From jimn8 at netcom.com Tue Mar 1 00:05:09 1994 From: jimn8 at netcom.com (Jim Nitchals) Date: Tue, 1 Mar 94 00:05:09 PST Subject: *Time Magazine* article on Clipper Message-ID: <199403010805.AAA17526@mail.netcom.com> (Sorry for the "from" and "to" names; I'm using elm and it just doesn't format the headers in a way that the Cypherpunks list software's happy with) America Online goofed, and let a preliminary description of this week's Time magazine remain online after Time pulled an article on Clipper at the last minute. I've got a screen snapshot of the welcome screen containing the promo text, as well as email from Tom Mandel, who maintains the Time Online information. He says it was pulled due to late breaking news. So, if Time puts out an article favorable to Clipper, and distracting the public's attention from mandated key escrow, it might make sense to do a little investigative journalism of our own. Not that I'd accuse Time of knuckling under to Administration pressure to pull the article, or making revisions based on NSA "advice." Are EFF and CPSR doing everything possible to get media attention? Can't the EFF hold a press conference and hand out a "Big Brother" award to whichever congresscritter has done the most to hurt the cause of privacy? Any of the sponsors of the FBI Wiretap bill would do. A little heavy adverse publicity might give pause to other critters, at least the ones up for re-election anyway. - Jim Nitchals From norm at netcom.com Tue Mar 1 00:17:41 1994 From: norm at netcom.com (Norman Hardy) Date: Tue, 1 Mar 94 00:17:41 PST Subject: standard for steganography? Message-ID: <199403010818.AAA19344@mail.netcom.com> At 0:56 3/1/94 -0500, Sergey Goldgaber wrote: >On Mon, 28 Feb 1994, Norman Hardy wrote: > >> Has anyone done statistical studies of low bits of pixels or sound samples? >> I suspect that they are often far from random. A flat 50% distribution in >> the low bits might standout like a sore thumb. I can imagine the the low ... >Yes, pure white noise would be anamalous. I have suggested that one use >a Mimic function with a "garbage grammar". Implemented correctly, it should >withstand statistical analysis. > >What is an AD converter? And what are the techniques you speak of that >mimic those AD converters? 'AD converter' = 'Analog to Digital converter'. Here are three schemes each with flaws: Consider an alphabet of 10 bit characters with a probability distribution such that each bit has an expected value of .6 (instead of the normal .5). The character 000000000 has a probability of .4^10 = .000105 and p(1111111111) = .6^10 = .006046. Do a Huffman encoding on this alphabet. 000000000 codes as 13 bits and 1111111111 codes as 7 bits. Take the cipher stream and execute the Huffman decode(!) operation on the cipher stream. Out comes a sequence of 10 bit bytes with 60% ones. To retrieve the original cipher stream execute the normal Huffman coding algorithm and get the original stream. The flaw here is that Huffman assigns some probability to each of the 10 bit characters which is 2^-7, 2^-8, ... 2^-13. The intermediate probabilities are not represented. This would show up without too much data. Another scheme is called 'arithmetic coding'. It avoids the above probability quantization but is tricky to program. I can't find a reference to it just now but it should appear in any modern book in information theory. Unlike Huffman it does not code each character into a definite number of bits but codes a sequence of several characters into a 'real number'. Adapting this to numbers that real computers can use is tricky. Again you feed the flat cipher stream into the decoding end of the algorithm and get biased bits. The above two schemes are information efficient. With a 60% bias you get 97% efficiency. If you are willing to settle for 80% efficiency you can merely establish a RNG synchronized at sender and receiver that sends a bit from the cipher stream with probability .8 and sends a one with probability .2. From sergey at delbruck.pharm.sunysb.edu Tue Mar 1 01:07:59 1994 From: sergey at delbruck.pharm.sunysb.edu (Sergey Goldgaber) Date: Tue, 1 Mar 94 01:07:59 PST Subject: standard for stegonography? In-Reply-To: <9403010717.AA20839@acacia.itd.uts.EDU.AU> Message-ID: On Tue, 1 Mar 1994, Matthew Gream wrote: > > Earlier, Sergey Goldgaber wrote: > > > Wasted bandwidth does not a poor method make! > > No, but in the case of steganography it does make it an impractical > requirement. I dissagree. You may waste a few bytes, or maybe several Kb, but it would be worth it. > No, I outlined two reasons. Firstly, an offset method such as you mention > wastes a lot of bandwidth. Say you take a conservative 16 bits as offset > (which is already too easy to brute force), there you have up to 64kbit of > potentially wasted bandwidth in a transmission medium that needs as much > as it can get. See for example pixel 'stegging', you'd need exceeding large > pictures just to overcome the offset noise let alone modulate data of any > practical length in. The second reason, which yes can be construed as more > a personal dislike, did regard the prerequistite for a PKCS. In retrospect, > I'll retract that. > As I said in an earlier post: you can either sacrifice space for security; or, sacrifice security for space! Now that I think about it, one wouldn't have to sacrifice any bandwidth whatsoever! As, the stego program could be made to do wrap-around encoding. Meaning that, as the end of the file is reached, encoding continues from the beginning until the appropriate offset is reached. This would loose none of the additional security offered by the original method. On a related note, someone has mentioned that fractals have a great ammount of potential for stego. Their noise-threshold is much higher. You may want to look into that if you're concerned with conserving space. > I agree with the first and foremost as well, steganography is there to > hide data. But by the same token, if the data is hidden, how do you know > there is any there ? Isn't the idea that _you_ have a quick means to > determine whether something has been hidden there, else it looks like > harmless information ? It _should_ look like harmless information! It would be _nice_ to be able to know which files have been stegg'ed; but, that would either have the potential to tip off one's opponent as well or, it would require secure channels to propagate header keys (see previous message in thread for comments to this effect). > > With your method, you're leaving it up to whatever particular information > has been stegged in to have some inherent integrity check. Ie. this would > work if you stegged in PGP data or signed data. I do not advocate stego'ing data with telltale headers. That combination is self defeating. It must be noted that encrypted headers, as per your advice, would allow one to know that decription was successful, without sacrificing security. > But what if you stegged > in something else, how do you know it was stegged data ? All I was > proposing was a method of providing a header encrypted so you _know_ that > what follows is stegged information, that was my original intent. > You would have to decrypt it to find out. The only problem may lie in figuring out the file-length. Possible solutions are: 1 - Put in some kind of EOF marker. Scatter a some more through the file just in case, as well. You may thus be required to make several attempts at decryption. 2 - Have a standard file length. Break the original file into standard length packets. Pad with noise, if neccessary. Then send it through via multiple successive files. > Those first few bits are decrypted to either > reveal a structured header, in which case you can proceed to remove > the rest of the data, or to reveal junk, in which case there is nothing > there, at least nothing for you. > This is much clearer, thank you. However, I'm sure you realize that if the key used to encrypt the header is standardized, and it's location of the header is standardized as well, much security is lost. If its not standardized, secure channels must exist for its propagation (ie: no need for stego). > > So that this question may be asked: if you have secure channels, why do you > > need encryption? > > I have seen this point, and yes, I guess it is a problem. You would need to > at some stage in the past agree on a key to use. How about changing that > from IDEA to RSA then ? > hmmmm..... > > It would be even easier to get the same picture and run it through your > > stego software which would look at your public-key and extract the file > > automatically. This would be pretty secure, easy to use, and require no > > secure channels! > > But then why offset in the first place? What is going to be at the offset > that can't be at the front of the file ? If something structured is going > to be at an offset, then it's easily susceptible to being brute force > searched. > Yes, stego is all but invalidated if you try and hide patterned information. That is why I recommend using "Stealth PGP" and/or a Mimic-function in combination with the standard stego we've been discussing. > Okay, how about giving up using some form of offset and just RSA encrypt > a header with the intended recipients key. You need not give up the offset-method to do this. They should work together for additional security. > To check, you'd get your stego > software to pull out the first 2048 bits and decrypt the first X bits > corresponding to whatever your modulus length is with your private key, > if the result is "*STEGO FOLLOWS*+other", then theres a file there, else > you know nothing exists there (at least not for you ..). This is a good idea. It will save you time you would have otherwise used to try and decrypt the whole file. However, this should only be used if the header fits in uniformly with the rest of the file. Otherwise, the file will stand out as encrypted. Of course, the data should be uniformly encrypted with Stealth PGP or its equivalent, as well. > However, this is half hearted because after thinking about it, I've come > to the conclusion that it's probably best if all the software does is > push the bits in and leave it up to Stealth-PGP (or other software) to > provide a means of creating the header and the proceeding data in a way > so that no key-ID's or so on exist. The function of Stealth PGP, as I understand it, is not only to encrypt without information as to the intended reciever, but to leave no trace of encryption whatsoever. Thus the need for a seperate, encrypted, header. I think your modified proposal should work just fine. > Then you could just > "desteg < art | stealth-pgp > out" and watch Stealth-PGP's exit code. If the desteg program automatically checks for encrypted, hidden fileheaders via un-stealth-pgp, it may be as simple as you've pointed out, anyway. > The desteg software shouldn't attempt to put anything in to identify > the presence of stegged data tho. > Your idea will save time at no loss to security, if the header is encrypted. I see a problem only if the header is: 1 - unencrypted or 2 - encrypted with a non-public key or 3 - encrypted but anamalous If its encrypted with a public-key and blends in with the rest of the data and the rest of the file it should be fine. Sergey From jeremy at crl.com Tue Mar 1 02:17:36 1994 From: jeremy at crl.com (Jeremy Cooper) Date: Tue, 1 Mar 94 02:17:36 PST Subject: The answer. Message-ID: I think I have found the way to end all our problems: ESP. Consider a secure public-key ESP connection from your head to mine. It's perfect. I think that we should work on developing this right away! _ . _ ___ _ . _ ===-|)/\\/|V|/\/\ (_)/_\|_|\_/(_)/_\|_| Stop by for an excursion into the-=== ===-|)||| | |\/\/ mud.crl.com 8888 (_) Virtual Bay Area! -=== From smb at research.att.com Tue Mar 1 06:27:44 1994 From: smb at research.att.com (smb at research.att.com) Date: Tue, 1 Mar 94 06:27:44 PST Subject: DES Question Message-ID: <9403011427.AA21477@toad.com> Mainly to sabotage the performance of DES software implementations. Even back then the government knew it was much easier to control the dissemination of hardware than software. Are you sure? I got the distinct impression it was related to serial/parallel conversions on the chips of the time. From lstanton at lehman.com Tue Mar 1 06:34:06 1994 From: lstanton at lehman.com (Linn Stanton) Date: Tue, 1 Mar 94 06:34:06 PST Subject: ditz in office In-Reply-To: <199402282219.RAA26298@eff.org> Message-ID: <9403011434.AA19268@sten.lehman.com> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Mike" == Mike Godwin writes: Mike> I'm still reasonably satisfied to have voted for Clinton. I Mike> don't think any of this stuff would have been any different Mike> if any other candidate had been elected. I think that these proposals would still be coming from the government if Bush had been re-elected, but that they would generate more opposition, which would, to me, be a Good Thing. It is an unfortunate fact that in this country, people often react differently to an idea, depending on who produces it. I have spoken to people who really TRUST Clinton, and who have no objection to clipper and the wiretap bill, until you remind them the the Republicans could be in office again someday. Then they go "Oh, yeah. That would be a problem" There is also the partisan issue. It would be much easier to muster opposition in Congress if the majority party was not the same as the party of the administration. Linn H. Stanton The above opinions are exclusively my own. If anyone else wants them, they can buy them from me. Easy terms can be arranged. - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 mQBNAitK8+EAAAECALzK83DH79m7DLKBmZA2h9U33fBE80EwT4xRY05K7WRfxpO3 BmhPVBmes9h97odVZ0RxAFvinOl4wZGOb8pDclMABRG0IUxpbm4gSC4gU3RhbnRv biA8c3RhbnRvbkBhY20ub3JnPrQnTGlubiBILiBTdGFudG9uIDxsc3RhbnRvbkBz aGVhcnNvbi5jb20+ =oCru - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- iQBVAgUBLXNSO8GRjm/KQ3JTAQEl4wH/cvsg3yl/iwKP1uQHJY5hqn/umpgbQznW tTm9XlPdl0NJa5PnysN8BoL4w5vskLjX3hFK33ZGknp+aUQl+zLKRg== -----END PGP SIGNATURE----- From ravage at wixer.bga.com Tue Mar 1 06:46:13 1994 From: ravage at wixer.bga.com (Jim choate) Date: Tue, 1 Mar 94 06:46:13 PST Subject: standard for steganography? In-Reply-To: <199403010523.VAA00389@mail.netcom.com> Message-ID: <9403011446.AA21798@toad.com> I have played w/ stego some and w/ the present resolutions of images I dont find the images have enough complexity to really hide a message of a useable length, unless you break it up into several images. I use a function to measure the complexity of a image based on adjacent bit changes. The more complex an image the more bit changes. I measure it thus: # of adjacent bit changes in image/ # of bits in image = complexity if the complexity is too low or too high (this is counter intuitive) then you can't hide a message. Consider an image w/ only a few bit flippings, any message that is inserted will cause the visual image to be distorted in a noticable way (unless it is truely expressionistic). Now consider a image w/ every other bit flipped (maximum complexity) which is in effect a checkerboard. Any bits that get flipped change the pattern to a less complex one (ie the checkerboard is broken up). Also you have to consider the effects on edges and the standard deviation inherant in using anti-aliasing. This will cause bits on the edge to be switched incorrectly for the algorith in use. Since it is a trivial problem to measure the sd for various graphics packages this makes a nifty test bed for finding imbedding images. Blank or mono-chromatic areas also show the same type of errors. I am still working on it and hope to find an error in there somewhere but so far no go. From uri at watson.ibm.com Tue Mar 1 06:57:40 1994 From: uri at watson.ibm.com (uri at watson.ibm.com) Date: Tue, 1 Mar 94 06:57:40 PST Subject: DES Question In-Reply-To: <199402282149.NAA00940@servo.qualcomm.com> Message-ID: <9403011457.AA21940@toad.com> Phil Karn says: > >Second question: The DES code that I have (not written by me) has a > >comment section which describes filling all 16 subkeys seperately, > >thereby allowing a 128 byte key. Is there any significant advantage to > >doing this? Is there any reason that I should not do it? > That sounds like my code. That feature seemed like a good thing to do > at the time. Then I learned about differential cryptanalysis. No, you > cannot strengthen DES in this way, and in fact you could actually > weaken it unless you are sure to use 128 completely random bytes for > your key. Phil is wrong and ys you can strengthen DES by choosing completely independent subkeys, rather than generating the subkeys with known algorithm from 56-bit "seed". However, the additional strength will mostly go towards foiling brute-force attacks. Note, that it will take about 2^60 chosen plaintexts instead of 2^47 to mount differential cryptanalysis attack, and also linear cryptanalysis is somewhat hampered by using subkeys independently generated. > >What is the purpose of the initial and final permutations? > Mainly to sabotage the performance of DES software implementations. > Even back then the government knew it was much easier to control > the dissemination of hardware than software. Wrong. Pure hardware requirements - nothing so subtle as to "complicate" software implementation, simply peculiarity of that day hardware... Trust me! (:-) -- Regards, Uri uri at watson.ibm.com scifi!angmar!uri N2RIU ----------- >From owner-cypherpunks Tue Mar 1 06:58:15 1994 From mnemonic at eff.org Tue Mar 1 06:58:15 1994 From: mnemonic at eff.org (Mike Godwin) Date: Tue, 1 Mar 94 06:58:15 PST Subject: ditz in office In-Reply-To: <9403011434.AA19268@sten.lehman.com> Message-ID: <199403011458.JAA15119@eff.org> Linn Stanton writes: > It is an unfortunate fact that in this country, people often react > differently to an idea, depending on who produces it. I have spoken > to people who really TRUST Clinton, and who have no objection to clipper > and the wiretap bill, until you remind them the the Republicans could > be in office again someday. Then they go "Oh, yeah. That would be a > problem" I don't detect any less opposition to Clipper and Digital Telephony from Clinton supporters than from Clinton opponents. Quite the opposite, if you want to know the truth. --Mike From lstanton at lehman.com Tue Mar 1 07:15:44 1994 From: lstanton at lehman.com (Linn Stanton) Date: Tue, 1 Mar 94 07:15:44 PST Subject: ditz in office In-Reply-To: <199403011458.JAA15119@eff.org> Message-ID: <9403011515.AA20333@sten.lehman.com> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Mike" == Mike Godwin writes: Mike> I don't detect any less opposition to Clipper and Digital Mike> Telephony from Clinton supporters than from Clinton Mike> opponents. Quite the opposite, if you want to know the Mike> truth. Exactly. This is how I see it (all numbers made up for illustration): If Clipper/Digital Telephony are proposed by Clinton, 60% of Democrats and 70% of Republicans will support. If Clipper/Digital Telephony are proposed by a Republican, 40% of Democrats and 80% of Republicans will support. Linn H. Stanton The above opinions are exclusively my own. If anyone else wants them, they can buy them from me. Easy terms can be arranged. - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 mQBNAitK8+EAAAECALzK83DH79m7DLKBmZA2h9U33fBE80EwT4xRY05K7WRfxpO3 BmhPVBmes9h97odVZ0RxAFvinOl4wZGOb8pDclMABRG0IUxpbm4gSC4gU3RhbnRv biA8c3RhbnRvbkBhY20ub3JnPrQnTGlubiBILiBTdGFudG9uIDxsc3RhbnRvbkBz aGVhcnNvbi5jb20+ =oCru - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- iQBVAgUBLXNb78GRjm/KQ3JTAQFdNAH/ZNjcqVtSVTQ8HY+qwAqgbOJrhKFNq6IO WA8bhJrRaccofIowUexlikyMyu1sVfE8FxZCCa1WO31wHAC996ZtOg== -----END PGP SIGNATURE----- From cvoid at netcom.com Tue Mar 1 07:59:42 1994 From: cvoid at netcom.com (Christian Void) Date: Tue, 1 Mar 94 07:59:42 PST Subject: T-Shirt stuff... Message-ID: Greetings. Could anyone who has order a t-shirt, but has not gotten a order confirmation PLEASE send me mail. I have a few orders sitting here that I have no size information or e-mail addresses for. Unless you want an XL, send me a note. Thanks. :) Christian Void /T71 | "I don't like it, and I'm sorry I | V/M/Research, Inc. cvoid at netcom.com | ever had anything to do with it." | P.O. Box 170213 Tel. 1+415-998-0774 | -Erwin Schrodinger (1887-1961) | SF, CA 94117-0213 * PGP v2.3a Public Key Available Via Finger * From frissell at panix.com Tue Mar 1 08:07:10 1994 From: frissell at panix.com (Duncan Frissell) Date: Tue, 1 Mar 94 08:07:10 PST Subject: Freehdom Isn`t Freeh Message-ID: <199403011606.AA22179@panix.com> New York Times, Monday, February 28, 1994 Business Day A PUSH FOR SURVEILLANCE SOFTWARE By John Markoff In the age of computer communications and digital telephone calls, the American people must be willing to give up a degree of personal privacy in exchange for safety and security, the head of the Federal Bureau of Investigation said. In an interview on Friday, Louis J. Freeh, the F.B.I. Director, defended proposed legislation that critics say would turn the nation's telephone network into a vast surveillance system. He said taxpayers would be asked to pay up to half a billion dollars to develop and deploy the necessary network software. The Administration wants to impose new technology that would enable law- enforcement agents to gather a wealth of personal information by monitoring citizens' calling patterns and credit card transactions over the telephone network --- and over the two-way cable television networks being planned by cable and phone companies. The system would go well beyond the current wiretapping technology, because much of the information could be gleaned without the police or F.B.I. actually having to eavesdrop on specific voice or electronic-mail conversations. "The costs are high, but you have to do a cost-benefit analysis," said Mr. Freeh, who insisted that fighting terrorists and criminals was the Government's intention --- not playing Big Brother to the citizenry. `A Credible Solution' "The damage to the World Trade tower and the economic interests of the country are conservatively estimated at $5 billion," he said, citing last year's bombing of the World Trade Center in Manhattan. "I think the American people will agree that this is a credible solution to the problem we face." The Administration is trying to line up Congressional support for the legislation, called the Digital Telephony and Communications Privacy Improvement Act of 1994, before having it formally introduced. Government officials say traditional wiretapping is becoming increasingly more difficult because more and more phone calls and data communications are transmitted as streams of digital information --- representing the ones and zeros understood by computers. Thousands of such calls may intermingle on a public-network circuit at any moment. Proponents of the legislation say new software placed on computerized network switching equipment is necessary to help law enforcement sort through this traffic. But executives of McCaw Cellular Communications, the nation's biggest cellular telephone company, told Mr. Freeh and White House officials at a meeting on Thursday that their newest telephone switches already provide the surveillance capabilities requested in the legislation. Moreover, privacy advocates say the Government can point to no case in which digital network technology alone has impeded an investigation. And they note that in the World Trade Center case, it was not electronic communications but mundane bungling of vehicle and warehouse rentals that led to arrests. An Electronic Portrait Such critics have long warned that in the information age, it is possible to build a detailed model of an individual's behavior, political and sexual preferences, social network and travel itineraries simply by examining telephone-calling patterns and credit card purchases. Some capabilities were demonstrated when law-enforcement agents pieced together a chronological list of phone calls made by the people accused of plotting and carrying out the attack in January on the figure skater Nancy Kerrigan. But the type of software the Clinton Administration wants to add to the public communications network would make possible much more detailed records of individuals' electronic activities. "It will be possible to develop a life-size portrait about you as a person," said Jerry Berman, executive director of the Electronic Frontier Foundation, a Washington privacy-rights lobbying group. "This is not just about a phone number." For the Administration, having taxpayers rather than communications companies pay for the system is meant to dilute industry criticism of the plan, which has met resistance since it was disclosed a few weeks ago. Congressional support is difficult to gauge. "The bill has some significant problems we need to resolve," said Representative Don Edwards, Democrat of California and chairman of the House Judiciary subcommittee on civil rights. "The profiling and the tracking aspect of the bill is something we are concerned abut." A version of the legislation was first proposed in 1991 by the Bush Administration at the urging of the Justice Department. But unlike that version, the new bill would limit the surveillance to public networks and not include company phone systems --- private branch exchanges, or PBXs --- or private corporate computer networks. Despite those changes, civil liberties groups and some industry executives say they are concerned that the scope of the new bill would give law- enforcement agencies new access to a vast amount of "transactional," or billing, information related to the setup of a telephone call. Under current law, obtaining a subpoena to obtain transaction data from the telephone company is easier than getting a wiretap warrant to eavesdrop on actual conversations, which requires a judge to find probable cause that a crime has taken place. Mr. Freeh met with telephone industry executives at the White House on Thursday and with Congressional leaders on Capitol Hill on Friday in an effort to attract support for the bill. He said in the interview that he was willing to compromise by adding safeguards for transactional information. "I understand the privacy concern," he said. "My real objective is to get access to the content of telephone calls. With respect to the extraordinary amount of personal information that is generated by this new technology, we would consider some way to block some of that information or raise the standard required to gain access. We're flexible on that." The F.B.I. Director said new digital communications technologies were making it more difficult for authorities to listen to conversations of suspected criminals who may be using cellular telephones or whose conversations may be carried as data streams in networks of fiber optic cables. Mr. Freeh said wiretapping had long been one of law enforcement's most effective tools. He cited examples in which it had been used effectively to prevent crimes, including a case in Chicago in which a terrorist was planning to shoot down an airliner with a Stinger missile. In that instance, Mr. Freeh said, The telephone networks involved were not advanced digital systems, but older analog networks that send voices as electronic patterns mimicking natural sound waves. But he said there had already been hundreds of cases in which attempted F.B.I. wiretaps had been thwarted by new digital communications technology --- not, he said, because the suspected criminals were necessarily trying to evade detection, but simply because the public-network technology made it difficult for agents to listen. Last year, a group called the Computer Professionals for Social Responsibility obtained Government documents through a Freedom of Information request indicating that an informal survey of F.B.I. offices in Newark, Philadelphia and Las Vegas, Nev., found no instances in recent years in which F.B.I. agents had encountered any technology- based problems in conducting wiretaps. Asked about those findings, Mr. Freeh said he was not aware of them. Several telephone industry executives who met with Mr. Freeh at the White House last week said that they were skeptical whether new legislation was needed and that they were concerned about provisions that would fine telephone companies up to $10,000 a day for failing to comply with the new law. "This is just new faces giving the same pitch," said one telephone industry vice president who attended the meeting and who had been opposed to the Bush Administration's version of the legislation. He spoke on condition of anonymity. Executives at the American Telephone and Telegraph Company said they did not believe there were significant technological problems that warranted new legislation. They also said they feared that the proposed legislation would undercut the privacy expected by customers. "Clearly the privacy concern is the biggest concern for A.T.&.T.," a spokesman for the company, Herb Linnen, said. He said the company would continue to meet with the White House and Justice Department in an effort to narrow the bill. Industry executives and privacy advocates have also warned about abuses of new surveillance technologies by telephone company insiders and computer vandals. But the F.B.I. Director said the protections in current analog telephone systems would be adequate to deter most break-ins. "This is always a threat," Mr. Freeh said. "But it's de minimus if you consider the alternative, which is not giving law-enforcement and intelligence agencies these capabilities." A White House official said that he believed opponents of the legislation were overreacting and that the law was a good compromise between privacy and law-enforcement needs. "The authority to gather transactional information already exists; I don't think this expands that authority," said John Podesta, the White House staff secretary. "We're open to talking through the issue with the privacy community." ----- Keyboarding by Lois Roth --- WinQwk 2.0b#1165 From frissell at panix.com Tue Mar 1 08:07:15 1994 From: frissell at panix.com (Duncan Frissell) Date: Tue, 1 Mar 94 08:07:15 PST Subject: Dorothy Denning Message-ID: <199403011607.AA22207@panix.com> New York Newsday, Tuesday, March 1, 1994 Letter to the Editor THESE YANKEE CLIPPERS ... Dorothy E. Denning asserts that the federal government needs to force telecommunications consumers to buy into a so-called "weak encryption" scheme using the National Security Agency's "Clipper" computer chip because the government needs to be able to decrypt communications traffic that criminals might generate in the future ["The Clipper Chip Will Block Crime," Viewpoints, Feb. 22]. Denning fails to offer any evidence that any criminal or terrorist group has ever used encryption in the past, and also fails to explain why they would be stupid enough to use a compromisable encryption scheme in the future. Denning glosses over past governmental abuses of intercept technology with assurance that Clipper intercept procedures are resistant to abuse. Denning fails to mention that federal documents confirm that government intercept procedures involving Clipper technology offer users no more protection from wrongful government surveillance than plain text. Intercepted data protected by so-called "strong" encryption cannot be told from data protected by weak encryption until somebody actually tries to break the code --- which would make random checking of the data stream necessary to expose users of strong encryption schemes. But the government disclaims the use of codebreaking except under court order. Universal adoption of Clipper technology is unlikely because now, just months after the government unveiled Clipper, designers are offering, through electronic bulletin boards and user groups, freeware [available for free tryouts before buying] programs using strong encryption. It is only a matter of months before true "military-strength" encryption software reaches the market --- making Clipper the Edsel of cryptography. If the government forces Americans to use nothing but Clipper encryption, we can kiss the First and Fourth Amendment rights good-bye. Hold out for military-strength encryption to keep your data safe! Ludwig R. Vogel Manhattan Editor's note: The writer is chair of the Libertarian Party of New York State. The views expressed are his own. ---- Keyboarding by Lois Roth --- WinQwk 2.0b#1165 From frissell at panix.com Tue Mar 1 08:16:04 1994 From: frissell at panix.com (Duncan Frissell) Date: Tue, 1 Mar 94 08:16:04 PST Subject: ditz in office Message-ID: <199403011615.AA28534@panix.com> Even if the normal parts of the Bush and Clinton Administrations are equally fascist, the Clinton Administration would win in net fascism since it includes an added (unelected) fascist element missing from the Bush administration: Linda Stasi reports in her column "Hot Copy" in the New York Daily News today (Tuesday, March 1, 1994) that she and some other gossip columnists were invited to have tea with Hillary Clinton yesterday. [Hillary was in town to boost her health care program with a visit to a very recently improved Kings County Hospital. The units Hillary visited were specially scrubbed for her visit and contained fewer patients than usual.] Linda says Hillary "...never wants to run for public office herself. But she'd probably get elected in a minute." Think again Linda. You also provided us with another one of those `Hillary's Ominous Quotes of the Day': "AT A CERTAIN POINT, YOUR RIGHTS MUST BE ABRIDGED FOR THE PUBLIC GOOD." The statement might simply be her response to a question about convicted rapists not having to submit to an AIDS test. And then again, it might not. --- WinQwk 2.0b#1165 From mnemonic at eff.org Tue Mar 1 08:23:39 1994 From: mnemonic at eff.org (Mike Godwin) Date: Tue, 1 Mar 94 08:23:39 PST Subject: ditz in office In-Reply-To: <199403011615.AA28534@panix.com> Message-ID: <199403011623.LAA17434@eff.org> Oh, please. Dislike Hillary Clinton's policies if you must, but all this animus against Hillary Clinton as a person and as a fascist is grounded in sexism. --Mike From smb at research.att.com Tue Mar 1 08:40:05 1994 From: smb at research.att.com (smb at research.att.com) Date: Tue, 1 Mar 94 08:40:05 PST Subject: ditz in office Message-ID: <9403011640.AA23727@toad.com> `Hillary's Ominous Quotes of the Day': "AT A CERTAIN POINT, YOUR RIGHTS MUST BE ABRIDGED FOR THE PUBLIC GOOD." Sorry, that's a statement of fact. The interesting question is where one draws the line. Assume, for example, that you are a fervent believer in some religion that requires the sacrifice of unwilling outsiders. Should you be permitted to practice that religion? (Note: I said ``practice'', not ``believe in''.) Would the anarchist liberatarian next door to you be abridging your rights if he or she shoots back when you come to collect some victims? Even your own note acknowledged that rights aren't necessary absolute; you noted, in an exculpatory context, that The statement might simply be her response to a question about convicted rapists not having to submit to an AIDS test. As I said -- the interesting question is how and where one draws the line. From jef at ee.lbl.gov Tue Mar 1 09:10:33 1994 From: jef at ee.lbl.gov (Jef Poskanzer) Date: Tue, 1 Mar 94 09:10:33 PST Subject: standard for stegonography? Message-ID: <9403011710.AA08621@hot.ee.lbl.gov> >Now that I think about it, one wouldn't have to sacrifice any bandwidth >whatsoever! As, the stego program could be made to do wrap-around >encoding. Indeed, that's what I implemented. The current man page is appended. --- Jef pnmstego(1) USER COMMANDS pnmstego(1) NAME pnmstego - insert a stegonographic message into a portable anymap SYNOPSIS pnmstego [-offset n] [-components rgb] [-bitsched 10010...] file [pnmfile] DESCRIPTION Reads a portable anymap as input. Hides another file within the anymap by changing the low-order bits of each pixel, and writes the modified anymap to standard output. Stegonography means "hidden writing" - it's for storing a message in such a way that an opponent won't even be sure that the message is there, let alone be able to extract, decrypt, and read it. Pnmstego lets you store a file in the low-order bits of a PPM or PGM image. For a typical maxval of 256, this means the pixel values will be changed by only 1/256, which should not be noticable to someone viewing the image. Only PGM and PPM images may be used - trying to hide a file in a PBM image would be easily visible, so it's not allowed. OPTIONS The program has a bunch of flags that let you specify varia- tions on exactly how the bits are hidden in the image. If you don't specify any flags, the default options give you a reasonable storage method, to wit: -offset 0 -components b -bitsched 1 Letting the options default like this has the advantage that you can send a stegoed file to someone without having to specify what flags you used. You can also put the file on a public FTP server for people to retrieve, without needing any other communication. However, there is a disadvantage: people who the file is not intended for will be able to extract it too. If the resulting file is recognizable in some way, for instance if it's encrypted by PGP, then some of the purpose of the stegonographic storage will have been compromised. (A PGP file has a standard header and stores, in cleartext, the keyid needed to decrypt a file.) So, if you want the file to be absolutely positively hidden, you can use non-default settings for the options. Just don't forget what settings you used, and remember that if you want to send the file to someone else you will have to communicate the necessary settings somehow. Now, as for what the options do: -offset Specifies how far into the image to start. If the file runs off the end of the image, it wraps around back to the beginning, so don't worry about specifying too large an offset. In fact, you can even specify an offset larger than the image size - the initial value gets wrapped around too (modulus). Basically, any 32-bit number can be used. -components This lets you specify which of the red, green, or blue color components is used for storing bits. You give it a string made up from one or more of the letters r, g, and b. The default is b, use only the blue component. See the section below on quantization for why the default isn't rgb. If the input image is a PGM file, instead of PPM, this option is silently ignored. -bitsched This lets you skip using some possible bit posi- tions in the image. If the file you're hiding is not so big that you need the whole image to store it, you can use this option to hide it better. The argument is just an arbitrary- length string of 1's and 0's - the 1's say which bit positions should be used, and the 0's which should be skipped. The default is to use all bit positions. QUANTIZATION Normally, to store an image in a colormapped file format such as GIF, you first run it through ppmquant. However, if you try to quantize, then stego, and then convert to GIF, you will find that the ppmquant step will fail with an error about too many colors. This is because the stego step increased the number of colors. You might think, ok, stego first, then quantize; nope, the quantization would destroy the stegonographic message. Here's what you do instead: quantize down to half the number of colors you want in the final file, and then use only one of the three color com- ponents to store the hidden file. Using only one bit per pixel, the number of colors can at most double. This is why the default for the -components flag is to use only blue. So, the pipeline to use is: ppmquant 128 image.ppm | pnmstego message.txt | ppmtogif > hidden.ppm SEE ALSO pnmdestego(1), pnm(5) AUTHOR Copyright (C) 1994 by Jef Poskanzer. From adam at bwh.harvard.edu Tue Mar 1 09:10:52 1994 From: adam at bwh.harvard.edu (Adam Shostack) Date: Tue, 1 Mar 94 09:10:52 PST Subject: ditz in office In-Reply-To: <199403011615.AA28534@panix.com> Message-ID: <199403011710.MAA01927@duke.bwh.harvard.edu> Duncan Frissell wrote: (Hillary Rodham Clinton, speaking in all caps:) | "AT A CERTAIN POINT, YOUR RIGHTS MUST BE ABRIDGED FOR THE PUBLIC GOOD." | | The statement might simply be her response to a question about convicted | rapists not having to submit to an AIDS test. IMHO, there is a world of difference between abrogating the rights of a convicted criminal and the rights of the accused. Society seems to have agreed that conviceted criminals should be stripped of certain rights, such as their freedom and or their ownership of property, after their conviction. Since the question of "Did he have AIDS?" clearly impacts the severity of the crime committed and the impact it may have on the victim, I don't see this as an amazingly shock provoking example of the rights of a criminal being taken away, especially in light of how difficult it seems to be to obtain a conviction for rape. I would not be willing to accept such testing on the basis of anything but a conviction. An accusation (in my mind) is not enough to force a test, nor to force the disclosure of a previous test. Adam -- Adam Shostack adam at bwh.harvard.edu Politics. From the greek "poly," meaning many, and ticks, a small, annoying bloodsucker. Have you signed the anti-Clipper petition? From jef at ee.lbl.gov Tue Mar 1 10:39:58 1994 From: jef at ee.lbl.gov (Jef Poskanzer) Date: Tue, 1 Mar 94 10:39:58 PST Subject: standard for stegonography? Message-ID: <9403011839.AA08937@hot.ee.lbl.gov> I wrote: >offset, wrap-around, bit schedules Actually, that interface is way too complicated and still not that secure. How about if the user just specifies a seed for a random number generator. Then that generator is used to make a *permutation* of the bit locations in the image, and the file's bits are stored in the permuted order. And look, this hides the file-length longword and any fixed file header real well, by spreading them through the image. Now I just have to find a simple but robust RNG that I can include in pbmplus, and some code to generate a permutation of a specified size. I'm not going to have ITAR problems with this, am I? RNGs are still legal to export? Oh, and to answer the original question: no standard. If this idea works, it's clearly better than existing stego systems at hiding the data; that's more important than interoperability. --- Jef From tcmay at netcom.com Tue Mar 1 10:49:59 1994 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 1 Mar 94 10:49:59 PST Subject: ditz in office In-Reply-To: <199403011458.JAA15119@eff.org> Message-ID: <199403011850.KAA22046@mail.netcom.com> Mike Godwin writes: > Linn Stanton writes: > > > It is an unfortunate fact that in this country, people often react > > differently to an idea, depending on who produces it. I have spoken > > to people who really TRUST Clinton, and who have no objection to clipper > > and the wiretap bill, until you remind them the the Republicans could > > be in office again someday. Then they go "Oh, yeah. That would be a > > problem" > > I don't detect any less opposition to Clipper and Digital Telephony from > Clinton supporters than from Clinton opponents. Quite the opposite, if you > want to know the truth. I tend to agree with Mike here. Playing the "what if" game, had Bush won, the Clipper thing would still be rolling along (remember that it was started long ago, probably in the mid 80s). The arguments against it would have a slightly different flavor, the Right would be more mollified, and the Left would be screaming about a police state. Perhaps more Congressional opposition to Clipper would've emerged if Bush were Prez, but we don't know. I'm hopeful that the Congresscritters will eventually realize that the foundations of a police state are being laid with things like Digital Telephony (proposed first under Bush, of course) and the 31 flavors of Clipper, Capstone, and Tessera. The real problem is not Republican vs. Democrat, but the concentration of more and more economic and political power in the hands of the State and the continual erosion of individual liberties. But you've heard some of us talk about this before, so I'll stop. --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^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway." From matsb at sos.sll.se Tue Mar 1 10:57:06 1994 From: matsb at sos.sll.se (Mats Bergstrom) Date: Tue, 1 Mar 94 10:57:06 PST Subject: Freehdom Isn`t Freeh In-Reply-To: <199403011606.AA22179@panix.com> Message-ID: > New York Times, Monday, February 28, 1994 > Business Day > A PUSH FOR SURVEILLANCE SOFTWARE > By John Markoff > A version of the legislation was first proposed in 1991 by the Bush > Administration at the urging of the Justice Department. But unlike that > version, the new bill would limit the surveillance to public networks and > not include company phone systems --- private branch exchanges, or PBXs > --- or private corporate computer networks. This is not fair! But couldn't a network provider hire all it's users for 1 dollar a year and deduct the employees' communications expenses from their salaries (making the net salary negative) thus keeping the network corporate and private? matsb From tcmay at netcom.com Tue Mar 1 11:33:44 1994 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 1 Mar 94 11:33:44 PST Subject: Virtual Corporations to Avoid Taxes In-Reply-To: Message-ID: <199403011934.LAA28358@mail.netcom.com> Here's an area that has long fascinated me: using corporate entities as a way to bypass taxes on individuals. Mats Bergstrom writes: > > A PUSH FOR SURVEILLANCE SOFTWARE > > By John Markoff > > > A version of the legislation was first proposed in 1991 by the Bush > > Administration at the urging of the Justice Department. But unlike that > > version, the new bill would limit the surveillance to public networks and > > not include company phone systems --- private branch exchanges, or PBXs > > --- or private corporate computer networks. > > This is not fair! But couldn't a network provider hire all it's users for > 1 dollar a year and deduct the employees' communications expenses from > their salaries (making the net salary negative) thus keeping the network > corporate and private? Indeed, anytime a distinction is made between the rights of individuals and corporate entities, all kinds of "gaming" can occur. To pick a truly devious example, in the same vein that Mats just mentioned, consider that corporations don't pay taxes or even report income on site-to-site transfers of goods, knowledge, etc. That is, huge amounts of stuff can flow back and forth within the company and not be treated as "income," because the various parts of the company are treated as part of the whole....only the "net income" ultimately gets taxed. (I'm not suggesting any changes in tax law--trying to tax internal flows would be ludicrous and impractical, as well as being unethical.) Where it gets interesting is if a group of consultants--the Cypherpunks, for example--instantiate themselves as a "corporation" and do mutual consulting and helping....avoiding taxes all the way. (Recall that plumbers and carpenters, for example, who do reciprocal labor are technically supposed to report all income received, to estimate the value of the labor received, etc.). Cyberspatial networks will allow "virtual corporations" to be formed that can shelter a lot of activity that would otherwise be heavily taxed! Kind of like a commune (which I suspect end up reporting very little "net" income and almost no income at all for the individual participants). Individuals would surely want a "real" income to be extractable from the system, and this "net" income would be fully taxable. But the mutual help aspects would not be taxable as is now the case. The best examples of such virtual corporations are _professional partnerships_, as in legal partnerships, medical partnerships, etc. The participants can exchange expertise, help each other, etc., all without reporting the transactions as income (or as expenses, to deduct from their income in other transactions). (Scenario: Create similar partnerships for blue-collar workers, so plumbers, carpenters, roofers, etc. can avoid taxes when they "trade" work.) (I won't get into the interesting issues of how contributors eventually extract income from such deals. There's always the potential for shirkers, layabouts, cheaters, and other phenomena well-known to commune folks. But the potential is there.) I have a sneaking suspicion that all of these ways that corporations can be used to limit taxes are the reasons for so many special laws and taxes on corporations. Imagine that the entity described by Mats Bergstrom is formed, and everyone gets paid their $1 a year.....then the various government agencies (in the U.S., in this example) descend upon the corporation and ask about the health care plans, the OSHA compliance, the minority quotas ("What, you mean 97% of your so-called "hackers" are white males?"), and on and on. And under Bilary's Health Nationalization Plan, if the corporation has more than X employees (where X is currently 50, I believe), it'll be instructed to fork over about $5000 per year per employee, no matter their wages ($1 a year), plus administrative expenses. Oh, and don't forget the minimum wage laws! Despite these problems, I see great opportunities for cypberspatial corporations being used to shield participants against various taxes and regulations. Foreign-based corporations, for example. Techno-communes, anyone? --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^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway." From plaz at netcom.com Tue Mar 1 11:40:57 1994 From: plaz at netcom.com (Plaz) Date: Tue, 1 Mar 94 11:40:57 PST Subject: standard for steganography? Message-ID: <199403011941.LAA06715@mail.netcom.com> Jim choate wrote: >I have played w/ stego some and w/ the present resolutions of images I dont >find the images have enough complexity to really hide a message of a useable >length, unless you break it up into several images. Present resolutions? What directions do you think it needs to go? Stego handles 24 bit TrueColor (actually 32 bit, but Romana wisely decided not to stuff data in the almost always blank alpha channel), and as many DPI as you have memory for. I don't think there is much call for deeper color resolution. It's true that GIF only accepts 8-bit color and the defacto standard internet transmision format for higher resolutions JPEG is a lossy compression that annhilates the message. Is this what you are refering to? >I use a function to measure the complexity of a image based on adjacent bit >changes. The more complex an image the more bit changes. I measure it thus: > ># of adjacent bit changes in image/ # of bits in image = complexity > >if the complexity is too low or too high (this is counter intuitive) then you >can't hide a message. Consider an image w/ only a few bit flippings, any >message that is inserted will cause the visual image to be distorted in a >noticable way (unless it is truely expressionistic). Now consider a image w/ >every other bit flipped (maximum complexity) which is in effect a >checkerboard. Any bits that get flipped change the pattern to a less complex >one (ie the checkerboard is broken up). Also you have to consider the effects >on edges and the standard deviation inherant in using anti-aliasing. This >will cause bits on the edge to be switched incorrectly for the algorith in >use. Since it is a trivial problem to measure the sd for various graphics >packages this makes a nifty test bed for finding imbedding images. Blank or >mono-chromatic areas also show the same type of errors. Yes, it is recommended that noisy images are used as the message envelope. Scanned or Frame-grabbed are good for this kind of thing. _______________________________________________________________________ Geoff Dale -- Cypherpunk/Extropian -- Plastic Beethoven AnarchyPPL - Anarch (Adjudicator) ExI-Freegate Virtual Branch Head plaz at netcom.com 66 Pyramid Plaza plaz at io.com Freegate, Metaverse at io.com 7777 "Subvert the domination paradigm!" From plaz at netcom.com Tue Mar 1 11:41:08 1994 From: plaz at netcom.com (Plaz) Date: Tue, 1 Mar 94 11:41:08 PST Subject: standard for stegonography? Message-ID: <199403011941.LAA06727@mail.netcom.com> Jef Poskanzer writes: >>Well, try using Stego on an 8 bit PICT, and see for yourself! >>It looks like a >slight< random noise filter was applied to >>the image - plausibly the sort of trouble one would have with >>a slightly imperfect scanner. > >Maybe colormaps on the Mac are always sorted? That would minimize >the visible effect of +-1 changes in index value. Colormaps on the Mac are not "always" anything, since creating custom pallettes is trivial, but yes, they usually are. For best stegonagraphy in 8-bit, I would recomend using the system greyscale pallette. (Greyscale images *almost always* sorted on the mac.) _______________________________________________________________________ Geoff Dale -- Cypherpunk/Extropian -- Plastic Beethoven AnarchyPPL - Anarch (Adjudicator) ExI-Freegate Virtual Branch Head plaz at netcom.com 66 Pyramid Plaza plaz at io.com Freegate, Metaverse at io.com 7777 "Subvert the domination paradigm!" From frode at toaster.SFSU.EDU Tue Mar 1 11:43:20 1994 From: frode at toaster.SFSU.EDU (Frode Odegard) Date: Tue, 1 Mar 94 11:43:20 PST Subject: It's the philosophy, stupid! Message-ID: <9403011941.AA17409@toaster.SFSU.EDU> It's now quite a while since I promised to write something about how the U.S. is starting to look more and more like the Weimar Republic just before Hitler came to power. However, I am simply out of band- width, and will try to get away with recommending the book where I first picked up this idea: "Ominous Parallels" by L. Peikoff The book reveals the philosophical premises of today's Liberals *and* Conservatives and shows how they would fit right into Weimar. In the end, Hitler was the man who promised to implement the ideals of both the right (order, restraint of workers etc.) and the left (social programs, restraint of businessmen.) Both the Protestants and the Catholics praised Hitler, for "increasing the moral standard" of the country. Finally, Ayn Rand's "Atlas Shrugged" is a novel which offers a rather stunning commentary to the words of both Bush and Clinton. Indeed, it was "Atlas Shrugged" which finally prompted me to abandon the super-socialized Norway and move to the U.S.; and here I am watching it grow ever-more statist. :-) As for anyone already aware of / curious about Rand's philosophy, Objectivism, I'll be happy to (per email) answer questions, point them to discussion lists and so on. Frode Odegard From nobody at jarthur.claremont.edu Tue Mar 1 11:50:16 1994 From: nobody at jarthur.claremont.edu (nobody at jarthur.claremont.edu) Date: Tue, 1 Mar 94 11:50:16 PST Subject: No Subject Message-ID: <9403011950.AA27701@toad.com> Hi All... No no answer to the swiss bank question... Duncan... if you KNOW positively then your answer is OK... otherwise if you are shooting from the HIP please refrain... A definitive answer to this question is needed... and currently its unknown... anon From jef at ee.lbl.gov Tue Mar 1 11:58:10 1994 From: jef at ee.lbl.gov (Jef Poskanzer) Date: Tue, 1 Mar 94 11:58:10 PST Subject: low-overhead encrypted telnet Message-ID: <9403011958.AA09178@hot.ee.lbl.gov> I've been talking about entrypted telnet with Craig Leres lately, and he came up with an interesting idea. The background is, sysadmins want encrypted telnet so that passwords don't fly around in the clear, but at the same time, they don't want to spend too many extra CPU cycles. I figured at least some sysadmins would resist installing an encryption-capable telnetd because of this concern about overhead. What you'd really like to do so satisfy these people is encrypt only when actually transmitting passwords. Problem is, that's hard to implement. Kerberos does it by supplying new versions of a dozen different programs, and it still only works within your organization, and even there it doesn't handle chained logins (telnet from host A to host B, then from host B to host C, etc.). It's hard because you have different levels of software trying to talk to each other. A solution that worked entirely within telnet would be a lot simpler. A compromise I thought of a while back is to encrypt the first few kilobytes and then switch to cleartext. This lets you log in securely, the average overhead for the session remains low, and there's no interaction between different software levels. But this also doesn't handle chained logins, if the second login comes later in your session. So here's Craig's idea: only encrypt the client-to-server direction. That's the only direction that passwords go, so it's secure; and it's low overhead because you generally type far fewer characters than you read. Just a tidbit for anyone working on encrypted logins. --- Jef From VACCINIA at UNCVX1.OIT.UNC.EDU Tue Mar 1 11:58:26 1994 From: VACCINIA at UNCVX1.OIT.UNC.EDU (VACCINIA at UNCVX1.OIT.UNC.EDU) Date: Tue, 1 Mar 94 11:58:26 PST Subject: clipper + enaction = illegal alternate encryption Message-ID: <01H9GN16SBXU000676@UNCVX1.OIT.UNC.EDU> -----BEGIN PGP SIGNED MESSAGE----- Jeremy at crl.com writes: >Now why bother going through all the trouble to take out the chip? Why >not just leave it in there and send RSA encrypted over your phone line? >Once they _DO_ decrypt your clipper, they will still have another barrier. >Leaving the chip in there does make it a little harder even for law >enforcement doesn't it? This is the reason all other forms of encryption will be outlawed if the clipper proposal goes through. I foresee at least two lines of enforcement. The first is that one is held in contempt of court (assuming they can find some charges to press) until you give them your key. How long can they keep you in the slammer on a contempt charge? This option is already available and seems to work, at least so far. The second is to make alternate encryption illegal and thus they will get you even if they have no evidence to charge you with. After all, if the police are monitering you AND you are encrypting information, you must be guilty, right? Encryption will be enough evidence to convict. This makes life easy for law enforcement and will surely be the next step after clipper. If they can't get you for the alleged crime you are committing then use of illegal encryption will provide a consolation prize. They really HAVE to make alternate forms of encryption illegal to make clipper of any value to them, despite the rhetoric we are now hearing (at least some people are hearing). Scott G. Morham !The First, VACCINIA at uncvx1.oit.unc.edu! Second PGP Public Keys by Request ! and Third Levels ! of Information Storage and Retrieval !DNA, ! Biological Neural Nets, ! Cyberspace -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLXModj2paOMjHHAhAQH4IgQAy+sqJeI1JqDgtR4kayOuo5ovzcVpxfVM JTi7ZgwLppw859cKhQgGzHfWezpDYQxrYGEfOH4JqFXWUlqEyVgrDhIw2PVMO95p IkGDrU90O/RkUFg9lrEuWvxSXJvKX52Cz6jN7tj7DxkdXYutpc2z80QiPY1mtXN7 wr7XySZ9dzI= =BVk0 -----END PGP SIGNATURE----- From wet!naga Tue Mar 1 12:11:49 1994 From: wet!naga (Peter Davidson) Date: Tue, 1 Mar 94 12:11:49 PST Subject: Insecurity of public key crypto #2 (reply to May) Message-ID: [The BBS I use seems to have brain damage. Apologies if this has already been posted.] >From: tcmay at netcom.netcom.com (Timothy C. May) >Subject: Re: Mac encryption >Date: Wed, 23 Feb 1994 09:56:40 -0800 (PST) > >Ron Davis writes: > >(quoting me [T.C.M.]) > >>>MacPGP, available by anonymous ftp from the soda.berkeley.edu site, is >>>the only one I know of using public key methods, and hence the only >>>one of real interest to Cypherpunks. > >The problem with symmetrical ciphers is one of *scaling*. > >Since a key must be exchanged with each other person, the total number >of keys growns rapidly as the community of participants increases. At >any stage, the key may be lost, stolen, observed, shared with the >Feds, etc. A community of 700 participants, as here on Cypherpunks, >would mean each person would have to generate, exchange (securely!), >and store 700 specific keys for use just with others. Anybody with 700 co-conspirators is asking for trouble, since at least one of them is sure to be a federal agent. Encryption is for concealing "sensitive" information. If it's not sensitive, why bother? If it is sensitive then you'd better be damn sure you can trust the person you're sending it to. >This is the famed "key distribution problem." > >With public key methods, this problem is largely solved. Each person >can generate his or her own key, publish the public key part of it, >and be done with it. It's not that simple. Terry Ritter has pointed out on sci.crypt that the problem with PGP is the validation of public keys used. In other words, the security hole in the use of PGP is not in the encryption methods used, or in the use of PGP itself, but in the possibility of being duped by someone (or some nefarious federal agency) spreading bogus public keys. It's not enough to have a public key which you believe is the public key of a person you wish to communicate securely with - you also have to be sure that the private key which corresponds to this public key is known only to that person, in other words, that the public key really did come from the person you believe it came from. If you get the (presumed) public key of some person X from some directory of public keys, or from some third party, how can you be sure it didn't originate with someone who wants to monitor all the encrypted messages being sent to X? Terry Ritter has explained how a third party can place themselves in the middle of encrypted communications between two people using PGP and monitor everything they say to each other - and this without having to crack RSA or IDEA. This method of eavesdropping applies only to public key encryption systems, not to secret key systems, so I suggest that the latter are still of interest (even to cypherpunks), not only for encrypting data that stays on your hard disk but also for encrypted communications. rom owner-cypherpunks Tue Mar 1 12:11:49 1994 Return-Path: Received: by toad.com id AA28180; Tue, 1 Mar 94 12:11:49 PST Received: from wet.UUCP by toad.com id AA28156; Tue, 1 Mar 94 12:11:44 PST Received: by wet.uucp (/\=-/\ Smail3.1.18.1 #18.2) id ; Tue, 1 Mar 94 11:52 PST Message-Id: Date: Tue, 1 Mar 94 11:52 PST From: wet!naga (Peter Davidson) To: cypherpunks at toad.com Subject: Insecurity of public key crypto #1 (reply to Mandl) Sender: owner-cypherpunks at toad.com Precedence: bulk [My BBS is having fits lately. Apologies if this has already been posted.] >Date: Wed, 23 Feb 94 12:13:57 EST >From: dmandl at lehman.com (David Mandl) >Subject: Re: Mac encryption > >The invention (discovery?) of public-key crypto changed the world, and >makes practical everyday use of crypto infinitely easier. Infinitely? You mean there is absolutely *no* difficulty involved in using PGP? I quit using it up quite a while back. Couldn't be bothered with the hassle. >It also makes >the kinds of specific things cypherpunks are interested in much more >practical (or POSSIBLE). Digital signatures, yes. I haven't had a need for 'em so far (I'm not setting up a digital bank). >If you correspond with hundreds of people on a >regular basis, including people you don't know and people you may send >something to once and never deal with again, it is impractical to say the >least to have to generate and exchange keys. Only "sensitive" information is worth encrypting and if you want to stay out of trouble you don't go giving sensitive information to someone you don't know. A certain mutual knowledge and trust between two people has to be establish before any exchange of sensitive information. >Why was public key crypto invented at all? Why are people interested in >using it? Practically, it's really fundamentally different from symmetric >crypto, which is of very limited use in the situation we're all in now >(anonymous communication, the net, quick hit-and-run dissemination of >information, digital signatures, etc., etc.). Crypto is for concealing information from those you don't want to see it. Public key crypto is thus not fundamentally different from symmetric key crypto. The difference is in communication of the encryption key, which is not a fundamental difference. Both kinds of crypto have problems when it comes to key distribution. In the case of secret key the problem is in keeping the key secret. In the case of public key the problem is in validating the public key. >PGP also has the "web of trust" structure built in. "Trust"? Sure. Just trust the person you got X's public key from (who got it from someone who got it from who knows?). So is X's public key really X's public key? Sure, just trust that it's so, then send X a message and trust that it won't be intercepted by whoever put out the bogus public key for X. From schneier at chinet.com Tue Mar 1 12:16:15 1994 From: schneier at chinet.com (Bruce Schneier) Date: Tue, 1 Mar 94 12:16:15 PST Subject: APPLIED CRYPTOGRAPHY - Errata 1.5.6 - March 2, 1994 Message-ID: APPLIED CRYPTOGRAPHY ERRATA Version 1.5.6 - March 2, 1994 This errata includes all errors I have found in the book, including minor spelling and grammatical errors. Please distribute this errata sheet to anyone else who owns a copy of the book. Page xvii: Third paragraph, first line: "Part IV" should be "Part III". Page 1: First paragraph, fourth line: "receiver cannot intercept" should be "intermediary cannot intercept". Page 6: Sixth and seventh lines: "against symmetric" should be "against a symmetric". Page 8: Second paragraph, first line: "q code" should be "a code". Page 10: Second paragraph, fifth line: Reference "[744]" should be "[774]". Page 11: Second paragraph: "The rotations of the rotors are a Caesar Cipher" should be "Each rotor is an arbitrary permutation of the alphabet". Page 13: Third paragraph: Delete parenthetical remark. Fifth paragraph, first line: "Shift the key" should be "shift the ciphertext". Page 15: Section 1.3, first line: "Throughout the book use" should be "Throughout the book I use". Page 25: "Attacks Against Protocols," first paragraph: "the protocol iself" should be "the protocol itself". Page 27: "One-Way Functions," fourth paragraph: "For example, x^2" should be "For example, in a finite field x^2." Page 28: Third paragraph, third and fourth sentences should be "How to put mail in a mailbox is public knowledge. How to open the mailbox is not public knowledge." Page 30: Fourth line: "symmetric cryptosystems: by distributing the key" should be "symmetric cryptosystems: distributing the key". Page 30: "Attacks Against Public Key Cryptography," second paragraph: "The database also has to be protected from access by anyone" should be "The database also has to be protected from write access by anyone". Also: "substitute a key of his choosing for Alice's" should be "substitute a key of his own choosing for Bob's". Page 30: Last line: "substitute that key for his own public key" should be "substitute his own key for that public key". Page 32: Ninth line: Delete the word "encrypted". Page 34" "Signing Documents with..." First sentence: "too inefficient to encrypt long documents" should be "too inefficient to sign long documents". Page 36: Second line: "document encrypted with" should be "document signed with". "Multiple Signatures," step (2): "Alice or Bob sends" should be "Alice sends". Page 38: Fifth paragraph: "V_X = E_X and that S_X = D_X" should be "V_X = E_X and S_X = D_X". Page 40: Third line: "computer can exist" should be "computer can be". Second paragraph: Delete "should be runs of zeros and the other half should be runs of ones; half the runs". Page 50: Step (3): "With Alice's public key" should be "with "Alice's" public key." Page 51: Step 5: "with what he received from Bob" should be "with what he received from Alice". Page 55: Step (2): At the end of the step, add: "He sends both encrypted messages to Alice." Page 69: Last line: "tried to recover her private key" should be "tries to recover Alice's private key". Page 73: "Bit Commitment Using One-Way Functions," last paragraph: Second and third sentences should be "Alice cannot cheat and find another message (R_1,R_2',b'), such that H(R_1,R_2',b') = H(R_1,R_2,b). If Alice didn't send Bob R_1, then she could change the value of both R_1 and R_2 and then the value of the bit." Page 77: "Flipping Coins into a Well," first line: "neither party learns the result" should be "Alice and Bob don't learn the result". Third line: parenthetical remark should be: "Alice in all three protocols". Page 78: Step (1): "Alice, Bob, and Carol all generate" should be "Alice, Bob, and Carol each generate". Page 80: Second paragraph, second sentence. It should read: "A general n-player poker protocol that eliminates the problem of information leakage was developed in [228]." Page 90: Last paragraph: "step (3)" should be "step (4)". Page 91: Second line: "step (3)" should be "step (4)". Page 93: "Blind Signatures," first line: "An essential in all" should be "An essential feature of all". Page 98: First paragraph after protocol, fourth line: "to determine the DES key with the other encrypted message" should be "to determine the DES key that the other encrypted message was encrypted in." Page 115: "Protocol #2," third paragraph: "together determine if f(a,b)" should be "together determine f(a,b)". Page 121: Second paragraph: Delete the colon in the third line. Page 131: Fifth paragraph: "each capable of checking 265 million keys" should be "each capable of checking 256 million keys". Page 133: Table 7.2: Third number in third column, "1.2308" should be "0.2308". Page 134: Table 7.3: "1027" should be "10^27". Page 139: Indented paragraph: "could break the system" should be "could break the system within one year". Page 141: "Reduced Keyspaces," last sentence: "don't expect your keys to stand up" should be "don't expect short keys to stand up". Page 148: Eighth line: "2^24" should be "2^32". Page 156: Second paragraph: "blocks 5 through 10" should be "blocks 5 through 12". Page 157: Figure 8.2: "IO" should be "IV". Page 159: Figure 8.3: "IO" should be "IV". Page 161: Figure 8.5: "Decrypt" should be "Encrypt". Page 162: Figure 8.6: "Encipherment" diagram: "Decrypt" should be "Encrypt". Input should be "p_i" instead of "b_i", and output should be "c_i" instead of "p_i". Page 164: Figure 8.7: "IO" should be "IV". Page 165: Last equation: There should be a "(P)" at the end of that equation. Page 167: Second paragraph, last line: "2^(2n-1)" should be "2^(2n-14)". Page 168: Figure 8.8: This figure is wrong. The encryption blocks in the second row should be off-centered from the encryption blocks in the first and third row by half a block length. Page 174: Middle of page: Equations should be: k_2 = c'_2 XOR p', and then p_2 = c_2 XOR k_2 k_3 = c'_3 XOR p_2, and then p_3 = c_3 XOR k_3 k_4 = c'_4 XOR p_3, and then p_4 = c_4 XOR k_4 Page 175: Last paragraph, second line: "acting as the output function" should be "acting as the next-state function". Page 177: Diffie's quote, second to last line: "proposal to built" should be "proposal to build". Page 178: Figure 8.20: In "Node 2", the subscripts should be "D_2" and "E_3". Page 190: Fourth paragraph, last line: "to determine M" should be "to determine P". Page 191: First paragraph: "3.5" should be "6.8". "0.56" should be "0.15". "EBCDIC (Extended Binary-Coded Decimal Interchange Code)" should be "BAUDOT". "0.30" should be "0.76". "0.70" should be "0.24". Page 193: Second sentence: "Unicity distance guarantees insecurity if it's too small, but does guarantee security if it's high" should be "Unicity distance guarantees insecurity if it's too small, but does not guarantee security if it's high." Page 198: Fourth paragraph from bottom, second sentence: "If a and b are positive and a is less than n, you can think of a as the remainder of b when divided by n" should be "If a and b are positive and b is less than n, you can think of b as the remainder of a when divided by n". Page 199: Middle of the page: In the sentence "Calculating the power of a number modulo a number", a should not be italicized. Page 201: First line of code: Remove "assuming x and y are > 0". Page 202: Middle of the page: In the sentence "Now, how do you go about finding the inverse of a modulo n?" "a" should be italicized. Page 207: "Jacobi Symbol," formula: Variable "h" should be "a". Also, J(0,n) = 0. Page 209: Fourth paragraph: "If that value does not equal q" should be "If that value does not equal 1". Page 214: Last line: "n" should be "p". Lines 29, 30, and 31: "r" should be "a", and "gcd(p,r)" should be gcd(a,p)". Page 215: Lehman test, step 5: All three "(n-1)/2" should be exponents. Page 217: There should be an open parenthesis in front of the second "ln" in both exponents. Sixth paragraph: "Guassian" should be "Gaussian". Page 222: "Validation and Certification of DES Equipment," first line: "As part of the standard, the DES NIST" should be "As part of the DES standard, NIST". Page 223: Second to last paragraph, last line. Reference "[472]" should be "[473]". Page 225: Figure 10.2: L_i is taken from R_(i-1) before the expansion permutation, not after. And "L_(i)-1" should be "L_(i-1)". Page 227: Fourth line from bottom: "output positions that correspond" should be "output positions correspond". Page 228: Fourth paragraph, last line: "0 to 16" should be 0 to 15". Page 228: Fifth paragraph should read: "For example, assume that the input to the sixth S-box (that is, bits 31 through 36 of the XOR function) are 110010. The first and last bits combine to form 10, which corresponds to row 2 of the sixth S-box. The middle four bits combine to form 1001, which corresponds to column 9 of the same S-box. The entry under row 2, column 9 of S-box 6 is 0. (Remember, we count rows and columns from 0, and not from 1.) The value 0000 is substituted for 110010. Page 231: Table 10.9, sixth line: "80286" should be "80386". Page 233: The second two weak keys should be: 1F1F 1F1F 0E0E 0E0E 00000000 FFFFFFFF E0E0 E0E0 F1F1 F1F1 FFFFFFFF 00000000 Page 238: Next to last line before "Additional Results": "NSA's" should be "IBM's". Page 238: "Differential Cryptanalysis," third paragraph: "(1/16)^2" should be "(14/64)^2". Page 239: Figure 10.4: "14/16" should be "14/64". Page 242: Table 10.14: In "XORs by additions" line, "2^39,2^3" should be "2^39,2^31". In "Random" line, "2^21" should be"2^18- 2^20". In "Random permutations" line, "2^44-2^48" should be"2^33-2^41". Page 245: Line 11" "8 bits is" should be "8 bits was". Page 247: Section heading, "Cryptanalysis of the Madryga" should be "Cryptanalysis of Madryga". Page 250: The two functions should be: S_0(a,b) = rotate left 2 bits ((a+b) mod 256) S_1(a,b) = rotate left 2 bits ((a+b+1) mod 256) Note the difference in parentheses. Page 250: Figure 11.4: Note that a is broken up into four 8-bit substrings, a_0, a_1, a_2, and a_3. Page 251: Figure 11.6: The definitions for S_0 and S_1 are incorrect ("Y = S_0" and "Y = S_1"). See corrections from previous page. Also, "S1" should be "S_1". Page 254: "Security of REDOC III," second sentence. Delete clause after comma: "even though it looks fairly weak." Page 262: Figure 11.9: There is a line missing. It should run from the symbol where Z_5 is multiplied with the intermediate result to the addition symbol directly to the right. Page 263: Table 11.1: The decryption key sub-blocks that are Z_n^(m)-1 should be Z_n^((m)-1). Also, the second and third column of decryption key sub-blocks in rounds 2 through 8 should be switched. Page 265: Figure 11.10: There is a line missing. It should run from the symbol where Z_5 is multiplied with the intermediate result to the addition symbol directly to the right. Pages 266-7: Since the publication of this book, MMB has been broken. Do not use this algorithm. Page 267: Sixth line from bottom: Reference should be "[256]". Page 269: "Skipjack." First paragraph. Reference should be "[654]". Page 270: "Karn." Third paragraph. Last sentence: "append C_r to C to produce" should be "append C_r to C_l to produce". Page 271: Middle of the page: "(for example, MD2, MD5, Snefru" should be "(for example, MD2, MD4, Snefru". Page 272: Second to last line: "But it is be analyzed" should be "but it is being analyzed". Page 275: Second to last paragraph: "Using 1028 bits" should be "using 1024 bits". Page 277: First lines: The correct street address is "310 N Mary Avenue" and the correct telephone number is "(408) 735-5893". Page 281: Third paragraph: The correct street address is "310 N Mary Avenue" and the correct telephone number is "(408) 735-5893". Page 283: Table 12.2: "PRIVATE KEY: d e^(-1)" should be "PRIVATE KEY: d = e^(-1)". Page 286: Third paragraph: "Eve gets Alice to sign y," "y" should be italicized. Second to last line: "Eve wants to Alice to" should be "Eve wants Alice to". Page 287: Last line: Wiener's attack is misstated. If d is less than one-quarter the length of the modulus, then the attack can use e and n to find d quickly. Page 288: The correct street address is "310 N Mary Avenue" and the correct telephone number is "(408) 735-5893". Page 289: The correct street address is "310 N Mary Avenue" and the correct telephone number is "(408) 735-5893". Page 292: Fifth line: "sqrt(x/v)" should be "sqrt(1/v)". Page 294: Second and third lines: "Bob" should be "Victor." Page 295: First line: "t random integers fewer than n" should be "t random numbers less than n". Page 297: Last line: "when" should be "where". Page 301: Middle of the page: Delete the sentence "Since the math is all correct, they do this step." Page 302: Fourth line from bottom: "a" should be in italics. Page 303: "Authentication Protocol," step (1): Add "She sends x to Victor." Page 305: Third paragraph, parenthetical remark: "NIST claimed that having DES meant that both that both the algorithm and the standard were too confusing" should be "NIST claimed that having DES mean both the algorithm and the standard was too confusing". Page 306: Eighth line: "cryptographers' paranoia" should be "paranoia". Page 307: "Description of the Algorithm": "p = a prime number 2^L bits long" should be "p = a prime number L bits long". "g = h^((p-1)/q)" should be "g = h^((p-1)/q) mod p". Page 309: Third line: "random k values and then precompute r values" should be "random k-values and then precompute r-values". Page 314: Protocol, step (1): "when" should be "where". Page 319: There should be a blank line before "discrete logarithm:" and another before "factoring:". Fourth line from the bottom: "depends more on the" should be "depends on more than the". Page 321: Third line: "when h" should be "where h". Page 322: Second paragraph: "over 500 pairs of people" should be "253 pairs of people". Page 326: In the definition of h_i, "H_(i-1)" should be "h_(i- 1)". Page 330: Definitions of FF, GG, HH, and II are wrong. These are correct: FF: "a = b + ((a + F(b,c,d) + M_j + t_i) <<< s)" GG: "a = b + ((a + G(b,c,d) + M_j + t_i) <<< s)" HH: "a = b + ((a + H(b,c,d) + M_j + t_i) <<< s)" II: "a = b + ((a + I(b,c,d) + M_j + t_i) <<< s)" Page 336: "HAVAL," sixth line: "160, 92, 224" should be "160, 192, 224". Page 339: "LOKI Single Block": In computation of Hi, drop final "XOR M_i". Page 340: "Modified Davies-Meyer": In computation of H_i, "M_i" should be subscripted. Page 342: "Tandem Davies-Meyer": In computation of W_i, "M_i" should be subscripted. Page 345: "Stream Cipher Mac", first line:" "A truly elegant MDC" should be "A truly elegant MAC". Page 347: Formula: "aX_(n1)" should be "aX_(n-1)". Second paragraph: "(For example, m should be chosen to be a prime number.)" should be "(For example, b and m should be relatively prime.)" Page 351: Second line of text: "they hold current" should be "they hold the current". Page 353: Tenth line (in source code): "< 31" should be "<< 31". Second paragraph: "are often used from stream-cipher" should be "are often used for stream-cipher". Page 356: Source code: "ShiftRegister = (ShiftRegister ^ (mask >> 1))" should be "ShiftRegister = ((ShiftRegister ^ mask) >> 1)". Page 360: Equation should not be "l(2^1-1)^(n-1)", but "l(2^l- 1)^(n-1)". Page 362: Figure 15.10: "LFSR-B" should be "LFSR-A" and vice versa. The second "a(t+n-1)" should be "a(t+n-2)", and the second "b(t+n-1)" should be "b(t+n-2)". Page 363: Fourth paragraph: "cellular automaton, such as an CSPRNG" should be "cellular automaton as a CSPRNG". Page 365: "Blum-Micali Generator": In the equation, "x_i" should be an exponent of a, not a subscript. Page 367: Paragraph 5: "Ingmar" should be "Ingemar". Page 370: "Using "Random Noise," first paragraph, last line: "output 2 as the event" should be "output 0 as the event". Page 371: Sixth line: "access/modify times of/del/tty" should be "access/modify times of /dev/tty". Page 371: "Biases and Correlations," third line: "but there many types" should be "but there are many types". Page 376: Seventh line: "send a message, M" should be "send a message, P". Page 391: Second protocol, step (1): "in his implementation of DES" should be "in his implementation of DSS". Next sentence: "such that r is either q quadratic" should be "such that r is either a quadratic". Page 402: First line: "when" should be "where". Line 18: "2^t" should be "2^(-t)". Page 406: Step (5): "ij". Page 417: Last paragraph: "Kerberos is a service Kerberos on the network" should be "Kerberos is a service on the network". Page 421: Figure 17.2: In the top message "C" should be lower case. Page 435: "RIPEM": "Mark Riorden" should be "Mark Riordan". Page 436: "Pretty Good Privacy," third paragraph: Delete fourth sentence: "After verifying the signature...." Page 436: Pretty Good Privacy is not in the public domain. It is copyrighted by Philip Zimmermann and available for free under the "Copyleft" General Public License from the Free Software Foundation. Page 437: Fifth line: Delete "assess your own trust level". "Clipper," second paragraph: reference should be "[473]". Fourth paragraph: references should be "[473,654,876,271,57]". Page 438: Middle of page: reference should be "[654]". "Capstone," first paragraph: reference should be "[655]". Page 445: The IACR is not the "International Association of Cryptographic Research," but the "International Association for Cryptologic Research." This is also wrong in the table of contents. Source Code: The decrement operator, "--", was inadvertently typesetted as an m-dash, "-". This error is on pages 496, 510, 511, 523, 527, 528, 540, and 541. There may be other places as well. Page 472: "for( i = 0; i<<16; i++ )" should be "for( i = 0; i<16; i++ )". Page 473: Function "cpkey(into)". "while (from endp)" should be "while (from < endp)". Page 508: Line 8: "union U_INITseed" should be "union U_INIT seed". Page 531: "for( i = 0; i<; i++ )" should be "for( i = 0; i<2; i++ )". Page 558: "#defineBOOLEAN int" should be "#define BOOLEAN int", "#defineFALSE0" should be "#define FALSE 0", and "#defineTRUE(1==1)" should be "#define TRUE (1==1)". Page 564: "#define BOOLEANint" should be "#define BOOLEAN int", "#define FALSE0" should be "#define FALSE 0", and "#defineTRUE(1==1)" should be "#define TRUE (1==1)". Page 569: "rand() > 11" should be "rand() >> 11". Page 569: In "G13.H", "#define G13int" should be "#define G13 int". Page 572: Reference [45]: "Haglen" should be "Hagelin". Page 576: References [136] and [137]: "Branstead" should be "Branstad." Page 578: Reference [184] "Proof that DES Is Not a Group" should be "DES Is Not a Group." The correct page numbers are 512-520. Page 589: Reference [475]: The publisher should be E.S. Mittler und Sohn, and the publication date should be 1863. Page 601: References [835] and [836]: "Branstead" should be "Branstad." Page 602: Reference [842]: "Solvay" should be "Solovay". Page 603: Reference [878]: "Weiner" should be "Wiener." This errata is updated periodically. For a current errata sheet, send a self-addressed stamped envelope to: Bruce Schneier, Counterpane Systems, 730 Fair Oaks Ave., Oak Park, IL 60302; or send electronic mail to: schneier at chinet.com. From warlord at MIT.EDU Tue Mar 1 12:41:05 1994 From: warlord at MIT.EDU (Derek Atkins) Date: Tue, 1 Mar 94 12:41:05 PST Subject: low-overhead encrypted telnet In-Reply-To: <9403011958.AA09178@hot.ee.lbl.gov> Message-ID: <9403012040.AA00412@toxicwaste.media.mit.edu> Couple of comments: 1) Kerberos *does* work between corporate entities. I can, for example, go to Iastate (ISU) and get MIT Kerberos tickets, and then rlogin -x to MIT, encrypting the session (I can, and I have). Also, it is possible (and I know someone who is doing it at this moment) for someone from ISU, with ISU tickets, to log into an account here at MIT. 2) Using your example, a user on host A telnets to host B, and from host B they telnet to host C, if the A<->B link is encrypted, then so long as the user trusts host B, then A<->C is secure as well (assuming B<->C is encrypted). 3) Just encrypting from client->server will not necessarily reduce the load on the server. Also, doing something like DES is really not a very high CPU operation, IMHO. Maybe a better protocol than the one done in rlogin -x is in order (this sends 8 characters over the link for every successful "read", which means you can be getting anywhere from 100% down to 12% throughput of plaintext in the cyphertext!) 4) Charon, which is based upon Kerberos, was developed exactly for this type of problem: you want to authenticate securely over links which may not otherwise be secure, but you trust the CPU in front of you! The paper describing Charon is available via anonymous ftp: ftp://toxicwaste.mit.edu/pub/charon/thesis.ps.Z Enjoy! -derek From fnerd at smds.com Tue Mar 1 12:43:48 1994 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Tue, 1 Mar 94 12:43:48 PST Subject: Security is TWO Rubber Stamps Message-ID: <9403011948.AA06577@smds.com> Ludwig R. Vogel's letter to New York Newsday makes the point, "...Government intercept procedures involving Clipper technology offer users no more protection from wrongful government surveillance than plain text." FBI guys say they only want to keep the abilities they already have. Vogel turns it around: they want to make sure we have no more protection against them than we already have...except for key escrow... America's Bulwark Against Corruption! Every citizen has the right to the protection of Two Rubber Stamps!* So wear your rubber stamps today, America! +----------------------+ | APPROVED FOR WIRETAP++---------------------+ | U.S. Treasury |+APPROVED FOR WIRETAP | +---------------------++ N.I.S.T. | +----------------------+ *Offer void under certain circumstances that cannot be discussed. -fnerd did i get the two agencies right? quote me - - - - - - - - - - - - - - - We shall have to evolve Problem solvers galore As each problem they solve Creates ten problems more. --Piet Hein -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE----- From MJMISKI at macc.wisc.edu Tue Mar 1 12:53:00 1994 From: MJMISKI at macc.wisc.edu (Matthew J Miszewski) Date: Tue, 1 Mar 94 12:53:00 PST Subject: On encrypted Logins Message-ID: <24030114501849@vms2.macc.wisc.edu> Does anyone have information on the actual overhead of encrypted logins. What besides telnetd need be modified, specifically? Jef makes an interesting idea for cost containment. Jef, what exactly would y --Matt ______________________________________________________________________________ In defense of liberty, encrypt for all purposes, civil and professional. In defense of privacy, encrypt all correspondence, personal and professional. In defense of sanity, do not encrypt your dry cleaning invoice! ++++++++--------mjmiski at macc.wisc.edu (c)1993 From MJMISKI at macc.wisc.edu Tue Mar 1 12:53:22 1994 From: MJMISKI at macc.wisc.edu (Matthew J Miszewski) Date: Tue, 1 Mar 94 12:53:22 PST Subject: welp. Message-ID: <24030114513424@vms2.macc.wisc.edu> Well now, that message got crunched. I meant to say Jef, what exactly would need to be modified using your monodirictional approach? --Matt ______________________________________________________________________________ In defense of liberty, encrypt for all purposes, civil and professional. In defense of privacy, encrypt all correspondence, personal and professional. In defense of sanity, do not encrypt your dry cleaning invoice! ++++++++--------mjmiski at macc.wisc.edu (c)1993 From hughes at ah.com Tue Mar 1 13:26:43 1994 From: hughes at ah.com (Eric Hughes) Date: Tue, 1 Mar 94 13:26:43 PST Subject: Insecurity of public key crypto #1 (reply to Mandl) In-Reply-To: Message-ID: <9403012118.AA08046@ah.com> >Only "sensitive" information is worth encrypting and if you want to >stay out of trouble you don't go giving sensitive information to >someone you don't know. If part of your communications are encrypted and part are not you have sent the message about what information is sensitive and what is not. This difference in encoding is a fir-class message in it's own right. Therefore _all_ communications should be encrypted at all time. It is no argument against the principle that this is difficult to do at the current time. Eric From jef at ee.lbl.gov Tue Mar 1 13:27:15 1994 From: jef at ee.lbl.gov (Jef Poskanzer) Date: Tue, 1 Mar 94 13:27:15 PST Subject: low-overhead encrypted telnet Message-ID: <9403012126.AA09307@hot.ee.lbl.gov> >1) Kerberos *does* work between corporate entities. In practice, no, it doesn't. This is not a technical problem, but it's nevertheless quite real. You will never see inter-realm Kerberos set up at places line netcom, because netcom's sysadmins have better things to do than manage secret keys for every organization that wants to connect. Only a system with completely automated configuration and operation has a chance. >2) Using your example, a user on host A telnets to host B, and from >host B they telnet to host C, if the A<->B link is encrypted, then so >long as the user trusts host B, then A<->C is secure as well (assuming >B<->C is encrypted). Yes, of course, if the A<->B link is encrypted then subsequent logins are secure. The point is to find a way to secure those logins *without* full encryption of the A<->B link. >3) Just encrypting from client->server will not necessarily reduce the >load on the server. In practice, almost all of the time, it will. >Also, doing something like DES is really not a >very high CPU operation, IMHO. Personally I agree with this. Most sysadmins will not. >4) Charon, which is based upon Kerberos, was developed exactly for >this type of problem: you want to authenticate securely over links >which may not otherwise be secure, but you trust the CPU in front of >you! The paper describing Charon is available via anonymous ftp: > ftp://toxicwaste.mit.edu/pub/charon/thesis.ps.Z I'll check this out, but if it's based on Kerberos it's probably useless for the reasons mentioned above. --- Jef From nates at netcom.com Tue Mar 1 13:30:14 1994 From: nates at netcom.com (Nate Sammons) Date: Tue, 1 Mar 1994 13:30:14 -0800 (PST) Subject: Colorado Cypherpunks meeting Message-ID: <199403012130.NAA13994@mail.netcom.com> From warlord at MIT.EDU Tue Mar 1 13:49:25 1994 From: warlord at MIT.EDU (Derek Atkins) Date: Tue, 1 Mar 94 13:49:25 PST Subject: low-overhead encrypted telnet In-Reply-To: <9403012126.AA09307@hot.ee.lbl.gov> Message-ID: <9403012149.AA00966@toxicwaste.media.mit.edu> > I'll check this out, but if it's based on Kerberos it's probably > useless for the reasons mentioned above. Charon does not require any shared kerberos. All it does require is that the destination server have an rcmd srvtab, and the user have a kerberos principal that can authenticate to that server in some form. To use your netcom example, if netcom had their own kerberos realm, and if they were running the Charon server, then anyone with a Charon client and a netcom account could securely authenticate to their netcom account, no matter where they were actually coming from. -derek From hughes at ah.com Tue Mar 1 14:08:16 1994 From: hughes at ah.com (Eric Hughes) Date: Tue, 1 Mar 94 14:08:16 PST Subject: on international transmissions In-Reply-To: <9402270646.AA25163@prism.poly.edu> Message-ID: <9403012200.AA08101@ah.com> The situation: -- non-USA person retains a USA-based email service -- this person forwards mail to non-USA machine -- this person requests crypto software be sent to the USA email address -- another person sends software to the USA address -- the forwarding works and the software is shipped outside the USA >This way, the author has not broken the law by sending the software >to anysite.com, This is correct, since the sender of the crypto was told that the address was a US place. If, however, the sender of the crypto knows that it will be automatically forwarded outside of the country, the they become liable because they have prior knowledge of the consequences of their actions. >and I haven't either because all I did was to tell >the unix box to forward my mail out of the country. Such a direction is not improper _per se_, but the combination with a request to have crypto software sent to that address means that the requester has prior knowledge that the request will cause crypto software to be exported across US boundaries. And that prior knowledge creates liability. >Neither I nor Joey_CryptoAuthor broke ITAR. Not really. Not >intentionally. Incorrect. The person who sets up forwarding with the intention of moving crypto software automatically outside of the country is in violation. But since I am not a lawyer I feel compelled to point out that the cost of extradition of random people to the USA for trial under USA laws is expensive and difficult, the most recent high-profile example being Noriega. In addition, detection of such an action will be difficult at best, and near impossible to prove if encryption is used. Proof that software was exported in encrypted mail would require at least the following: -- a copy of a particular piece of mail claimed to contain encryption software -- evidence that this particular piece of encrypted mail did in fact contain encryption software -- evidence that a particular piece of encrypted mail was sent outside of the country at a particular time and between two given machines So, someone has to supply the authorities with a copy of the mail, with a decryption of the mail, and with mailer logs evidencing a transmission across USA borders. Mailer logs are typically purged after a week or two. So if the intermediate machine has purged logs and the .forward file is gone, there will be precious little direct evidence left of an actual transmission. If the encryption is addressed to only the receiver, and if the sender did not keep a record of the session key, only the receiver can provide the session key. The session key is necessary to show that a given piece of encrypted mail is an encrypted copy of a particular piece of software. And unless the NSA or the intermediate machine or the sender provides a copy of the particular piece of mail, there's no fact in evidence that any software was actually sent. Of course, if the sender is out to sting you and ther intermediary provides logging information, one might get screwed. But then again, all intermediaries would have to cooperate, were there more than one. And finally, I have written so much only to point out that legality and enforceability are two very different things. Eric From hughes at ah.com Tue Mar 1 14:19:35 1994 From: hughes at ah.com (Eric Hughes) Date: Tue, 1 Mar 94 14:19:35 PST Subject: Proposal: Another emergency session of Cypherpunks In-Reply-To: <199402262029.MAA19813@mail.netcom.com> Message-ID: <9403012211.AA08138@ah.com> >Summary: Maybe it's time for another emergency session of Cypherpunks >to discuss policy in the aftermath of the double whammy announcements >of Tessera/Clipper II and the new and even more dangerous Digital >Telephony Bill. Since such a meeting would be only one week before our regular meeting, and since we had ignorantly but presciently scheduled the topic to be "Politics", I see no need. >It'd also be nice if some of the outlying groups (Cambridge, MA, >Washington, D.C., London, Colorado, Austin) could link up with us at >least briefly. [Background: we did voice-over-IP for the emergency meeting last year right after clipper came out.] I'd like to do this again. Can those who are interested in setting up this technically contact me directly for coordination? Also, for those who did it last time, even if you won't be doing it this time, I'd like to hear from you. And if someone can get us an MBONE channel for this, I'd be willing to carry two or three hours of the meeting on a broadcast-only basis. >(If we started at noon, California time, that would be >fine for the East Coasters, but 8 or 9 p.m. for the Londoners....does >the London group still meet?) We'll be meeting at the same time, noon on the second Saturday, as we always do. Eric From wcs at anchor.ho.att.com Tue Mar 1 14:39:49 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Tue, 1 Mar 94 14:39:49 PST Subject: stego Message-ID: <9403012217.AA05764@anchor.ho.att.com> Jim Choate's comments on steganography having problems with images that are too complex or too simple were interesting. Obviously, cartoon-like GIFs aren't a good target, though scanned real stuff may be fine. Weather maps cna be good - back when I worked with the things, I found you could really see about5-6 bits worth of depth, and after that it didn't usually look much different - we stole one or two values from the color-map to draw lines on the satellite images to add state boundaries, various data values, etc., but could have stolen the LSB and maybe 7th bit without major loss on cloud-image pictures. (Radar pictures, on the other hand, were almost all black, with one or two other pixel values, compressed to 2% of original size, and would have been useless for hiding anything in.) Bill From karn at qualcomm.com Tue Mar 1 15:11:31 1994 From: karn at qualcomm.com (Phil Karn) Date: Tue, 1 Mar 94 15:11:31 PST Subject: Proposal: Another emergency session of Cypherpunks In-Reply-To: <9403012211.AA08138@ah.com> Message-ID: <199403012311.PAA11250@servo.qualcomm.com> If you were to carry the Cypherpunks meeting over the MBONE, which I assume you mean, I'd definitely be interested in joining in from San Diego. Phil From hughes at ah.com Tue Mar 1 15:31:54 1994 From: hughes at ah.com (Eric Hughes) Date: Tue, 1 Mar 94 15:31:54 PST Subject: On meetings Message-ID: <9403012324.AA08378@ah.com> Tim asked me to clarify the bit about emergency meetings. I thought he was consider moving the meeting time, among other things. He was not. I mistook his article. Sorry for the misunderstanding. Eric From unicorn at access.digex.net Tue Mar 1 15:35:05 1994 From: unicorn at access.digex.net (Black Unicorn) Date: Tue, 1 Mar 94 15:35:05 PST Subject: Dorothy Denning Message-ID: <9403012335.AA01986@toad.com> -> Also, I've gotten a message through to Ross Perot about our fight against Clipper, and how to reach me, so if I get a response, I'll let you guys know. Anthony <- Oh god, that is all the cause needs. I can see it now: "Transistor brain Ross Perot opposes it! It must be evil!" From m5 at vail.tivoli.com Tue Mar 1 15:35:52 1994 From: m5 at vail.tivoli.com (Mike McNally) Date: Tue, 1 Mar 94 15:35:52 PST Subject: Problems w/ Clipper In-Reply-To: Message-ID: <9403012335.AA02003@toad.com> Anthony D Ortenzi writes: > 1) Most of us are concerned not with our own privacy if other forms of > encryption are not banned. I don't understand this; what it seems to say, I disagree with completely and suspect everyone else does too. > 2) Collectively, we seem to agree that letting the Government into our > lives in such a way as Clipper provides is not necessarily all that > evil... I completely disagree, and I suspect most other c'punks do as well. > Am I right? I don't think so. > (trying to center the discussion) ...but your motive is good. -- | GOOD TIME FOR MOVIE - GOING ||| Mike McNally | | TAKE TWA TO CAIRO. ||| Tivoli Systems, Austin, TX: | | (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" | From wcs at anchor.ho.att.com Tue Mar 1 15:36:14 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Tue, 1 Mar 94 15:36:14 PST Subject: DES Question Message-ID: <9403012336.AA02022@toad.com> Matthew Ghio writes: > When using DES to encrypt email addresses, the total amount of data to > be encrypted would be only 3 or 4 eight-byte DES blocks. My question > is: Would CBC or CFB really be effective for such a small amount of data Assuming you're using a random initialization vector rather than zeros, yes, CBC or CFB should be quite effective - the first real block is essentially XORed with random junk, though of course if they guess the right key they can check that the block comes out reasonably. But it does prevent a brute-force attack where they decrypt and see if they get ASCII, since they first block is random junk - they're forced to decrypt at least two blocks of data, which is somewhat annoying for brute-force-search machines. Bill From andy at autodesk.com Tue Mar 1 15:36:41 1994 From: andy at autodesk.com (Andrew Purshottam) Date: Tue, 1 Mar 94 15:36:41 PST Subject: Dorothy Denning In-Reply-To: <199402282142.NAA00899@servo.qualcomm.com> Message-ID: <9403012336.AA02039@toad.com> Dr. Denning is a secure systems (OS and databases) research from SRI. Her background is in capability-based OS (her advisor was MUTICS designer Peter Denning, whom she married) and inference of private data from statistical data bases. Her work is interesting and potentially contributes to our privacy, but has little direct connection to cryptanalysis. Phil's objection seems quite reasonable. I recall a profile of the Dr's Denning in one of the popular cracker/phreax exposes, (maybe in Markov/Hafner?) Andy From wcs at anchor.ho.att.com Tue Mar 1 15:42:38 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Tue, 1 Mar 94 15:42:38 PST Subject: ditz in office Message-ID: <9403012341.AA08259@anchor.ho.att.com> (I voted Libertarian, of course; back in '84 I had wasted my vote on (yuk) Mondale because he was the closest to a credible threat to Reagan, and it only encouraged them to get another useless Democrat the next time. If there hadn't been a Lib running, I would have probably voted for Perot just for the chaos factor, though I didn't particularly trust him.) I had, however, hoped that Clinton, as a tax&spend Democrat, would at least bring in some of the Liberal virtues along with the Liberal vices, which would be better than a George Bush who had the vices of the conservatives with none of the virtues. Unfortunately, I've been disappointed, in spite of how low my expectations already were :-) Somebody who favors national ID cards, concentration camps for non-violent political offendors, allowing the Federal cops to burn down the homes of uncooperative religious groups if they won't surrender, restrictions on free speech to keep the cops happy, wiretaps for everyone, and stuff like that is *clearly* no liberal. Some columnist, probably George Will, described him as a "passionate hypocrite", which seems to fit reasonably well. I'd hoped for someone genuinely passionate about something, and I don't see that in him. (Nobody could describe George Bush that way, of course, since the man's clearly not passionate about anything....) Bill Stewart, ranting about politics again.... From fhalper at pilot.njin.net Tue Mar 1 15:46:00 1994 From: fhalper at pilot.njin.net (Frederic Halper) Date: Tue, 1 Mar 94 15:46:00 PST Subject: Applied Crypto Message-ID: <9403012345.AA19252@pilot.njin.net> Does anyone know if Project Guttenberg(or anyone else) has electronic books such as applied cryptography? Thanks, Reuben Halper From wcs at anchor.ho.att.com Tue Mar 1 15:56:51 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Tue, 1 Mar 94 15:56:51 PST Subject: Dorothy Denning Message-ID: <9403012355.AA08431@anchor.ho.att.com> I objected to Anthony Ortenzi's article on Dorothy Denning. Much of the attacks seemed appropriate for a politician like Clinton (:-)), but aren't appropriate for an academic who's doing politics about technical areas, where there so much more *useful* ways to flame her ideas, rather than her character. > Number 1, if someone is an encryption expert [...], why would they endorse > anyone but the recipient being able to decode the message? You're confusing technical tactics with political/social goals. She's an expert in what you can do with encryption, she just has different values about who should be able to benefit from it and how. > Number 2. [Newsday...] > The argument was just very, well, flimsy is the word I guess. I thought so too. Part of it was from writing for a non-technical audience, but some of her arguments have been appallingly weak. El Rukn was a particularly bad example :-), and as you say, it would be nice if she'd just come out and say the government should spy on all of us to keep us from doing Bad Things; it's an argument people can relate to and discuss (though it'll get a lot of negative reaction, which is not her objective.) > Anyone know: > A) Is she an expert in cryptography? Yes - her book from the early 1980s was *the* standard text on crypto for quite a few years, and she's published some other reasonable papers. Dr. Denning is department head of CS or EE or something at Georgetown. > C) Was she dropped on her head a lot as a baby? Probably got scared by a Commie Terrorist Drug Dealer, and comforted by some friendly federal police officer... or else was educated in government-run schools. :-) > Also, I've gotten a message through to Ross Perot about our fight > against Clipper, and how to reach me, so if I get a response, I'll let Clipper sounds like just the kind of thing Perot would enjoy. Bill From wcs at anchor.ho.att.com Tue Mar 1 16:08:32 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Tue, 1 Mar 94 16:08:32 PST Subject: The answer. Message-ID: <9403020006.AA08655@anchor.ho.att.com> > I think I have found the way to end all our problems: ESP. No good - the KGB has top psychics working for them, and the CIA has been working for years to keep up. I read it in the newspaper in the supermarket, so it must be true! Bill From ejohnson at pmip.dist.maricopa.edu Tue Mar 1 16:20:24 1994 From: ejohnson at pmip.dist.maricopa.edu (Eric Johnson) Date: Tue, 1 Mar 94 16:20:24 PST Subject: Insecurity of public key crypto #1 (reply to Mandl) Message-ID: <199403020015.RAA21139@pmip.dist.maricopa.edu> : >Only "sensitive" information is worth encrypting and if you want to : >stay out of trouble you don't go giving sensitive information to : >someone you don't know. : : If part of your communications are encrypted and part are not you have : sent the message about what information is sensitive and what is not. : This difference in encoding is a fir-class message in it's own right. : : Therefore _all_ communications should be encrypted at all time. It is : no argument against the principle that this is difficult to do at the : current time. : : Eric : Would it not make sense, therefore, to publish a public cypherpunks mailing list key, which is returned with subscription requests? All incoming message cleartext to the mailing list server would then be encrypted in the server's key; not for security, but precisely for the reason you state above. That _would_ create quite a volume of encrypted communications to each receipient of the list. --Eric From wcs at anchor.ho.att.com Tue Mar 1 16:22:55 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Tue, 1 Mar 94 16:22:55 PST Subject: I have FOIA'd the Clipper Key Escrow databases Message-ID: <9403020004.AA08640@anchor.ho.att.com> Eric Hughes writes: > Should John's FOIA request for the clipper key database work, it > creates a wonderful hole in the entire key custody system. > It would require a legislative act to plug the hole. Not necessarily - they may be able to claim there's a criminal investigation in progress (one of the standard FOIA loopholes) or they may lose the first round if there isn't one in progress so they'd have to go start investigating somebody (for corruption in government, or spies in the CIA, if nothing else is available :-) Since they don't know who the spy is, or who has which phone, everybody's key must obviously be relevant evidence... But it's clearly a fun opportunity. > Now, how many legislators do you know that are going to make a public > record by voting in favor of Big Brother? If the President supports it, why not a bunch of his fellow politicians? Bill From ritter at cactus.org Tue Mar 1 16:25:01 1994 From: ritter at cactus.org (Terry Ritter) Date: Tue, 1 Mar 94 16:25:01 PST Subject: Large Block DES Newsletter Message-ID: <9403020024.AA06224@cactus.org> Large Block DES Newsletter Vol. I, No. 1 Feb. 28, 1994 Terry Ritter, Ed. Current Standings for the Large-Block DES Proposals: I. NxM DES: A B v v k1 -> DES1 k2 -> DES2 v v C D Exchange Right 4 Bytes E F v v k3 -> DES3 k4 -> DES4 v v G H Falls to meet-in-the-middle like double-DES. Falls to a practical attack by Biham, now called "fix-in-the-middle." II. NxM DES Found Weak Announcement of above. III. Isolated Double-DES 2x construct found weak in original article. The 1x construct: A v k1 -> DES1 v B v km -> XOR v C v k2 -> DES2 v D was found weak by Chris Dodd who pointed out that two different blocks of known-plaintext (A,D) and (A',D') will allow matching (B XOR B') and (C xor X'). (This is similar to Biham's "fix-in-the-middle.") Good going Chris! Also found by Stefan Lucks . IV. Ladder-DES A B | k1 | v v | XOR <- DES1-----| | | | k2 | | v v |---- DES2 -> XOR | | | k3 | v v | XOR <- DES3 ----| | | | k4 | | v v |---- DES4 -> XOR | | v v C D Joseph C. Konczal points out that the construct is indeed vulnerable to meet-in-the-middle. I agree, but note that this seems to imply a 112-bit search. Since we don't need more than 112 or 120 bits of strength, I don't see it as a problem. (Indeed, if we could get more strength, we might want to trade it for speed anyway.) 112 bits (or so) is the design goal, which should be enough for a couple of decades. In a normal cipher design, I would expect each key bit to contribute toward strength, but these are hardly normal cipher designs. Especially when we try to expand block size, extra keys may simply provide another small block with the same strength as a previous small block. Keys will be delivered electronically, so the relatively rare delivery of 2x or 4x or even 8x the expected key material should not pose a serious problem. However, Biham reports: "ladder DES is not more secure than 2**88 steps and 2**64 chosen plaintexts." Now, 2^88 cipherings is 2^32 times as strong as the 2^56 currently in DES (and larger than Skipjack), but hardly the 2^112 intended. For the current design the current options are: 1) live with the 2^88 strength (so far!), 2) design the rest of the system to prevent chosen plaintexts, or 3) prevent more than, say, 2^32 block cipherings under a single key. Actually, we need to know exactly what the problem is, and the limits of it, before we can propose a fix, or decide whether the ladder-DES scheme is unfixable. Summary Three substantially different constructs proposed; of these, two fall, and one is wounded. To review, the intent is to find some relatively-simple construct which builds on the assumed strength of DES to deliver wide blocks and something like 112 bits of strength, with less processing than triple-DES. (I see no need for super-strength, unless it is free.) We still do not know whether or not this is possible. From fnerd at smds.com Tue Mar 1 16:43:10 1994 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Tue, 1 Mar 94 16:43:10 PST Subject: Fax / Modem question Message-ID: <9403012238.AA07514@smds.com> (Please respond to this question by private email.) Is it possible to set up most fax/data modems to be ready to receive calls from either fax machines or data modems? If so, in this mode, does it make the beep that sets a calling fax machine going, or does the caller have to push a button to initiate the connection from his or her side? Ditto for data. Doesn't the answer side usually put out the first beep? -fnerd please reply to: fnerd at smds.com - - - - - - - - - - - - - - - blue mass, Pharm. a preparation of metallic mercury with other ingredients, used for making blue pills. -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE----- From fischer at charybdis.prl.ufl.edu Tue Mar 1 16:49:18 1994 From: fischer at charybdis.prl.ufl.edu (G R Fischer) Date: Tue, 1 Mar 94 16:49:18 PST Subject: Dorothy Denning Message-ID: <9403020050.AA24854@charybdis.prl.ufl.edu> > I recall a profile of the Dr's Denning in one of the > popular cracker/phreax exposes, (maybe in Markov/Hafner?) > > Andy I believe you are referring to Bruce Sterling's "The Hacker Crackdown", interesting book because Sterling sympathetically presents many sides: paranoid telco's, testosterone-poisoned adolescent hackers, hand-wringing cops (Dr. Denning is presented in this milieu) and (my personal favorite) the "information wants to be free" libertarians. Randy Fischer From smb at research.att.com Tue Mar 1 16:57:19 1994 From: smb at research.att.com (smb at research.att.com) Date: Tue, 1 Mar 94 16:57:19 PST Subject: PGP on the HP 100 Message-ID: <9403020057.AA03418@toad.com> Has anyone tried putting ViaCrypt PGP on the HP-100? Is anyone but me crazy enough to contemplate it? How abysmal is the performance? --Steve Bellovin From schneier at chinet.com Tue Mar 1 17:10:57 1994 From: schneier at chinet.com (Bruce Schneier) Date: Tue, 1 Mar 94 17:10:57 PST Subject: Cryptography Articles in April 94 Dr Dobbs Journal Message-ID: Check out the April 94 issue of Dr. Dobbs Journal. There are four articles on cryptography, and a cryptanalysis contest. The first article is by myself, about the Cambridge Algorithms Workshop last November. The topic of the workshop was high-speed encryption, and ten complete algorithms were presented. The article discusses the workshop, briefly mentions the algorithms, and talks a little about designing secure algorithms. The second article, by Peter Smith, talks more about the LUC cipher. If you remember his article in the Jan 93 DDJ, LUC is an RSA variant that uses Lucas functions instead of exponentiation. Even though Smith claims to have invented this scheme, it has been around since the early 1980s (see p. 318 of my book). In any case, it's a good article. William Stalling's article is about SHA. It explains how the algorithm works very nicely. (If this is any indication of how his new book will look, I am looking forward to it.) And finally, I have an article describing a new secret-key algorithm: Blowfish. I presented Blowfish at the Cambridge Workshop. The article includes a description of the algorithm and source code (that hopefully will compile on any machine--call me if you have problems). DDJ is sponsoring a cracking context for Blowfish. You don't have to break the entire algorithm, just finding a weakness is sufficient. The best attack received by 1 April 1995 wins. Awards are $750 for first place, $250 for second, and $100 for third. Subscribers should expect to receive their copy of the magazine in a week or so, and newsstand copies will be available by mid- March. Bruce ************************************************************************** * Bruce Schneier * Counterpane Systems For a good prime, call 391581 * 2^216193 - 1 * schneier at chinet.chi.il.us ************************************************************************** >From owner-cypherpunks Tue Mar 1 13:49:25 1994 From andy at autodesk.com Tue Mar 1 17:17:00 1994 From: andy at autodesk.com (Andrew Purshottam) Date: Tue, 1 Mar 94 17:17:00 PST Subject: Applied Crypto In-Reply-To: <9403012345.AA19252@pilot.njin.net> Message-ID: <9403020015.AA28709@meefun.autodesk.com> Well, Applied Crypto is of recent (now) vintage, so I would not expect it to show up in Project G. But certainly some of the classic stuff that APP reprints might be candidates. Have the copyrights expired on W. Friedman's texts, or were they pd anyway as Army publications? Andy From cknight at crl.com Tue Mar 1 17:19:30 1994 From: cknight at crl.com (Chris Knight) Date: Tue, 1 Mar 94 17:19:30 PST Subject: Colorado Cypherpunks meeting In-Reply-To: <199403012130.NAA13994@mail.netcom.com> Message-ID: On Tue, 1 Mar 1994, Nate Sammons wrote: > > This saturday, the 5th of March, at 7:00pm in the Penny Lane > coffee shop, there will be a Colorado Cypherpunks meeting to > discuss the recent Clipper/Skipjack/FBI DTB problems. > > Please tell anyone in the area (Colorado) who is interested to > please show up. It's on the South-west corner of 18th street > and Perl. > You maybe want to give a town? Colorado is a BIG place... -ck From rcain at netcom.com Tue Mar 1 17:32:27 1994 From: rcain at netcom.com (Robert Cain) Date: Tue, 1 Mar 94 17:32:27 PST Subject: Insecurity of public key crypto #2 (reply to May) In-Reply-To: Message-ID: <199403020133.RAA14793@netcom9.netcom.com> Peter Davidson sez: > > >This is the famed "key distribution problem." > > > >With public key methods, this problem is largely solved. Each person > >can generate his or her own key, publish the public key part of it, > >and be done with it. > > It's not that simple. Terry Ritter has pointed out on sci.crypt that > the problem with PGP is the validation of public keys used. In other > words, the security hole in the use of PGP is not in the encryption > methods used, or in the use of PGP itself, but in the possibility of > being duped by someone (or some nefarious federal agency) spreading > bogus public keys. It's not enough to have a public key which you > believe is the public key of a person you wish to communicate securely > with - you also have to be sure that the private key which corresponds > to this public key is known only to that person, in other words, that > the public key really did come from the person you believe it came > from. If you get the (presumed) public key of some person X from some > directory of public keys, or from some third party, how can you be > sure it didn't originate with someone who wants to monitor all the > encrypted messages being sent to X? Terry Ritter has explained how a > third party can place themselves in the middle of encrypted communications > between two people using PGP and monitor everything they say to each other > - and this without having to crack RSA or IDEA. Ah, yes. The man in the middle again. If a protocol existed that could guarantee detection of the man in the middle, then it would only need be used once with each conversant to exchange public keys reliably. The whole problem of public key distribution would then be solved. As many of you know, I believe such a protocol exists. :-) Without this detection capability in some form, public key has few advantages except that you only need one of them. A signfigant advantage, I admit but it doesn't seem to solve anything. Exchanging keys between point A and point B requires a chain of trust with no possibility of a man in the middle, not the sort of thing people want to mess with. Peace, Bob -- Bob Cain rcain at netcom.com 408-354-8021 "I used to be different. But now I'm the same." --------------PGP 1.0 or 2.0 public key available on request.------------------ From m at BlueRose.com Tue Mar 1 18:03:44 1994 From: m at BlueRose.com (M Carling) Date: Tue, 1 Mar 94 18:03:44 PST Subject: Applied Crypto Message-ID: <9403020134.AA12320@BlueRose.com> Project Guttenberg has only books that are in the public domain e.g. very old books. I suspect that Bruce Schneier (and the publisher) would like people to buy Applied Cryptography. I found it to be worth the price. M Carling Begin forwarded message: Date: Tue, 1 Mar 94 18:45:49 EST From: fhalper at pilot.njin.net (Frederic Halper) To: cypherpunks at toad.com Subject: Applied Crypto Sender: owner-cypherpunks at toad.com Precedence: bulk Does anyone know if Project Guttenberg(or anyone else) has electronic books such as applied cryptography? Thanks, Reuben Halper From russw at netcom.com Tue Mar 1 18:26:42 1994 From: russw at netcom.com (Russell Earl Whitaker) Date: Tue, 1 Mar 94 18:26:42 PST Subject: Colorado Cypherpunks meeting Message-ID: <199403020227.SAA24907@mail.netcom.com> At 13:30 3/1/94 -0800, Nate Sammons wrote: >This saturday, the 5th of March, at 7:00pm in the Penny Lane >coffee shop, there will be a Colorado Cypherpunks meeting to >discuss the recent Clipper/Skipjack/FBI DTB problems. > >Please tell anyone in the area (Colorado) who is interested to >please show up. It's on the South-west corner of 18th street >and Perl. > Nate, I know people in Colorado who would be interested in going... if you told them what city it might be in. Denver? Russell Russell Earl Whitaker russw at netcom.com Director, Extropy Institute 408-366-5435 ================================================================ From nobody at soda.berkeley.edu Tue Mar 1 18:30:32 1994 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Tue, 1 Mar 94 18:30:32 PST Subject: the nsa Message-ID: <199403020230.SAA02384@soda.berkeley.edu> we of the cypherpunks mailing list certainly admire the nsa, perhaps more than any other agency anywhere in the world. because of this admiration, i would like to have a large, color jpeg of the director of the nsa. i will uuencode this and mail it to many many people. could someone post such a jpeg to cypherpunks, or perhaps point me to where i might find one, or point me to a book or magazine that would have one, so i can scan it in? it's ok if the image is a bit noisy. thanks, nobody From wcs at anchor.ho.att.com Tue Mar 1 18:33:45 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Tue, 1 Mar 94 18:33:45 PST Subject: Standards for Steganography Message-ID: <9403020153.AA09443@anchor.ho.att.com> There are basically three classes of things you can hide 1) Plaintext easily-recognized payloads 2) Encrypted payloads with easily-recognized forms, e.g. PGP 3) Encrypted payloads that looks like random noise unless you have the key. (e.g. stealth-PGP or other cryptosystems that don't self-identify.) The definition of "easily-recognized" is obviously context-dependent, depending on your threat model. The proposed stego programs are mainly A) Programs that simply insert the payload, no frills except padding the ends B) Programs that insert the payload with length-markers and checksums C) Programs that encrypt the payload while inserting it D) Mimic functions that adapt the real bits to a given set of statistics Type A stego is fine for Type 3 data, as long as the statistics of the file you're hiding data in make random bits believable. It's obviously not much use for Type 1 data, and only some use for Type 2 data, if you're worried about the Bad Guys knowing that you're sending secret messages (and you probably are, else why bother with stego?) So if you're using Type A stego, make sure you use Type 3 random-looking payloads. Type B stego is a dead giveaway, like Type 2 payloads, if the Bad Guys are looking for it. If you're using encryption programs that do some kind of verification (at least if you have the right key), then you don't need these functions. Sure, the Bad Guys have to do the checksum themselves, which takes some work, but they now have a 256:1 or 64K:1 or whatever certainty there's stuff there. Type C stego programs are ok, if they're sufficiently high-quality, but they have to provide most of the functions of a good encryption program. It makes much more sense to use a software tools approach and separate the encryption from the steganography - if the encryption function doesn't advertise itself blatantly. If you just use a wimpy encryption function (e.g. XOR all the data with 10101010 or a PRNG), it stops wimpy Bad Guys at the cost of annoying the rich competent Bad Guys. The main usefulness of this is for Type 2 payloads, e.g. current PGP, but it's probably better to use Stealth-PGP instead. Type D stego can be useful for cases where the host material doesn't look right if you throw in random bits, and you seriously need to hide something. It's probably most effective with random- looking data (Type 3 payloads); with Type 1 or Type 2 the steganized message will tend to start the same way each time, which is bad, and if you need the quality of data hiding that mimic functions give you, you need a high-quality encryption program as well. All this stuff is essentially saying that you should use simple stego programs and stealthy encryption programs. Among other advantages, it means that you *can* standardize on stego programs without risking the attention of the Bad Guys, and it's much easier to agree on a standard with almost no options than to waste time on the infinite choice of details that you can haggle about with Type B stego - especially since those systems really tend to need good stealthy encryption as much as Type A stego does. Bill From corbet at stout.atd.ucar.EDU Tue Mar 1 18:46:12 1994 From: corbet at stout.atd.ucar.EDU (Jonathan Corbet) Date: Tue, 1 Mar 94 18:46:12 PST Subject: Colorado cypherpunks meeting -- city Message-ID: <199403020246.TAA10388@stout.atd.ucar.EDU> > This saturday, the 5th of March, at 7:00pm in the Penny Lane > coffee shop, there will be a Colorado Cypherpunks meeting to > discuss the recent Clipper/Skipjack/FBI DTB problems. > > Please tell anyone in the area (Colorado) who is interested to > please show up. It's on the South-west corner of 18th street > and Perl. For all of you who haven't heard of Penny Lane...it's in Boulder, on *Pearl* street (frueidan slip there, Nate?). This is about your last chance to check out this place -- it's being booted so that we can have another Starbuck's or some such. Such is life in Boulder these days. (Insert sanctimonious old-timer's sigh here). If I can explain to my wife that one night I'm staying late thrashing up the systems, the next I'm brewing beer with a friend, and the following I'm going to a cypherpunks meeting I'll be there. Jonathan Corbet National Center for Atmospheric Research, Atmospheric Technology Division corbet at stout.atd.ucar.edu http://www.atd.ucar.edu/rdp/jmc.html From nobody at soda.berkeley.edu Tue Mar 1 18:49:49 1994 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Tue, 1 Mar 94 18:49:49 PST Subject: Insecurity of public key crypto #2 (reply to May) Message-ID: <199403020249.SAA04575@soda.berkeley.edu> ## As many of you know, I believe such a protocol exists. :-) and as many of us believe, you're full of it... and what about the STS protocol that's been presented on the list before?? unless you publish, no one has any good reason to believe you... From rcain at netcom.com Tue Mar 1 18:56:26 1994 From: rcain at netcom.com (Robert Cain) Date: Tue, 1 Mar 94 18:56:26 PST Subject: clipper + enaction = illegal alternate encryption In-Reply-To: <01H9GN16SBXU000676@UNCVX1.OIT.UNC.EDU> Message-ID: <199403020257.SAA26110@netcom9.netcom.com> VACCINIA at UNCVX1.OIT.UNC.EDU sez: > > -----BEGIN PGP SIGNED MESSAGE----- > > Jeremy at crl.com writes: > > >Now why bother going through all the trouble to take out the chip? Why > >not just leave it in there and send RSA encrypted over your phone line? > >Once they _DO_ decrypt your clipper, they will still have another barrier. > >Leaving the chip in there does make it a little harder even for law > >enforcement doesn't it? > > This is the reason all other forms of encryption will be outlawed if the > clipper proposal goes through. I do not think so. It is perceived at very high levels that this simply won't fly. Y'all have been pretty effective at creating an initial negative impression within the press that is being accepted by John and Jane Q. public. Congrats. It is felt that already there has been too much bad press to counteract even with good arguments. If it happens I don't think it will be a matter of legislation but executive order that will stand the scrutiny of private consultation with congress and the flak this early publicity will generate. The latter is just a guess but I do know that the Clipper proponents are not at all encouraged and feel the need for it in the most sincere and concerned ways for what I think are very good reasons. Personally I don't think they will do anything to prevent our opening Pandora's Box simply because they are outflanked and know it but they have considered things they can't say in public that are creating much fear not only within this government but quite recently among many governments. It is not dope dealers or racketeers these governments are worried about. > I foresee at least two lines of enforcement. > The first is that one is held in contempt of court (assuming they can find > some charges to press) until you give them your key. How long can they keep > you in the slammer on a contempt charge? This option is already available > and seems to work, at least so far. This could work except that if exchanges are interactive so that a D-H type protocol can be used to generate one time session keys, using the RSA PK's only to do this securely, then yielding one's private key gives no ability to decrypt any prior interactive sessions. For documents this line of enforcement could work but for conversation it is useless. > > The second is to make alternate encryption illegal and thus they will > get you even if they have no evidence to charge you with. After all, if > the police are monitering you AND you are encrypting information, you > must be guilty, right? Encryption will be enough evidence to convict. > This makes life easy for law enforcement and will surely be the next > step after clipper. Except that if you use Clipper too they will have no reason to suspect that you might be using something hard going into it until they have done the escrow thing and by then you are probably in pretty deep anyway if the escrow method works as described and probably guilty of something pretty serious. There really is a strong argument from their side that says if one must use a form that is immune from a compromise like well escrowed keys one is *way* more than likely to be discussing something most of us would want LE or NS to know about. I know that argument is anathema here but I am finding it more and more compelling. Peace, Bob -- Bob Cain rcain at netcom.com 408-354-8021 "I used to be different. But now I'm the same." --------------PGP 1.0 or 2.0 public key available on request.------------------ From 71332.747 at CompuServe.COM Tue Mar 1 19:32:37 1994 From: 71332.747 at CompuServe.COM (James Hicks) Date: Tue, 1 Mar 94 19:32:37 PST Subject: Who are Worldwide Consultants? Message-ID: <940302030040_71332.747_DHQ92-1@CompuServe.COM> Hello. Has anyone heard of this organization? The below popped into my mail box unsolicited. This is the "E-mail Version" but there is no e-mail return address (that I could find). >James< >***************************************************************************** >FINANCIAL & PERSONAL PRIVACY NEWSLETTER, Spring 1994 Issue, E-mail Version >***************************************************************************** > >Published by: > >Worldwide Consultants >2421 West Pratt Boulevard, Suite 971 >Chicago, Illinois 60645 >U.S.A. > >PURPOSE AND POLICY STATEMENT: In order to keep the Financial and Personal >Privacy Newsletter (FPPN) unbiased, this publication accepts no paid >advertising and does not affiliate itself with, or receive support from, any >particular organization. > >FPPN covers topics of interest to privacy-conscious individuals. We cover the >legal, technological and personal aspects of confidentiality as well as >government and private sector-sanctioned invasion. > >This publication (in its entirety), MAY BE REPRODUCED OR TRANSMITTED in any >form or means without consent of the publisher. This newsletter is a public >service, thus is FREE. Feel free to disseminate by electronic mail or fax, >post on national & international networks and BBSs (Bulletin Board Services), >and distribute in hardcopy (printout) format. > >FPPN presents information and research believed to be reliable, however, it >cannot be guaranteed. Although every attempt has been made to ensure the >accuracy of contained data, Worldwide Consultants, the publisher, cannot >accept liability for misstatements. A complete investigation should be >conducted prior to any commitments. THIS CONTENT OF THIS NEWSLETTER IS FOR >INFORMATIONAL PURPOSES ONLY AND IS NOT INTENDED AS LEGAL OR OTHER PROFESSIONAL >ADVICE. > > > >FROM THE PUBLISHER'S DESK > >We would like to take this time to welcome you to the premier edition of our >publication. The Financial & Personal Privacy Newsletter will bring you hard- >to-find, valuable, and even bazaar information not found in the mainstream >press. We bring you the world in a way that you probably have never seen it >before. > >Please remember that there is an open door for you to air your thoughts, >suggestions and grievances (if any) in writing. Also, we welcome relevant, >well-written and researched articles of at least 500 words. Though we can't >pay for submissions, we will print up to 100 words about the author. > >Enjoy! > >-FPPN Staff > > > >BOOK AND VIDEO REVIEWS > >Confidential Information: Dangers of Disclosure by Bodo Schonebeck is a text >that describes the use and detection of bugs and other monitoring devices used >to obtain sensitive information. The price of the publication is $15 (plus $5 >postage). To order, contact: Security-Investigation-Debugging-Agency, P.O. >Box 4757, D-78512 Tuttlingen, Germany. > > >Asset Protection Strategies: Tax and Legal Aspects by Lewis D. Solomon and >Lewis J. Saret is a 480-page concise text that details various techniques for >protecting assets and reducing the risk of lawsuits. The price of the book is >$125. To order (or examine for 30 days), contact: Wiley Law Publications, >7222 Commerce Center Dr., Suite 240, Colorado Springs, CO 80919 USA; 800-879- >4539; Fax 719-548-4479. Please reference #4-6630. > >Phone Pirates by Ian Angus and Gerry Blackwell is a 246-page guide to >telecommunications fraud. The text describes how hackers penetrate phone >systems and steal long-distance services. The price of the book is $55. To >order, contact: Telemanagement Press, 8 Old Kingston Rd., Ajax, Ontario >L1T 2Z7, Canada 416-686-5050, ext 225. > >PT2 The Practice: Freedom and Privacy Tactics by Dr. W.G. Hill is a candid and >straight-foward text that takes an inside look at international financial >privacy planning and free-living. The price of the book is $100. To order, >contact: Scope International Ltd., 62 Murray Rd., Waterlooville, Hants >PO8 9JL, Great Britain; 44-0705-592255; Fax 44-0705-591975. > >New ID: How to Create a Complete New Identity by L.O.T.I. Group is a 35-minute >videotape that walks the viewer, step-by-step, through the process of identity >change and ID aquisition. The cost of the VHS video is $24.95. To order, >contact: Paladin Press, P.O. Box 1307, Boulder, CO 80306 USA; 303-443-7250; >Fax 303-442-8741. > >Our Vanishing Privacy by Robert E. Smith provides in-depth details (based on >the author's experience and an attorney, government employee, and reporter & >researcher) about information kept on U.S. citizens in government computers. >The price of the book is $12.95. To order, contact: Loompanics Unlimited, >P.O. Box 1197, Port Townsend, WA 98368 USA. > >People Tracking - You Can Find Anyone by Fay Faron & Lee Lapin is an 80- >minute videotape that provides the viewer with details on finding missing >persons of every walk of life. The price of the VHS video is $69.95. To >order, contact: Intelligence Incorporated, 2228 S. El Camino, #349, San Mateo, >California 94403; Fax 415-851-5403. > >How to Achieve Personal and Financial Privacy, 5th Edition by Mark Nestmann is >a 300+ page manual that details virtually every aspect of domestic privacy >protection. The book costs $68. To order, contact: LPP, Ltd., P.O. Box >83538, Phoenix, AZ 85071; 800-528-0559; Fax: 602-943-2363. > > > >SECURE COMMUNICATIONS STRATEGIES > >by Dr. Herrell Roehm, Ph.D. > >WARNING: The instructional format is used for clarity only. The author does >not advocate breaking any law. The reader is solely resposible for any >actions taken. No warrants, expressed or implied are made for any of the >material contained herein. Copyright 1991 I.S.D.A. - All Rights Reserved. > >RECOMMENDED READING FOR Privacy Seekers, Spies, Private Investigators, >Attorneys, Skip Tracers, Security Consultants, Law Enforcement Personnel, >Mercenaries, Collection Agents, Anarchists, Tax Resisters, Secret >Organizations, and The Persecuted and Oppressed. > >INTRODUCTION > >HOW TO USE THIS ARTICLE EFFECTIVELY: Place yourself in the position of >someone requiring maxium privacy AS IF YOUR LIFE DEPENDED ON IT. You'll gain >concrete insight and intuition that will help you avoid those seeking to >locate you, whom we will call the "tracer". Seek to develop your own >individual and unique sense of intuition. Intuition is informed by knowledge, >and knowledge should be informed by intuition. This somewhat intangible >quality can make the crucial difference between safety and exposure of worse. > >HOW MOST MISSING PERSONS ARE FOUND: If the truth were known, skip tracing is >not an extremely difficult profession, and can be very lucrative. The P.I. >(Private Investigator) is not the only kind of tracer. When we speak of >tracer, we mean: P.I.s, Feds and Police, government and private spies and >intelligence agencies, collection agencies, bounty hunters, or anyone who >might want to locate you. To find almost all of your "regular" skips, just >learn the readily available methods. There are more books about missing >persons than any other area of investigation. It represents the "bread and >butter" of many P.I. agencies. Any good tracer will be signed up with one or >more computer search services, and may locate many targets in just a few hours >or days. > >HOW MISSING PERSONS STAY "MISSING": Our privacy seeker is serious, and has >made privacy a way of life. He is hard to find, and makes up perhaps ten >percent or less of all missing persons cases. Some investigators label these >cases "difficult" or "impossible" to locate, often charging large fees anyway. >Some skips are fleeing criminal prosecution, prison, or engage in illegal >enterprises which demand absolute secrecy and security. A high-level of >sercecy and security is required for other legitimate enterprises too: >private investigation, personal bodyguard, critical and/or controversial >research, labs, and inventors to mention a few. Unpopular or "deviant" >lifestyles, beliefs, and practices lead some individuals to distance >themselves from "society" as much as they can. Certain totalitarian trends in >modern society cause some to want to avoid contact with government "Big >Brother" as much as possible. Persons in failed witness "protection" programs >where security has been breached may trun to the private sector after being >compromised by feds or other cops. Additional non-criminal reasons may >include: oppression from political, terrorist and dangerous groups, flight >from abusive families or cults, or fleeing threats of violence perpetrated by >individuals. It is not our purpose to judge or evaluate, and other reasons >exist. All have in common as distinct need for privacy. The techniques >discussed are used to achieve a successful level of privacy and secrecy, but >require DEDICATION AND THOROUGHNESS to be effective. > >SECURE COMMUNICATIONS > >MAIL: Get all your mail at a P.O. Box in a ficticious name. You will have to >fill out U.S.P.S. Form 1093 with a physical address (required), but you can >later "move". Sometimes the post office will ask for an update of your 1093. >This can be routine, but could indicate that someone is mail-tracing you. >They may have already received your "dud" address, and have continued their >inquiry by passing this information on the the P.O., who then ask you for the >updated 1093. The tracer can get a lot of free work done this way, but he >also runs the risk of alerting the skip. The final word here is WATCH YOUR >MAIL. > >MAIL DROPS: A "mail drop" or private postal box is sometimes recommended, but >"caveat emptor" is the watchword. These services are available in most areas, >and are used by numerous individuals and businesses for legitimate reasons. >You can provide additional cover by having your mail go through a series of >drops, but don't forget there are directories of these addresses. Because of >Reverse Skip Tracing (discussed later), we don't recommend mail drops when >seeking maximum security. Safest of all is to establish an address where you >(or a trusted friend or associate) can receive your mail. For the price of >some mail drops, you might rent a small cheap room or apartment in the "seedy" >area of town (if a particular type of address is not needed) where you can get >your mail in a group of mailboxes for that building. You can pick up your >mail at varying times, or have someone else do it for you. Make friends with >the superintendent of a building so that your mail is delivered with that of >the residents (you don't live there, of course). A cover story can easily >account for your need of this service. A "homeless" person might persuade a >mission, church or other agency to receive his mail, but the amount of mail >should be small as not to attract attention. These suggestions work best if >you don't get a lot of mail, and are not involved in illegal or other >compromising situations, which might lead to blackmail, exposure, or worse! > >GENERAL DELIVERY: Sounds hokey, but it's a very good cover. The Main Post >Office in a town or city is probably the best location as they are the busiest >and least likely to remember or notice you. Try to appear properly >nondescript when going for your mail, and don't establish a pattern. > >CREATE A STREET ADDRESS FROM A P.O. BOX: A box is not suitable for all >situations. You will need a street address. Every post office has a physical >street address, so send your mail there. Example: You are Mr. A. Skipper, Box >911, Metropolis, TX 78444-0911. Find out the street address of the P.O., and >write your address like this: Mr. A. Skipper, 1411 Main Street, Number 911, >Metropolis, TX 78444-0911. All boxholders now have an individual 9-digit >zipcode; its use should insure you get mail so addressed. Some correspondents >tell us that an occassional nosey postal employee will say this is not >permissable, but generally you shouldn't have any trouble. If you insist the >employee show you chapter and verse in the administrative codes, you will >probably prevail, but you may draw unwanted attention. In another instance of >a branch post office in a shopping center, there was difficulty obtaining the >actual physical address as the employee claimed it was never used. Even after >the address was obtained, some mail continued to be improperly returned to >sender. You will have to weigh each case, but we recommend that you try >another post office or branch if you run into snags at a particular location. > >REVERSE SKIP TRACING: Some ads for mail drops are just a ploy to get your >name and address, which is crossed referenced with lists of known missing >persons. Even "legitimate" drops may sell their client lists, or allow >tracers to go through the names. You can rest assured that every mail drop >will cooperate with the police or feds if they come around asking about you >(or your assumed name). Many books recommend use of mail drops, but we see >too may possible hangups. Is it possible that some of these "expert" missing >persons authors are just making sure that maildrops have a steady clientel for >reverse tracing? > >ANSWERING ADVERTISEMENTS: Keep your eyes open, and examine closely what is >recommended in some "inside information" or "underground" publications. Be >careful in answering any potentially risky advertisement. An example is found >in magazines catering to drug users and advocates, such as "High Times >Magazine". Many ads are probable D.E.A. fronts, especially the ones for >information or paraphernalia for growing pot (marajuana), mushrooms, ect.. >An ad for information on privacy, false I.D., or illegal scams (by little or >unknown companies), may be a front for reverse skip tracers - or someone else >tracing people like you! Don't avoid seeking new information, but be sure >your postal privacy is well protected. If your return address is traced, be >sure they come up empty-handed. > >REGISTERED AND CERTIFIED MAIL and C.O.D.s: Once you have established your >P.O. Box, the only mail coming to your real address should be "occupant" mail. >If Registered or Certified mail does come (could be C.O.D. or Insured Parcel >Post or ANY mail requiring a signature), say you are someone else, say the >person moved and left no address, moved months or years ago, say anything, but >NEVER sign for mail - no exceptions! The carrier is out of line to ask who >YOU are, so this should work. Tracers use this as a cheap and effective way >to locate skips. > >PACKAGES AND DELIVERIES: Always pay with money orders. Your receipt is proof >enough if required, and virtually impossible to trace. Keep the receipt >blank; don't fill it in unless needed. Although Federal Express, UPS, and >other couriers say they can't deliver to a P.O. Box, you can still use it. >Say on the order, "notify by mail at my P.O. Box for delivery instructions". >This causes a little delay, but the parcel agent will simply send you a post >card with an 800 phone number so you can call with delivery instructions. >Have it sent to a safe address, or don't give them an address at all. Pick up >the package at their office. NEVER have ANYTHING delivered to your real >address! That way, if anything does come, you will be alerted, and refuse >delivery as described. > >TELEGRAMS: We think of them as old-fashioned, but telegrams are still around. >It's not a bad ruse either, and should be treated same as above. > >MAIL TRACING: This is a cheap and useful tool, and is often the opening >gambit in efforts to locate you. Look out for any suspicious mail! All P.O. >Box information on U.S.P.S. Form 1093 can be accessed by others. Numerous >cover letters are avaiable, but the best way is to state that the individual >used the P.O. Box for business purposes, or that a court action is intended or >in the process. The P.O. will release the records, including the physical >street address you gave them. See any good book on researching public records >for more details. If a tracer sends you a letter, and it doesn't come back, >he may be enticed to advance another level, such as a personal visit and/or >surveillance. To deflect First Class and all other mail, consider buying >(through the mail of course) a small rubber stamp saying "Unknown - Return To >Sender", "Deceased", "Moved", "No Fowarding Order On File" or similar P.O. >wording. Be sure to drop it in a mail box NOT served by your regular post >office or branch. Beware of responding to offers asking you to call for >confirmation because you have "won" a free cruise or whatever. A postcard, >flyer or letter may offer a lucrative employment in your profession (or >something else you need or want) with a number to call collect. It may be a >ruse by a tracer. If family or friends' names are known, you may receive an >"emergency call" notifying you of the "death" of a loved one. Don't respond- >no exceptions! Have a backup plan for emergency communications with friends >or family if you absolutely must have it. So if a call comes, you KNOW it's a >ruse, and do not respond. Advance planning is crucial. > >MAIL COVERS: If feds or other cops are tracing you, they may establish a Mail >Cover for a 30 day period, with extensions. A mail cover does NOT require a >warrant, so it's easy to use. It is initiated by the agency working directly >with the local post office. They record ALL the information on the OUTSIDE of >the envelope, based on the premise that this is "public" information. They >identify regular correspondents, contacts, abnks, credit cards, other mail >transactions, suppliers, business associates, and more. Supposedly this does >not delay your mail, but who knows? It seems that it would delay it (given >the efficiency of most P.O. workers) or that you might receive mail in large >amounts when you usually do not. Monitor postmarks, and if you receive a lot >of mail, you should have a good idea how long it takes mail to reach you from >various parts of the country. ALWAYS WATCH MAIL AND DELIVERY PATTERNS. > >SENDING "SENSITIVE" MAIL: If you use a mail drop, change it from time to >time, and always run your mail through more than one drop. When quicker >delivery is needed, consider private delivery services. Drop the package off >at a pick-up point - do NOT have them come to you. Vary your service between >different carriers, and do NOT use post office Express Mail, particularly if >moving detectable contraband. It is routinely X-rayed and "sniffed". The >bus can be sued as numerous parcels are shipped everyday. Common items >shipped are tools, auto parts and equipment of all sorts, but many suitcases >and cardboard boxes as well. Even if you just have an envelope, wrap it in a >large box and weigh it down so that it is similar to other boxes being >handled. Use a typewriter for anything written, preferably a newer electric >model that doesn't leave a distinctive mark or indicate anything about your >key pressure. For short notes, ect., consider taking your paper to a large >discount store where typewriters are set out for your demostration. If you're >typing something that takes a minute of so, this is a good source. Libraries >often have typewriters available for use, so use a cover identity to get a >library card. Better yet copy centers and business centers where typewriters, >computers, printers, and copy machines are located together. No one will >require I.D. to rent you a typewriter for a half hour, and no one will >remember you among hunderds of users. For very sensitive correspondence, >photocopy the letter after you type it, and send this copy as the "original". >Develop an unreadable scrawl as your signature. It's not always necessary to >put your return address, and it is not required. You must be sure that the >mail is correctly addressed, and that nothing inside would compromise your >location or identity if it were opened by the authorities (or a tracer - yes, >they may violate the law!). > >AVOIDING MAIL TRACERS AT YOUR REAL ADDRESS: Remove the mail box. Remove any >signs from doors, windows, outside or walls, which may draw unwanted >attention. Never put YOUR name(s) on anything, and remove any old nameplates. >You can remove address numbers. If the postman has no mailbox or no proper >address, he cannot deliver, and mail is returned "Undeliverable As Addressed". > >MAILING LISTS, PERIODICALS, AND SUBSCRIPTIONS: Use the Direct Marketing >Association, P.O. Box 9008, Farmingdale, NY 11735 to get off most lists. The >IRS uses sophisticated mailing lists to apprehend tax evaders, categorized by >high-salary professions, spending patterns, lifestyles, and purchases like >vacations and luxury cars. Get off as many lists as you can. If you receive >"junk" mail (or other unwanted mail), mark it "addressee unknown - unable to >foward", and drop it in a street mail box, preferably one not served by your >local post office or substation. List users will delete your name to save >future costs. Do this consistently; you'll be off more lists. When you move, >do NOT send "Change of Address" notices to anyone. Start new subscriptions >under your new name at your new P.O. Box. If you subscribe to "exotic" or >unusual publications, you may be traced by this connection to your old life. >Large publications are probably OK, but if your interest is "The Vegetarian >Party Times", or Gum Label Collectors Quarterly", which has only a few >subscribers, you're taking a chance of exposure. NEVER SUBSCRIBE TO A >NEWSPAPER OR ANY OTHER SERVICE USING A DELIVERY PERSON. Tracers know these >individuals are aften talkative, nosey, and area a wealth of information about >you and your habits. Buy it at a news rack, read it at the library, or have >it sent to your P.O. Box. WRITE THE TRACER A LETTER, AND TELL HIM YOUR >"LOCATION": An Air Mail letter from Guatemala City, Paga Pago, Cairo or >Australia saying you're there, and never plan to return to the USA can end a >lot of tracing activities, particularly those of collection agencies. You >need a cooperative person in the other country to remail the letter. Business >agents for banking and forming corporations, and offices for rent in places >like Panama, the Isle of Man or other locations could be used. Check the >classified section of The International Herald Tribune Newspaper, 212-755-8785 >for leads. Some banks in Europe and other countries have good confidentiality >laws, and, if you have an account, some may receive and foward your mail for >you. Letters from diverse locations over a period of time might convince a >tracer that you are roaming about the world, another expatriate American >(there are lots of them) running from responsibilities back home. A word to >the wise: watch out for mail drops abroad - tracers have lists and directories >of these addresses. > >TELEPHONE SECURITY: Depending on who's after you, there may be no security at >all! The feds (and others) can turn a phone into an area "bug" with proper >equipment. If you must have a phone, be aware of the latest technology (an >excellent soure is "Full Disclosure Magazine, which is published monthly by >First Ammendment Press, P.O. Box 67, Lowell, Michigan 49331 USA). Be sure to >list it in a fictitious name or business name. I'm told that Ma Bell now >wants you to be a corporation to do this. That's OK - be a corporation! If >they ask for a corporation registration number, find out what one looks like >in your state, and provide it. If you receive a message or letter asking you >to call someone collect, don't do it! This is an old tracing technique. If >you don't give yourself away in the conversation, the tracer will simply call >the operator, ask for the time, charges and origin of the call and phone >number. Since the tracer is paying for the charges, the operator will be >happy to cooperate. Avoid cordless & cellular phones and radio communication. >Police (and anyone else) can listen and legally record these conversations, >which are exempt from wiretap laws. You're using the open airwaves, so your >communications are literally open to anyone who wants to listen. Numerous >scrambling devices are available. Some cordless phones have variable security >codes, and you could combine this with a voice scrambler (one type of which is >available from Shomer-Tec, P.O. Box 2039, Bellingham, WA 98227). This may be >enough, depending on who's tracing you, but what one computer scrambles, >another computer can eventually unscramble. This also goes for any "codes" >you might device or use. In the ever-changing world of communications >technology and spy devices, "never say never" about anything, and always >assume that someone is at least one step ahead of you in sophistication. STAY >AWAY FROM ALL ELECTRONIC COMMUNICATIONS IF YOU CAN. If you must communicate >over these media, take every possible precaution. Best of all - don't have a >phone. It's easier than you think. A lot of phone use is habit anyway. If >you must make calls, use safe locations like a friend's home or a secure pay >phone, but don't establish a regular pattern anywhere. > >FACE-TO-FACE COMMUNICATIONS: In past times, when your telephone wasn't secure >you could usually set up a face-to-face meeting. The ready availability of >numerous "bugs" has changed all of that, especially the ultra-small micro >varieties. Depending on the level of security required, it can be very >expensive to deploy counter devices and detectors. They may be useless, and >give you a false sense of security. Let's consider a few of the >possibilities. If your meeting place is known, bugs can be planted in >advance. Your contact will probably be bugless, but the whole area would >already be compromised. Simple parabolic ears and smaller listening devices >can easily be employed if cover can be established. These are generally >defeated by meeting in large open spaces, yet this presents its own additional >risks. Technology advances rapidly in theis field. What was science fiction >yesterday is common equipment tomorrow. Never underestimate the technological >capacity of the tracer. Who can you trust when it comes to bugs? Trust no >one! Even a friend or "safe" contact (or their car or home) can be bugged >without their knowledge. After the tracer has identified your contact, he >will observe HIS patterns, just waiting for YOU to show up. This is >particularly successful if you have a girlfriend, pusher, money source, or >anyone/anywhere you just HAVE to visit. The tracer knows you're eventually >coming, so it's just a matter of time. Your contact could be compromised by >threats to his (or his family's) safety, or by blackmail. Very few people >will remain totally loyal under such circumstances. You can hope your contact >will at least warn you if this is happening, but don't count on it. Watch >friends and contacts for any signs which might alert you. When someone who >was helpful, jovial and friendly begins to act reserved, afraid, and uneasy, >they may be under just this kind of pressure. > >A FINAL WORD ON COMMUNICATIONS: Our purpose is to get you in the habit of >thinking, observing, and COMMUNICATING from the position of someone who >requires absolute maximum privacy and security. Its purpose is not to create >paranoia, but don't forget the old saying: "Just because you're paranoid >doesn't mean they're not really out to get you". > >ABOUT THE AUTHOR: Herrell Roehm is the founder and executive director of the >International Security and Detective Alliance (I.S.D.A.), a worldwide society >and professional registry for private investigation and security services. He >is also the editor of I.S.D.A.'s newsletter, The Eagle (subscriptions are >$7.95 for 4 issues). For a sample copy, including information about the >organization, send $2 to: I.S.D.A., P.O. Box 6303, Corpus Christi, TX 78466 >U.S.A.. Dr. Roehm also conducts nationwide missing persons searches and other >examinations in the southern U.S. and Mexico. He may be reached by telephone >at 512-888-6164. > > > >NEWS IN THE WORLD OF PRIVACY PROTECTION AND INVASION > >THE PRIVACY JOURNAL is a monthly newsletter that reports on legislation, legal >trends, new technology, and public attitudes affecting the confidentiality of >information and the individual's right to privacy. The subscription cost is >$109 annually ($135 overseas). For a sample copy, contact the Privacy Journal >at P.O. Box, 28577, Providence, RI 02908 USA; 401-274-7861. > >TRACELESS PHONE CALLS are possible through the use of a service provided by >the International Telephone Company. Private Lines, a service founded by >Beverly Hills Lawyer Will Dwyer II, allows users to make calls via their 900- >number with absolutely no record. The service works for domestic and >international calls. Simply dial 1-900-CALL-888, and select "1" for calls >within the U.S., Canada or the Caribbean at $1.95/minute. Select "2" for all >other direct-dial worldwide locations at $3.95/minute. The calls will appear >on your long-distance bill as calls to 1-900-225-5888 "Secure-Tel". For more >information about the service, contact IPC at 800-823-0080; 408-738-3700; Fax >408-748-4343. > >CAMOUFLAGE PASSPORTS are documents that look exactly like a legally issued >passport, containing the bearers photo and vital stats, and is full of entry >and exit stamps. These documents are bogus passports from countries that >don't exist anymore (i.e. Ceylon, British Guyana, New Hebrides, Upper Volta or >Pantagonia). The purpose of these documents are not travel, but to provide >hijackers, terrorists, and other hostile elements with an alternative identity >in order to save those with high-profile nationalities such as American, >Canadian, British, ect. from harm. The cost of a "Camouflage Passport" is >$550. For more information or to order, contact: Expat World, P.O. Box 1341, >Raffles City, Singapore. > >OFFSHORE COMPANY FORMATION for the purpose of setting up legitimate businesses >or empty shells is simple with the use of the the services of Overseas Comapny >Registration Agents, Ltd.. They are part of an worlwide network of lawyers, >accountants, secretaries and bankers who perform all work with extreme >discretion. For a free 60-page brochure, contact: O.C.R.A., Companies House, >Ramsey, Isle of Man; 800-283-4444 (toll-free from the U.S.); 44-624-815544; >Fax 44-624-815548. > >THE 16TH ANNUAL CONFERENCE OF DATA PROTECTION will be held in The Hague, >Netherlands in September. Government Commssioners will meet with the private >sector to discuss computers and privacy issues. For more information, >contact: Peter Hustinx, Postbus 3011, 2280 GA Rijswijk, The Netherlands. > >BUSINESS ESPIONAGE CONTROLS & COUNTERMEASURES ASSOCIATION (BECCA) is a non- >profit organization dedicated to the protection of proprietary information and >other business secrets. For more information about the group, contact: BECCA, >P.O. Box 55582, Seattle, Washington 98155 USA; 206-364-4672. > >EVERY ASPECT OF COMPUTER, PBX & VOICE MAIL, AND TECHNOLOGICAL PRIVACY is >covered by the Infosecurity News, The magazine for the protection of >information. For details and subscription rates, contact the publication at >498 Concord Street, Framingham, MA 01701 USA; Fax 508-872-1153. > >HAVE YOUR NAME AND PHONE NUMBER REMOVED FROM TELEMARKETING LISTS by writing to >Telephone Preference Service, DMA, P.O. Box 9014, Farmingdale, NY 11735 USA. > >GET COPIES OF YOUR CREDIT REPORT by contacting TRW at 800-392-1122, Equifax at >800-685-1111, or Trans Union at 800-851-2674. > >JIM ROSS' COMMUNICATOR NEWSLETTER covers various topics relating to electronic >surveillance and privacy issues. For a free copy, call 800-US-DEBUG. > >COMPUTING & COMMUNICATIONS LAW & PROTECTION REPORT is a brief guide to >developing corporate policy on monitoring and disclosure of electronic mail >(e-mail). For a free copy, contact: Assets Protection Publishing, P.O. Box >5323, Madison, WI 53705 USA; Fax 608-271-4520. > >ALTERNATIVE INPHORMATION markets numerous publications on high-tech (and not >so technical) methods of privacy invasion. Write for a copy of their catalog: >Alternative Inphormation, P.O. Box 4, Carthage, Texas 75633 USA. > >CORPORATE SECURITY DIGEST is a weekly publication reporting on governmental, >commercial, and industrial security (and privacy) topics. Subscriptions are >$295/year. To request a free copy, contact: Washington Crime News Service, >3918 Prosperity Avenue, Suite 318, Fairfax, Virginia 22031 USA; 703-573-1600. > >CENTRAL INTELLIGENCE AGENCY (CIA) PUBLICATIONS are available by annual >subscription. For information, contact: Document Expediting Project (DOCEX), >Exchange and Gifts Division, Library of Congress, Washington, DC 20540 USA; >202-707-9527. > > > >***************************************************************************** * >OFFSHORE FINANCIAL AND PERSONAL PRIVACY PROGRAMS ALLOW YOU TO PROTECT YOUR >CONFIDENTIALITY IN PERSONAL AND BUSINESS AFFAIRS. A FEW EXAMPLES OF THE From nobody at nowhere Tue Mar 1 19:41:16 1994 From: nobody at nowhere (nobody at nowhere) Date: Tue, 1 Mar 94 19:41:16 PST Subject: No Subject Message-ID: <199403020307.AA05092@xtropia> On Mon, 28 Feb 94 11:48:59 -0800, "Eric Hughes" wrote: > John's request will be denied, no doubt, and will go to court. Should > he prevail in court, the executive branch is bound by that decision. > A key custody database which was public would make the system insecure > and unusable. The executive branch could not change this. Only the > legislature could. > Do not expect a treatment according to the law by the courts. It has been a long time since courts have considered themselves bound by the text of the laws or the constitution. Instead, John should instruct his lawyers to create delays. A Lawyer that can not create a delay is worthless. In the beginning, until the Government figures out what is going on, the Government will probably also want to create a delay. Cypherpunks should tell the public and every possible buyer of the clipper chip, especially the Corporate buyers that the suit exists, and if it is successful, all clipper keys could be disclosed including the keys to Clipper devices. All data that has been transfered via Clipper could be retroactively exposed! This will cause Clipper to be a commercial flop. In short, we can use FUD to kill Clipper! This is a delicious irony because usually FUD is used by the enemies of liberty, not buy its defenders! > Eric From sommerfeld at orchard.medford.ma.us Tue Mar 1 20:05:24 1994 From: sommerfeld at orchard.medford.ma.us (Bill Sommerfeld) Date: Tue, 1 Mar 94 20:05:24 PST Subject: PGP on the HP 100 In-Reply-To: <9403020057.AA03418@toad.com> Message-ID: <199403020355.WAA00374@orchard.medford.ma.us> From: smb at research.att.com Date: Tue, 1 Mar 94 19:56:40 EST Sender: owner-cypherpunks at toad.com Has anyone tried putting ViaCrypt PGP on the HP-100? Yup. Is anyone but me crazy enough to contemplate it? Nope. (I demoed it to a few people at the ISOC SNDS conference in San Diego a month ago..). How abysmal is the performance? Pretty bad, at least compared to the desktop systems I'm used to. I hope you're patient.. - Bill From rcain at netcom.com Tue Mar 1 20:09:35 1994 From: rcain at netcom.com (Robert Cain) Date: Tue, 1 Mar 94 20:09:35 PST Subject: Dorothy Denning In-Reply-To: <9403012355.AA08431@anchor.ho.att.com> Message-ID: <199403020410.UAA07525@netcom9.netcom.com> bill.stewart at pleasantonca.ncr.com +1-510-484-6204 sez: > > I objected to Anthony Ortenzi's article on Dorothy Denning. > Much of the attacks seemed appropriate for a politician like Clinton (:-)), > but aren't appropriate for an academic who's doing politics about > technical areas, where there so much more *useful* ways to flame > her ideas, rather than her character. I could not agree more. I would rather see her ideas discussed though than flamed. > > > Number 1, if someone is an encryption expert [...], why would they endorse > > anyone but the recipient being able to decode the message? > > You're confusing technical tactics with political/social goals. > She's an expert in what you can do with encryption, she just has different > values about who should be able to benefit from it and how. I spoke with her at some length today and later with a man she recommended I also speak with that is an Assistant to the Director at the NSA. It *is* a question of who should be able to benefit from it but not because they are conerned about any of us here. More later. > > as you say, it would be nice if she'd > just come out and say the government should spy on all of us to keep us > from doing Bad Things; it's an argument people can relate to and discuss > (though it'll get a lot of negative reaction, which is not her objective.) She won't come out and say that because that is not at all what she believes. She is not even looking at us much or giving much thought to the Bad Things we might do. Her scope is much larger than "us." > > > C) Was she dropped on her head a lot as a baby? > Probably got scared by a Commie Terrorist Drug Dealer, and comforted > by some friendly federal police officer... or else was educated in > government-run schools. :-) I wish I could get across to you all how this C) kind of attack affects even people of her stature and public standing. This is a very poor charactature of her as I found her in discussion or have found her writings. She is calm, reasonable, not in the least a hard liner and I haven't seen a trace of the personality traits you give a basis for. Yes, she is very frustrated, even depressed sounding, because she cannot seem to find a way to convey the reality of her concern without it being distorted or pulled into a ridiculous context and yes she is frustrated because she clearly sees the problems facing Clipper. What has not been discussed here very much and what I felt going into the conversations with these people is that they *can't* tell us what they are afraid of. It is not a matter of won't. The conversations bore this out. We have been concentrating on in our discussion here on how much they fear the loss of a power they have gotten used to and abused to where we find it offensive. That is not nearly so much what they fear. It is the *unknown*. It is pretty hard to make public statements like that. The real issue is that this is an *enabling* technology that allows any group of people distributed over the world to meet spontaneously in secret to plan anything. I don't think we can even conceive, nor have they yet, the ways the real Bad Guys (I hope we can agree that some do exist) might find to use this new ability. A very clear danger is sensed in Washington with little real benefit to the civilized and civil majority. In fact, the reason I began to have the qualms about this that I have been expressing lately (besides being in a position to open this Pandora's Box myself now) is that the reason I started looking at crypto a couple of years ago was that I was in an extremely agitated, nearly revolutionary state during the period slightly before the LA riots and for a while thereafter and I came to the conclusion that this system needed to be brought down, simple. I felt that this could be pulled off, in fact, if a method of secure voice communication could be established that would *enable* country wide planning and synchronization. Think about it. Well, my politics have changed considerably for several reasons but I well remember my initial motive for studying crypto and looking for a solution to the man in the middle that didn't require any passwords or prior agreement. I have not, however, lost the belief that dedicated revolutionaries could use it to create havoc not just here but world wide and that could just be the tip of the iceberg. I don't know what the solution is though and I don't think that Dr. Denning, President Clingon or the NSA really has one. The cat is out of the bag now and they seem to realize to their near depression that it won't go back in. I requested the phone meeting with her because I needed to discuss these moral issues with someone that I felt was looking a bit more deeply into it all. I am not sure what I am going to do. I no longer really want to be the one to open the box with something easy to use and foolproof but I know that it is just a matter of time before someone else meanders down the path I found so why act on my personal concerns only to lose the chance to be the first out of the gate. I asked these questions and ran into heavy sighs. I believe it is well understood that only voluntary means of controling this exist and that liklihood is very small. Persuasion is not working and the press has been whipped into a near hysterical state over this by we and our friends (yes, we on the internet are considered to be the force that has derailed their hopes and that was unforseen.) As is obvious I don't consider this government to be a monolithic antagonistic entity out to strip us of rights. Sure it has happened in areas but they are reasonably isolated areas. There are *many* people in this rather diverse government and in an advising capacity to it whose sole concern is our safety and these people are worried. I find it interesting that there are many people here who lack the imagination to understand that there probably are a goodly number of reasons for rightly feeling the need for a Clipper like solution and that it would not be appropriate for the government to be public about them. Why is that so difficult to understand in these times of international strife, terror and technology? Peace, Bob -- Bob Cain rcain at netcom.com 408-354-8021 "I used to be different. But now I'm the same." --------------PGP 1.0 or 2.0 public key available on request.------------------ From dwomack at runner.utsa.edu Tue Mar 1 20:20:32 1994 From: dwomack at runner.utsa.edu (David L Womack) Date: Tue, 1 Mar 94 20:20:32 PST Subject: Corporations Message-ID: <9403020420.AA23717@runner.utsa.edu> Mr. May mentioned corporations; I'd like to hear comments on a concept.... Let's suppose an offshore corp. is established somewhere; perhaps Grenada, perhaps Belize, or where ever. You work for this corporation; the corporation produces a product or service. Now, here is where the potential seems to be: the corporation generates bills from the offshore location. Customers pay to the corp., mailing to the offshore location. Constructive receipt, then, is offshore. My understanding is that corporate earnings are subject to the host country's tax, NOT U.S. tax. And, tax waivers are not difficult to get from these other countries. If one wishes to take some risks, the corp. then makes a loan to the individual, at a fair market rate of interest. This would be in addition to whatever miserly wage the corp. paid to it's employees. Of course, the person would be obligated to declare a forgiven loan as income; they would be on their honor to do so, since there would be no paperwork.... Any thoughts? Or is there a gigantic hole in my thinking? Regards.... From punisher at ccwf.cc.utexas.edu Tue Mar 1 20:26:21 1994 From: punisher at ccwf.cc.utexas.edu (The PUNISHER - Judge) Date: Tue, 1 Mar 94 20:26:21 PST Subject: Clipper/Skipjack Message-ID: <199403020426.AA01460@bashful.cc.utexas.edu> just a quick note to tell you all that I just read an editorial in info security by John Droge. He rambles on in much the same way Dorothy Denning does, terrorists, you can trust that gov't...blah, blah, blah.. Anyway, I was wondering why any sane, 1/10 intelligent person would be defending the Clipper chip...then I read his bio...he is a VP at Mykotronx. Looks like their PR machine is in full steam! :) The Punisher From nowhere at bsu-cs.bsu.edu Tue Mar 1 20:32:16 1994 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Tue, 1 Mar 94 20:32:16 PST Subject: Stegonography Message-ID: <9403020432.AA11900@bsu-cs.bsu.edu> There's been a lot of discussion lately about trying to make stego files not have any identifying marks, so that usage of stego would be indistinguishiable from noise. A more effective option might be to insert obvious (or somewhat obvious) stego messages in lots of graphics. Take every graphic file you own and hide something in it with a stego program. Put PGP messages in them (even including the obvious ---- BEGIN PGP MESSAGE ---- headers). Or a BBS ad. Or just cute little messages. Then distribute the files that way. Hopefully, people will take these images and pass them on without ever knowing there was stuff in them. If enuff people do this, graphics will become so "polluted" with stego messages that your truly secret PGP messages will be hidden in plain sight along with all the other graphic files full of stuff, and won't stand out. Plus, you could plausably deny having put it there, claiming that it must have been that way when you got it, and that you didn't know it was there. From rarachel at prism.poly.edu Tue Mar 1 20:45:06 1994 From: rarachel at prism.poly.edu (Arsen Ray Arachelian) Date: Tue, 1 Mar 94 20:45:06 PST Subject: Insecurity of public key crypto #1 (reply to Mandl) In-Reply-To: <199403020015.RAA21139@pmip.dist.maricopa.edu> Message-ID: <9403020433.AA16707@prism.poly.edu> > Would it not make sense, therefore, to publish a public cypherpunks > mailing list key, which is returned with subscription requests? > All incoming message cleartext to the mailing list server would > then be encrypted in the server's key; not for security, but > precisely for the reason you state above. That _would_ create > quite a volume of encrypted communications to each receipient of > the list. Please don't do that. I don't want to go through hoops to read this mailing list. It's already cumbersome as is. Adding PGP in the soup would make things very nasty. I'd rather not use PGP except for private messages. Perhaps having a usenet news group for encoded mail might be better. Something where everyone can occasionally either send a PGP'ed message with the subject being an encoded version of the receipient's name, or with just random junk that's PGP'ed... This would create enough traffic to be able to hide messages in. Perhaps a special "news" reader program can be written that scans all messages in that group for the encoded name, and if it matches that of the reader it will decode it and dump it in that user's mail or read it (and possibly reply to it) on the spot. From ejohnson at pmip.dist.maricopa.edu Tue Mar 1 21:11:49 1994 From: ejohnson at pmip.dist.maricopa.edu (Eric Johnson) Date: Tue, 1 Mar 94 21:11:49 PST Subject: Insecurity of public key crypto #1 (reply to Mandl) Message-ID: <199403020511.WAA21677@pmip.dist.maricopa.edu> : From rarachel at prism.poly.edu Tue Mar 1 21:44:58 1994 : Subject: Re: Insecurity of public key crypto #1 (reply to Mandl) : To: ejohnson at pmip.dist.maricopa.edu (Eric Johnson) : Cc: cypherpunks at toad.com : X-Mailer: ELM [version 2.4 PL21] : Content-Type: text : Content-Length: 1207 : : > Would it not make sense, therefore, to publish a public cypherpunks : > mailing list key, which is returned with subscription requests? : > All incoming message cleartext to the mailing list server would : > then be encrypted in the server's key; not for security, but : > precisely for the reason you state above. That _would_ create : > quite a volume of encrypted communications to each recipient of : > the list. : : Please don't do that. I don't want to go through hoops to read this : mailing list. It's already cumbersome as is. Adding PGP in the soup : would make things very nasty. I'd rather not use PGP except for private : messages. That was exactly the point Eric Hughes was making; it is not a good strategy to save encryption for only private communications. Besides, procmail (or similar) should be able to handle piping incoming cypherpunks traffic through the decryptor, so the hoop would be transparent anyway. No muss, no fuss. --Eric From tytso at ATHENA.MIT.EDU Tue Mar 1 21:29:19 1994 From: tytso at ATHENA.MIT.EDU (Theodore Ts'o) Date: Tue, 1 Mar 94 21:29:19 PST Subject: Dorothy Denning In-Reply-To: <199403020410.UAA07525@netcom9.netcom.com> Message-ID: <9403020528.AA26183@tsx-11.MIT.EDU> From: rcain at netcom.com (Robert Cain) Date: Tue, 1 Mar 1994 20:10:15 -0800 (PST) What has not been discussed here very much and what I felt going into the conversations with these people is that they *can't* tell us what they are afraid of. It is not a matter of won't. The conversations bore this out. We have been concentrating on in our discussion here on how much they fear the loss of a power they have gotten used to and abused to where we find it offensive. That is not nearly so much what they fear. It is the *unknown*. It is pretty hard to make public statements like that. Yes, it is pretty hard, because it makes it seem as if they have small minds. There have been people who have likened the coming of computers and networking to the invention of the Gutenburg printing press --- that is, it is a critical, enabling technology that will have extremely serious impacts on our society as we know it. I can imagine that back then, the Catholic church must have been deeply opposed to letting the "hoi polloi" access to books, and access to learning. Think of how it would disrupt the social order!!! >From what you have said, it sounds like Denning, et. al's objections are of a similar ilk; they are afraid of how this might completely change society. I agree; it probably will. However, while there may have been some societal upheavals that can be traced back to the introduction of the printing press, in the end I think we can all agree that the printing press was a good thing. The important point that you make is that the cat really *is* out of the bag; I am just concerned that the government, in a futile attempt to try to stuff the cat back in, does perhaps fatal damage to all of our civil rights in its desperation. Look at how civil forfeiture has been used to completely strip someone of his properties, without any due process. Look at the RICO act, and the truely scary things that you can do with it; it was originally applied against the Big Bad Mob, but it's turning out to have much broader applications. So if the cat really is out of the bag, then the government should give up on this ill-conceived Clipper abortion as soon as possible. The fact that the Clipper propoents may actually be recognizing the hopelessness of their task this is a sign of hopefulness or a sign of great danger; the question is whether they will act like rational human beings, or a cornered animal. - Ted From plaz at netcom.com Tue Mar 1 21:35:29 1994 From: plaz at netcom.com (Plaz) Date: Tue, 1 Mar 94 21:35:29 PST Subject: GAMES: The "Crypto Anarchy Game" Message-ID: <199403020536.VAA20802@mail.netcom.com> >Tim, on the cypherpunks list you said: > > Let me also note that this issue has--like so many things on this > list--come up a couple of times. Geoff Dale, for example, proposed a > Cypherpunks game/simulation area in a virtual world at the Illuminati > BBS. I have no idea how it's coming; haven't seen Geoff here in > months. Best wishes to Seth or anyone else who actually implements > such a system. > >I don't know what Geoff has been doing with the Illuminati BBS, but I >do know that he's on the list. Majordomo tells me so: > > plaz at netcom.com (Geoff Dale) > >Geoff, do you think it would be appropriate to describe on the list what >progress, if any, you've made on the above referenced project? Woops, found this in my archives. Almost a week old, forever in net time. I did mention something about possibly doing a cypherpunks area in the Metaverse MOO. I was largely trying to convince someone else to do it. I have done absolutely nothing on this topic. ExI Freegate Virtual Branch, yes. A little work on Cafe Flesh, guilty, but no work on any cypunks game/environment. I doubt the value of spending much time on a cypherpunk "game" anyway. It's not like we had to introduce an internet game to the public before they started to notice it. If someone wants to do it, go for it. It won't register highly in my priority list, tho. TTFN _______________________________________________________________________ Geoff Dale -- Cypherpunk/Extropian -- Plastic Beethoven AnarchyPPL - Anarch (Adjudicator) ExI-Freegate Virtual Branch Head plaz at netcom.com 66 Pyramid Plaza plaz at io.com Freegate, Metaverse at io.com 7777 "Subvert the domination paradigm!" From sandfort at crl.com Tue Mar 1 22:27:57 1994 From: sandfort at crl.com (Sandy Sandfort) Date: Tue, 1 Mar 94 22:27:57 PST Subject: Corporations In-Reply-To: <9403020420.AA23717@runner.utsa.edu> Message-ID: C'punks, On Tue, 1 Mar 1994, David L Womack wrote: > . . . > Let's suppose an offshore corp. is established > somewhere; perhaps Grenada, perhaps Belize, > or where ever. You work for this corporation; > the corporation produces a product or service. > > Now, here is where the potential seems to be: > the corporation generates bills from the offshore > location. Customers pay to the corp., mailing > to the offshore location. Constructive receipt, > then, is offshore. My understanding is that > corporate earnings are subject to the host > country's tax, NOT U.S. tax. And, tax waivers > are not difficult to get from these other countries. Yup. And a variation of this is what's called double invoicing. It's one of the things that made Hongkong great. > If one wishes to take some risks, the corp. then > makes a loan to the individual, at a fair market > rate of interest. This would be in addition to > whatever miserly wage the corp. paid to it's > employees. Of course, the person would be obligated > to declare a forgiven loan as income; they would > be on their honor to do so, since there would be > no paperwork.... Congratulations, you have re-invented a time-honored service of offshore banks and incorporation services. Of course, there never has to be a forgiveness of the loan. It can just be rolled over forever. Or, the recipient can use his "loan payments" as a means of ex-patriating more money. I'm really quite impressed with your thinking on this. Though many sophisticated varients of these techniques have existed for years, it is quite an accomplishment to invent them independently. Unlike some knee-jerk hand wringing (mixed metaphor?) I have seen on this list, you have identified the transactional essence present in successful transnational thinking. Again, congratulations. S a n d y From nobody at soda.berkeley.edu Tue Mar 1 22:28:58 1994 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Tue, 1 Mar 94 22:28:58 PST Subject: . Message-ID: <199403020628.WAA04657@soda.berkeley.edu> >What has not been discussed here very much and what I felt going into >the conversations with these people is that they *can't* tell us what >they are afraid of. It is not a matter of won't. The conversations >bore this out. We have been concentrating on in our discussion here >on how much they fear the loss of a power they have gotten used to and >abused to where we find it offensive. That is not nearly so much >what they fear. It is the *unknown*. It is pretty hard to make public >statements like that. Repeat after me: Change is our friend. We must embrace change. Change is good. We must lose our fear of change. Change...Change...Change...Change...Change...Change...(click)...Change... From kinney at bogart.Colorado.EDU Tue Mar 1 22:33:46 1994 From: kinney at bogart.Colorado.EDU (W. Kinney) Date: Tue, 1 Mar 94 22:33:46 PST Subject: Dorothy Denning Message-ID: <9403020633.AA22730@bogart.Colorado.EDU> -----BEGIN PGP SIGNED MESSAGE----- Robert Cain Writes: >What has not been discussed here very much and what I felt going into >the conversations with these people is that they *can't* tell us what >they are afraid of. Theodore Ts'o writes: >So if the cat really is out of the bag, then the government should give >up on this ill-conceived Clipper abortion as soon as possible. The fact >that the Clipper propoents may actually be recognizing the hopelessness >of their task this is a sign of hopefulness or a sign of great danger; >the question is whether they will act like rational human beings, or a >cornered animal. I think this is very perceptive. Clipper is perhaps the best they could _think_ of given an outmoded set of axioms. If the presumptions people in government have about their own role are no longer valid, they probably don't fully realize it yet, or at least can't admit they do. Clipper is just the kind of woefully clueless thing people in that position would come up with. It is kind of scary. Yikes. -- Will -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLXPOevfv4TpIg2PxAQE2zQP9HY7vmwAz73DDvW0wHti07p/4hlPOLouQ Yw0gj6Ixrxw00D1trdpZloU3pw5NfHrVGjcLvA12KMJqcjyh9Ga6+q1y/oQOoGzm q/8dTwgKT61pdkTKnPt8Esyy/g30Jzy+QODjdDFMkkey+KwE1vbKIJiQccPvZypJ rFpN4KOqBZ4= =Jo/p -----END PGP SIGNATURE----- From Rolf.Michelsen at delab.sintef.no Tue Mar 1 23:38:25 1994 From: Rolf.Michelsen at delab.sintef.no (Rolf Michelsen) Date: Tue, 1 Mar 94 23:38:25 PST Subject: low-overhead encrypted telnet In-Reply-To: <9403011958.AA09178@hot.ee.lbl.gov> Message-ID: On Tue, 1 Mar 1994, Jef Poskanzer wrote: > I've been talking about entrypted telnet with Craig Leres lately, and > he came up with an interesting idea. The background is, sysadmins want > encrypted telnet so that passwords don't fly around in the clear, but > at the same time, they don't want to spend too many extra CPU cycles. > I figured at least some sysadmins would resist installing an > encryption-capable telnetd because of this concern about overhead. [Some text deleted] Have you seen the proposals for an encryption option for TELNET? There are at least two proposals. The first is by David Borman dated April 1990 and the second by Lawrence Brown and Gilje Jaatun dated December 1991. Borman's proposal focuses on the possibility of encryption of passwords only. Unfortunately I don't have a pointer to an electronic copy of these proposals -- perhaps someone else on this list has? I am currently working on a project which requires encrypted TELNET. We will be encrypting *all* transmitted data to protect sensitive information -- not just passwords. Does anybody know the current status of standardization of an encryption option for TELNET? -- Rolf ---------------------------------------------------------------------- Rolf Michelsen Phone: +47 73 59 87 33 SINTEF DELAB Email: rolf.michelsen at delab.sintef.no 7034 Trondheim Office: C339 Norway ---------------------------------------------------------------------- From wcs at anchor.ho.att.com Tue Mar 1 23:38:52 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Tue, 1 Mar 94 23:38:52 PST Subject: Clipper (Re: Dorothy Denning) Message-ID: <9403020738.AA12338@anchor.ho.att.com> "W. Kinney" writes: > I think this is very perceptive. Clipper is perhaps the best > they could _think_ of given an outmoded set of axioms. > If the presumptions people in government have about their own role > are no longer valid, they probably don't fully realize it yet, > or at least can't admit they do. I disagree. My opinion is that the axioms involved are 1) We're in power, and want to stay there. 2) Some kinds of technology greatly enhance our power if we control them. 3) Crypto Technology is a major threat to our power unless we control it. 4) Maybe we can stop it if we act quickly, at a cost to society that's low enough that we won't cause a major revolt 5) If we pull that off, the success will help consolidate our power. 6) The public believes almost anything we tell them, at least for a while, as long as we sound sincere. Of those axioms, only 4) is really in question, though 1a) is a bit shaky. Even George Bush could pull off 6) as long as the economy was doing ok. Some of the people, though probably not Clinton, have some other axioms, which I'll agree are obsolete or outright bogus, like: -1) Government is inherently a good way to do things. -2) We can accomplish a lot of good things with our power. -3) We're not really interested in power for its own sake -4) We're smart enough to run a planned economy > Clipper is just the kind of woefully clueless thing people in > that position would come up with. It's not at all clueless. It's offensive, unAmerican, and probably won't win, but there's a subtle malignity to it that's almost Nixonesque in its cleverness, and it's tacky enough they may be able to pull it off. Bill # Bill Stewart AT&T Global Information Solutions, aka NCR Corp # 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204 fax-6399 # email bill.stewart at pleasantonca.ncr.com billstewart at attmail.com # ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465 From tcmay at netcom.com Tue Mar 1 23:54:44 1994 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 1 Mar 94 23:54:44 PST Subject: Quantum mechanics banned In-Reply-To: <9403020006.AA08655@anchor.ho.att.com> Message-ID: <199403020755.XAA26409@mail.netcom.com> > > > I think I have found the way to end all our problems: ESP. > > No good - the KGB has top psychics working for them, > and the CIA has been working for years to keep up. > I read it in the newspaper in the supermarket, > so it must be true! > > Bill Bill Stewart has failed to add that work on ESP is now classfied UMBRA SECRET SCARLET. The Jason Society has declared Puthoff and Targ's work on remote viewing to be of highest military significance and has moved the research to the National Rensaissance Organization at Fort Belvoir, Virginia. The work is run under codeword security, as part of DOD 451 deep black ops. Quantum cryptography has similarly been deemed of vital national importance to a secret research facility at Area 51 at Groom Lake. Encrypted blind pipes link the researchers to PROMIS databases at MITRE and Fort Monmouth Signal Warfare Lab. Quantum cryptography foils eavesdroppers, as you all know, so it cannot be allowed in the hands of private citizens. As Professor Denning puts it: "Would you want child pornographers to _also_ know how to calculate wave functions?" (However, not all is lost. Quantumpunks are reporting success in penetrating national borders by something they call "crypto tunnelling." Collapse of the Usenet wave function predicted. Sigh! or, as we quantumpunks prefer to say, "Psi.") I learned all this watching "The X-Files." --Tim May, in an unbound state (not California) -- .......................................................................... 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^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway." From hkhenson at cup.portal.com Wed Mar 2 00:23:38 1994 From: hkhenson at cup.portal.com (hkhenson at cup.portal.com) Date: Wed, 2 Mar 94 00:23:38 PST Subject: fyi Message-ID: <9403020024.1.28502@cup.portal.com> Sorry to inflict this *DRAFT* copy of a letter on the net, but I have begun to feel rather paranoid--the kind of feeling you get from stepping into deep water and being among sharks. (I wonder if Danny C. would have done better if he had kept the net informed as he went along?) I have been told that the court clerks and judge's secrataries (who work for the Justice Departement, and are not really under the control of the Judges) do abuse-of-process favors like thoes reported below for the US Attorneys all the time. When the name spellings and facts get checked, I plan to print it out, put on my suit, and hand deliver it to the Judge Patel in open court. I hope to report in a day or so. H. Keith Henson 799 Coffey Ct. San Jose, CA 95123 408-972-1132 Judge Marilyn Patel Northern District of California 450 Golden Gate Ave., 19th Floor San Francisco, CA 94102 March 1, 1994 Dear Judge Patel: As a friend of the court, I suggest you look into the actions of your clerks. It appears they withhold information from you and play games with your calendar. Last Thursday, Richard Williams (a lawyer from San Jose) made telephone contact with Ms Moriyama in the clerk's office. He had a motion to file for return of property and suppression of evidence in a case which itself involves a report of fraud on Judge Brazil to obtain a search warrant. Ms Moriyama told him that the motion could be placed on the calendar of your court for Monday, February 28, 1994 at 2:30 pm if he could get the motion filed early Friday morning. Mr. Williams had the motion filed by courier with the clerks office by about 9 am last Friday. He fully expected to be before your court Monday at 2:30. I learned of the hearing Friday and made plans to be there myself since my affidavit is part of this motion. Two of Mr. William's staffers talked to Ms Moriyama last Thursday, and are prepared to testify as to her agreement to putting the motion on your calendar, though the option was left open that you might shift it to some other department at the same hour. Monday about 10 am, Ms Moriyama called Mr. Williams saying she had no copy of the motion (two were filed) and denying that she had even agreed to put this matter on your calendar, or even that she had talked to Mr. Williams or his staff the previous week. She tried to get the matter placed before Judge Brenin, and when told that a Magistrate-Judge was unacceptable, she got the motion hearing placed on Judge Caulfield's calendar one day before the matter is to be moved to Tennessee, inflicting great costs and business damage upon the plaintiffs. While talking to Judge Caulfield's clerk on Monday, Mr. Williams was told that the US attorney had ordered the clerks to remove the motion from your calendar after it had been scheduled! Though I do not know that Judge Brazil ever saw the letter I wrote to him, one of his staff called me and left a long message (which I preserved) on my answering machine. In it, the staffer stated that it was not a Judge's role to investigate the fraud perpetrated on his court to which I had directed his attention, and that I should contact the US attorney if I wished the matter to be investigated. Given that the US attorney has manipulated your calendar to prevent these very matters from being brought to the attention of your court, I believe this approach would be akin to getting a fox to guard the henhouse. I have never considered myself a naive person. In spite of this, I have always felt that the judiciary in this country was honest. I still feel this way, but how effective can an honest judge be when their information channels are completely controlled by one party in a case? Sincerely, H. Keith Henson From nobody at jarthur Wed Mar 2 00:57:34 1994 From: nobody at jarthur (nobody at jarthur) Date: Wed, 2 Mar 94 00:57:34 PST Subject: No Subject Message-ID: <9403020857.AA13739@toad.com> Men in Dark Suits, sunglasses and trenchcoats FORCED Bob Cain to Say: > >it is well understood that only voluntary means of controling this >exist and that liklihood is very small. Persuasion is not working and >the press has been whipped into a near hysterical state over this by we >and our friends (yes, we on the internet are considered to be the force >that has derailed their hopes and that was unforseen.) Thanks Bob... that admission from the opposing forces has made all of our effort in this fight worth it... This makes the complete devaluation of this "Clipper/Tessara" nightmare relatively easy.... we doing good... keep the pressure up!! This has lifted the fog of battle for us momentarily... > >As is obvious I don't consider this government to be a monolithic >antagonistic entity out to strip us of rights. Sure it has happened in >areas but they are reasonably isolated areas. There are *many* people >in this rather diverse government and in an advising capacity to it >whose sole concern is our safety and these people are worried. I find My Saftey is REALLY NONE of THEIR concern... they have already insured in court they cant be held liable for mistakes... >it interesting that there are many people here who lack the imagination >to understand that there probably are a goodly number of reasons for >rightly feeling the need for a Clipper like solution and that it would >not be appropriate for the government to be public about them. Why is >that so difficult to understand in these times of international strife, >terror and technology? Here I start to wonder about you Bob... OUR Government caused the current issues we are seeing haunt this country... and they want the keys to ALL the secrest??? Not a chance in HELL Bob... I AND OTHERS WILL MAKE SURE THAT CLIPPER IS TOTALLY SUNK!!! count on it!! anon p.s. to the punks... keep it up... you are doing a GREAT job...(anon pats himself on the back also!!) > > >Peace, > >Bob > From pmetzger at lehman.com Wed Mar 2 04:15:29 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 2 Mar 94 04:15:29 PST Subject: Insecurity of public key crypto #1 (reply to Mandl) In-Reply-To: <199403020511.WAA21677@pmip.dist.maricopa.edu> Message-ID: <9403021214.AA21553@andria.lehman.com> Eric Johnson says: > : Please don't do that. I don't want to go through hoops to read this > : mailing list. It's already cumbersome as is. Adding PGP in the soup > : would make things very nasty. I'd rather not use PGP except for private > : messages. > > That was exactly the point Eric Hughes was making; it is not a good > strategy to save encryption for only private communications. > > Besides, procmail (or similar) should be able to handle piping > incoming cypherpunks traffic through the decryptor, so the hoop > would be transparent anyway. No muss, no fuss. So, will procmail run for someone getting this mailing list via CCMail under DOS? There are people doing that, you know. Its one thing to write tools so people can encrypt their routine PRIVATE mail. Its another thing to encrypt mailing lists read by hundreds of people. The former can be adjusted on a case by case basis -- the latter cannot. Perry From pmetzger at lehman.com Wed Mar 2 04:34:22 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 2 Mar 94 04:34:22 PST Subject: Dorothy Denning In-Reply-To: <9403020528.AA26183@tsx-11.MIT.EDU> Message-ID: <9403021233.AA21564@andria.lehman.com> Theodore Ts'o says: > I can imagine that back then, the Catholic church must have been deeply > opposed to letting the "hoi polloi" access to books, and access to > learning. Think of how it would disrupt the social order!!! Don't look back to the Catholics, Ted. The Russians and Chinese restricted access to printing presses, because they knew that they would permit the overthrow of the government. Dorothy and all the rest are Statists. They are no different from the Russians and the rest. The Communists wanted to restrict access to printing presses because they felt them to be a danger to their society, and Denning and the rest want to restrict cryptography for exactly the same reason. They have no love for the constitution -- they believe in "balancing" constitutional rights, "giving up" rights for "security" and all the rest. They THINK they have love for the constitution. They THINK they are patriots. In fact, they are no different in ANY of the arguments they make from fascists or communists. If Denning knew how much of what she said sounds exactly like stuff coming out of Pravda from the 1960s, she'd probably either flip or go into denial. I used to read translations of Pravda a lot as an original source for researching Soviet history. Her stuff also bears an uncanny resemblence to public statements made by Nazi leaders at various times about dangerous things the public couldn't get their hands on, and how various rights needed to be restricted in order to "protect" the public. > The important point that you make is that the cat really *is* out of the > bag; I am just concerned that the government, in a futile attempt to try > to stuff the cat back in, does perhaps fatal damage to all of our civil > rights in its desperation. People forget about the fact that rights are not just a nicety, the way Denning thinks. They are critical to our survival. The U. S. is not a nice place that happens to grant rights because it has a benevolent government -- it has a benevolent government and is a nice place because it grants rights. This crucial distinction is lost on those who would trade rights for safety -- the Dennings of the world believe safety is a commodity that may be purchased with rights. John Gilmore has noted that once you have replaced all a government's mechanisms with mechanisms that would be needed for a fascist government to run the country, fascism can be achived by a mere change in attitude by the governors. Denning and the rest don't grok that. They think "this is America; it can never happen here." My relatives who perished in the holocaust all said "this is Germany; the land of Goethe and Schiller; one of the greatest intellectual centers on earth; how can this happen here?" People never ask the distinction that made the U.S. government stable where others fall every few decades. They just assume it to be a fact of nature -- that they can play with the basis of that fact all they like without making the fact itself disappear. Cause and effect do not work that way. > Look at how civil forfeiture has been used > to completely strip someone of his properties, without any due process. > Look at the RICO act, and the truely scary things that you can do with > it; it was originally applied against the Big Bad Mob, but it's turning > out to have much broader applications. Once all telecommunications in this country are instantly interceptable; once all the FBI Digital Telephony crap and the Clipper crap are merged together, any fascist takeover could immediately start bugging all phones at will. They could immediately determine who their enemies were talking to at will. They could trace all economic transactions at will. (They want to be able to do that, too -- look at FinCen, also an idea "to protect us".) In short, this is a major tool that they would want. It looks so much like the premises behind the East German or Bulgarian phone network ran on that we should ask ourselves WHY. > So if the cat really is out of the bag, then the government should give > up on this ill-conceived Clipper abortion as soon as possible. It is, of course, already way too late for them to do anything. The damage they can do before they realize this might, however, be extreme. Perry From an64372 at anon.penet.fi Wed Mar 2 05:07:33 1994 From: an64372 at anon.penet.fi (an64372 at anon.penet.fi) Date: Wed, 2 Mar 94 05:07:33 PST Subject: Virtual Corporations to Avoid Taxes Message-ID: <9403021223.AA08175@anon.penet.fi> Timothy C. May writes: > Here's an area that has long fascinated me: using corporate entities > as a way to bypass taxes on individuals. > > [misc. examples deleted] I've been researching this and related topics (offshore corporations, non-U.S. banks, mail drops, etc.) and I have many ideas and questions I'd like to discuss. Is this an appropriate mailing list or does a superior venue exist? Is there enough interest for a new list? Are there any commercial providers that run electronic mailing lists (if so, how costly are they)? ------------------------------------------------------------------------- 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 Tomaz.Borstnar at arnes.si Wed Mar 2 05:24:08 1994 From: Tomaz.Borstnar at arnes.si (Tomaz Borstnar) Date: Wed, 2 Mar 94 05:24:08 PST Subject: Virtual Corporations to Avoid Taxes In-Reply-To: <9403021223.AA08175@anon.penet.fi> Message-ID: <9403021323.AA18119@toad.com> In-reply-to: Your message dated: Wed, 02 Mar 1994 12:23:29 -0300 > I've been researching this and related topics (offshore > corporations, non-U.S. banks, mail drops, etc.) and I have many ideas > and questions I'd like to discuss. Is this an appropriate mailing > list or does a superior venue exist? Is there enough interest for a Don't think so. We better get a new list. Tomaz From loofbour at cis.ohio-state.edu Wed Mar 2 06:52:01 1994 From: loofbour at cis.ohio-state.edu (Nathan Loofbourrow) Date: Wed, 2 Mar 94 06:52:01 PST Subject: Increasing the encrypted/unencrypted ratio (was Re: Insecurity of public key crypto #1 (reply to Mandl)) In-Reply-To: <9403021214.AA21553@andria.lehman.com> Message-ID: <199403021451.JAA28312@styracosaur.cis.ohio-state.edu> "Perry E. Metzger" writes: > Eric Johnson says: [in reply to bits about encrypting The List] > > Besides, procmail (or similar) should be able to handle piping > > incoming cypherpunks traffic through the decryptor, so the hoop > > would be transparent anyway. No muss, no fuss. > > So, will procmail run for someone getting this mailing list via CCMail > under DOS? There are people doing that, you know. Ah - so provide an unencrypted list for the software-challenged and the merely lazy. The incentive for using the encrypted list, then? Simple -- 1. Increasing ones personal encrypted-to-unencrypted ratio and 2. The old chestnut -- delay the unencrypted list 24 hours. Do I need to insert the stereotype that those who can't run procmail are probably experiencing worse delays than the above thanks to their UUCP feed? Or is enough to use the "information*timeliness=value" argument that's been advanced in the past to advocate encrypting traffic *to* the list? Either way, the rhetorical advantage still lies in the turnaround time to the list. > Its one thing to write tools so people can encrypt their routine > PRIVATE mail. Its another thing to encrypt mailing lists read by > hundreds of people. The former can be adjusted on a case by case basis > -- the latter cannot. I believe it's traditional to reply "Indeed." nathan From adam at bwh.harvard.edu Wed Mar 2 07:15:34 1994 From: adam at bwh.harvard.edu (Adam Shostack) Date: Wed, 2 Mar 94 07:15:34 PST Subject: low-overhead encrypted telnet In-Reply-To: Message-ID: <199403021514.KAA03435@duke.bwh.harvard.edu> Rolf wrote: | I am currently working on a project which requires encrypted TELNET. We | will be encrypting *all* transmitted data to protect sensitive | information -- not just passwords. Does anybody know the current status | of standardization of an encryption option for TELNET? I don't, but I would question the wisdom of putting lots of effort into a telnet encryption scheme. I would think it would be much more productive to build an encryption scheme at the network level, say, as packets are being encapsulated, so that users can specify that they want an encrypted session for telnet or ftp, or even sendmail could encrypt automatically when sending to certain hosts. By using a public key scheme to exchange session keys (much like PGP), you could obtain the public key affiliated with your destination IP, and know your packets are getting to the right place. A general framework, based on public key encryption would be a far more flexible, powerful and useful tool for generating security on the net than simply securing TELNET. Adam -- Adam Shostack adam at bwh.harvard.edu Politics. From the greek "poly," meaning many, and ticks, a small, annoying bloodsucker. Have you signed the anti-Clipper petition? From sdw at meaddata.com Wed Mar 2 07:49:46 1994 From: sdw at meaddata.com (Stephen Williams) Date: Wed, 2 Mar 94 07:49:46 PST Subject: stego In-Reply-To: <9403012217.AA05764@anchor.ho.att.com> Message-ID: <9403021550.AA05379@jungle.meaddata.com> > > Jim Choate's comments on steganography having problems with images > that are too complex or too simple were interesting. > Obviously, cartoon-like GIFs aren't a good target, though scanned > real stuff may be fine. Weather maps cna be good - back when I worked > with the things, I found you could really see about5-6 bits worth of > depth, and after that it didn't usually look much different - > we stole one or two values from the color-map to draw lines on > the satellite images to add state boundaries, various data values, etc., > but could have stolen the LSB and maybe 7th bit without major loss on > cloud-image pictures. (Radar pictures, on the other hand, were almost I haven't been able to keep up with all of the Stego discussion, but on pictures with few colors and a large amount of a small number of colors (like cartoons, etc. with a backround), you could use the unused color table entries. You set these to be the same colors as the correspondingly largest used colors and use them when juxtaposed with their color. Original: [0,A] 00000000000000000000000000000000000000000000000 000000000000000A000000000000000A000000000000000 000000000000000A000000000000000A000000000000000 000000000000000A000000000000000A000000000000000 000000000000000A000000000000000A000000000000000 000000000000000A000000000000000A000000000000000 000000000000000A000000000000000A000000000000000 00000000000000000000000000000000000000000000000 Stego-colormap: (1/0 repeat) [0=1,A=B] 01010101010101010101010101010101010101010101010 010101010101010B010101010101010B010101010101010 010101010101010B010101010101010B010101010101010 010101010101010B010101010101010B010101010101010 010101010101010B010101010101010B010101010101010 010101010101010B010101010101010B010101010101010 010101010101010B010101010101010B010101010101010 01010101010101010101010101010101010101010101010 Won't compress as well of course, but the picture is identical. Multiple color entries at the same setting could be used to encode more bits. (0=1=2=3 gives 2 bits info). You then leave the least used colors alone. More easily detectable I suppose though since multiple color settings were the same. One way around that is to make them just a shade off, which wouldn't change the actual color much. > all black, with one or two other pixel values, compressed to 2% of original > size, and would have been useless for hiding anything in.) > > Bill > -- Stephen D. Williams Local Internet Gateway Co.; SDW Systems 513 496-5223APager LIG dev./sales Internet: sdw at lig.net sdw at meaddata.com OO R&D Source Dist. By Horse: 2464 Rosina Dr., Miamisburg, OH 45342-6430 Comm. Consulting ICBM: 39 34N 85 15W I love it when a plan comes together From ejohnson at pmip.dist.maricopa.edu Wed Mar 2 07:50:23 1994 From: ejohnson at pmip.dist.maricopa.edu (Eric Johnson) Date: Wed, 2 Mar 94 07:50:23 PST Subject: Insecurity of public key crypto #1 (reply to Mandl) Message-ID: <199403021550.IAA22518@pmip.dist.maricopa.edu> : > : Please don't do that. I don't want to go through hoops to read this : > : mailing list. It's already cumbersome as is. Adding PGP in the soup : > : would make things very nasty. I'd rather not use PGP except for private : > : messages. : > : > That was exactly the point Eric Hughes was making; it is not a good : > strategy to save encryption for only private communications. : > : > Besides, procmail (or similar) should be able to handle piping : > incoming cypherpunks traffic through the decryptor, so the hoop : > would be transparent anyway. No muss, no fuss. : : So, will procmail run for someone getting this mailing list via CCMail : under DOS? There are people doing that, you know. Yes, I am aware of that. : Its one thing to write tools so people can encrypt their routine : PRIVATE mail. Its another thing to encrypt mailing lists read by : hundreds of people. The former can be adjusted on a case by case basis : -- the latter cannot. : : Perry I don't think "adjust[ing] on a case by case basis" is necessary. I was suggesting just the opposite. It obviously isn't a security issue. I believe it is more of a first principles issue; "Thou shall encrypt thy communications, lest thou draw attention to thy self, and the right be removed by thine opponents." Oh well, since it was deleted in the first reply to my reply, let's try this again: Eric Hughes wrote: : If part of your communications are encrypted and part are not you have : sent the message about what information is sensitive and what is not. : This difference in encoding is a fir-class message in it's own right. : : Therefore _all_ communications should be encrypted at all time. It is : no argument against the principle that this is difficult to do at the : current time. Perhaps I am misunderstanding the above (I think not; "_all_" is fairly inclusive). I understand your argument about routine PRIVATE mail. However, key exchange alone involves considerably more hassle than what I am suggesting (and judging from the reply I got from Eric Hughes, I gather encrypting the list is hardly a new idea) which is this: there would be a tangible benefit from encrypting a list like cypherpunks with a well-known, even casual grade key. For God's sake, *especially* cypherpunks (you know, the name, power of example and all that) If the tools need to be built for some platform; well, "cypherpunks write code". Pipes _are_ available under DOS, you know. --Eric From pmetzger at lehman.com Wed Mar 2 08:03:57 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 2 Mar 94 08:03:57 PST Subject: Insecurity of public key crypto #1 (reply to Mandl) In-Reply-To: <199403021550.IAA22518@pmip.dist.maricopa.edu> Message-ID: <9403021603.AA21658@andria.lehman.com> Eric Johnson says: > I don't think "adjust[ing] on a case by case basis" is necessary. > I was suggesting just the opposite. It obviously isn't a security > issue. I believe it is more of a first principles issue; "Thou > shall encrypt thy communications, lest thou draw attention to thy > self, and the right be removed by thine opponents." You miss the point, Eric. We are advocating that IN THE FUTURE all communications should be encrypted. However, FOR THE MOMENT this is often impractical. Cypherpunks write code in an effort to try to bring this future closer. However, making our lives impossible right now will delay that future. I encrypt things whenever possible. Some people I communicate with can't encrypt, so I adjust, on a case by case basis. Someday, hopefully within the next year or two, things will be different. Encrypting this list ever would be useless -- but fine if it would be easy to do. Since it isn't easy or useful, it is a bad idea. Perry From freeman at MasPar.COM Wed Mar 2 08:06:44 1994 From: freeman at MasPar.COM (Jay R. Freeman) Date: Wed, 2 Mar 94 08:06:44 PST Subject: Quantum mechanics banned Message-ID: <9403021606.AA25085@cleo.MasPar.Com> Tim May discusses ESP and quantum cryptography... > I learned all this watching "The X-Files." Well, *I* learned it by watching a crystal ball. -- Jay Freeman From hughes at ah.com Wed Mar 2 08:27:23 1994 From: hughes at ah.com (Eric Hughes) Date: Wed, 2 Mar 94 08:27:23 PST Subject: low-overhead encrypted telnet In-Reply-To: <199403021514.KAA03435@duke.bwh.harvard.edu> Message-ID: <9403021619.AA10508@ah.com> > I don't, but I would question the wisdom of putting lots of >effort into a telnet encryption scheme. I would think it would be >much more productive to build an encryption scheme at the network >level The reason that encrypted telnet is a good thing is that modification at the network level requires kernel modification, and encrypting a telnet does not. Installing an encrypted telnet daemon does require sysadmin cooperation, but it doesn't mean recompiling the kernel. As such, encrypted telnet is a good intermediate while the long term solution of encrypted IP gets developed and deployed. Eric From hughes at ah.com Wed Mar 2 08:30:14 1994 From: hughes at ah.com (Eric Hughes) Date: Wed, 2 Mar 94 08:30:14 PST Subject: Increasing the encrypted/unencrypted ratio (was Re: Insecurity of public key crypto #1 (reply to Mandl)) In-Reply-To: <199403021451.JAA28312@styracosaur.cis.ohio-state.edu> Message-ID: <9403021622.AA10519@ah.com> >The incentive for using the encrypted list, then? Simple -- > 1. Increasing ones personal encrypted-to-unencrypted ratio >and > 2. The old chestnut -- delay the unencrypted list 24 hours. I'll consider doing this after a whole bunch more stuff is developed, like checking for digital signatures on posts and delaying those without them. We're now running majordomo for the list, so if these features get added to the standard majordomo distribution, we could more easily deploy them. That's a hint, since I have higher priority things to work on. Eric From pmetzger at lehman.com Wed Mar 2 08:33:01 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 2 Mar 94 08:33:01 PST Subject: low-overhead encrypted telnet In-Reply-To: <9403021619.AA10508@ah.com> Message-ID: <9403021632.AA21725@andria.lehman.com> Eric Hughes says: > The reason that encrypted telnet is a good thing is that modification > at the network level requires kernel modification, and encrypting a > telnet does not. Installing an encrypted telnet daemon does require > sysadmin cooperation, but it doesn't mean recompiling the kernel. Although running an encrypted IP stack does require sysadmin cooperation, it does not require a kernel rebuild -- John Ioannidis has built modloadable versions of most of the swIPe software. > As such, encrypted telnet is a good intermediate while the long term > solution of encrypted IP gets developed and deployed. Agreed -- sadly its arriving VERY slowly. 4.4BSD Lite comes with a standards-compliant encrypted telnet implementation, however. Perry From hughes at ah.com Wed Mar 2 08:37:22 1994 From: hughes at ah.com (Eric Hughes) Date: Wed, 2 Mar 94 08:37:22 PST Subject: Insecurity of public key crypto #1 (reply to Mandl) In-Reply-To: <199403021550.IAA22518@pmip.dist.maricopa.edu> Message-ID: <9403021629.AA10563@ah.com> I wrote: >: Therefore _all_ communications should be encrypted at all time. It is >: no argument against the principle that this is difficult to do at the >: current time. >there would be a tangible benefit from encrypting >a list like cypherpunks with a well-known, even casual grade key. Yes, there would be a benefit for those who are working specifically on mailers, but for those, like me, of course, who aren't, it would be a royal pain in the ass. This is an argument against the practice of encrypting all traffic, not the principle. And this argument only holds in the present time; it won't hold in the future. As Perry points out, we aren't where we want to be. Yet. Eric From smb at research.att.com Wed Mar 2 08:46:23 1994 From: smb at research.att.com (smb at research.att.com) Date: Wed, 2 Mar 94 08:46:23 PST Subject: low-overhead encrypted telnet Message-ID: <9403021646.AA21038@toad.com> Eric Hughes says: > The reason that encrypted telnet is a good thing is that modificatio n > at the network level requires kernel modification, and encrypting a > telnet does not. Installing an encrypted telnet daemon does require > sysadmin cooperation, but it doesn't mean recompiling the kernel. Although running an encrypted IP stack does require sysadmin cooperation, it does not require a kernel rebuild -- John Ioannidis has built modloadable versions of most of the swIPe software. Assuming, of course, that you're running a system that has modload. (Ironically, CERT has recommended that you delete loadable device drivers from systems that don't need them, as a way to guard against password- sniffers.) > As such, encrypted telnet is a good intermediate while the long term > solution of encrypted IP gets developed and deployed. Agreed -- sadly its arriving VERY slowly. 4.4BSD Lite comes with a standards-compliant encrypted telnet implementation, however. What standards? There are no RFCs, nor any current drafts, that define a telnet encryption option. The last draft I saw was from 1991, and Internet drafts expire after 6 months. As I recall, the idea that was being pushed then was to integrate encryption more closely with authentication. From pmetzger at lehman.com Wed Mar 2 08:53:43 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 2 Mar 94 08:53:43 PST Subject: low-overhead encrypted telnet In-Reply-To: <199403021644.LAA09602@lehman.com> Message-ID: <9403021653.AA21794@andria.lehman.com> smb at research.att.com says: > Agreed -- sadly its arriving VERY slowly. 4.4BSD Lite comes with a > standards-compliant encrypted telnet implementation, however. > > What standards? There are no RFCs, nor any current drafts, that define > a telnet encryption option. The last draft I saw was from 1991, and > Internet drafts expire after 6 months. As I recall, the idea that was > being pushed then was to integrate encryption more closely with > authentication. There are much more recent drafts, Steve -- the telnet authentication option is now RFC1409, as of early last year, and the encryption draft is dated April 1993 -- see the nearest internet drafts mirror for a copy. Your recollection of the desire to merge authentication and encryption is correct -- to my knowledge, the new Cray telnet is an implementation of the currently circulated draft (which was also written at Cray). Perry From pmetzger at lehman.com Wed Mar 2 08:55:09 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 2 Mar 94 08:55:09 PST Subject: low-overhead encrypted telnet In-Reply-To: <9403021646.AA21038@toad.com> Message-ID: <9403021654.AA21811@andria.lehman.com> smb at research.att.com says: > Although running an encrypted IP stack does require sysadmin > cooperation, it does not require a kernel rebuild -- John Ioannidis > has built modloadable versions of most of the swIPe software. > > Assuming, of course, that you're running a system that has modload. > (Ironically, CERT has recommended that you delete loadable device drivers > from systems that don't need them, as a way to guard against password- > sniffers.) A short sighted view. You can't stop line monitoring -- you should defend against it with encryption instead. In an environment like mine, there are literally thousands of potential line monitoring points that I cannot defend, but encryption gives me real security. Perry From cme at sw.stratus.com Wed Mar 2 09:01:11 1994 From: cme at sw.stratus.com (Carl Ellison) Date: Wed, 2 Mar 94 09:01:11 PST Subject: PGP on the HP 100 Message-ID: <199403021700.MAA04776@galt.sw.stratus.com> >Has anyone tried putting ViaCrypt PGP on the HP-100? Is anyone but >me crazy enough to contemplate it? How abysmal is the performance? I may be crazier. I put it on a Mac (660) using SoftPC. It performs about like on a 286. However, that's plenty fast enough for my uses. - Carl From kermit at ics.forth.gr Wed Mar 2 09:02:04 1994 From: kermit at ics.forth.gr (Aggelos D. Keromitis) Date: Wed, 2 Mar 94 09:02:04 PST Subject: low-overhead encrypted telnet In-Reply-To: <9403021619.AA10508@ah.com> Message-ID: <199403021702.AA24705@pythia.ics.forth.gr> In message <9403021619.AA10508 at ah.com>, Eric Hughes writes: >The reason that encrypted telnet is a good thing is that modification >at the network level requires kernel modification, and encrypting a >telnet does not. Installing an encrypted telnet daemon does require >sysadmin cooperation, but it doesn't mean recompiling the kernel. > >As such, encrypted telnet is a good intermediate while the long term >solution of encrypted IP gets developed and deployed. > Has anyone (other than me that is :) thought of changing just the library routines for setsockopt/getsockopt/send/recv ? It wouldnt be too hard (me thinks) to do it, but i dont know where to find the sockets library. -Aggelos ----------------------------------------------------------------------------- Aggelos Keromitis kermit at csd.uch.gr Heraclion, Greece kermit at ics.forth.gr Finger kermit at calliope.ics.forth.gr for public PGP key ----------------------------------------------------------------------------- From blancw at microsoft.com Wed Mar 2 09:10:30 1994 From: blancw at microsoft.com (Blanc Weber) Date: Wed, 2 Mar 94 09:10:30 PST Subject: Virtual Corporations Per Se Message-ID: <9403021711.AA05232@netmail2.microsoft.com> > I've been researching this and related topics (offshore > corporations, non-U.S. banks, mail drops, etc.) and I have many ideas > and questions I'd like to discuss. Is this an appropriate mailing > list or does a superior venue exist? Is there enough interest for a >Don't think so. We better get a new list. .............................................. *I'm* interested ....... not simply to avoid taxes, but to live as a Hitchhiker Citizen of the Galaxy. :>) If a new list is started, you can add my name. ~ Blanc From deeb at meceng.coe.neu.edu Wed Mar 2 09:18:29 1994 From: deeb at meceng.coe.neu.edu (Stephen Humble) Date: Wed, 2 Mar 94 09:18:29 PST Subject: clipper + enaction = illegal alternate encryption In-Reply-To: <199403020257.SAA26110@netcom9.netcom.com> Message-ID: <9403021716.AA15267@meceng.coe.neu.edu> rcain at netcom.com (Robert Cain) sez: > There really is a strong argument from their side that says if one > must use a form that is immune from a compromise like well escrowed > keys one is *way* more than likely to be discussing something most > of us would want LE or NS to know about. I know that argument is > anathema here but I am finding it more and more compelling. I think "anathema" may be the wrong word - I would suggest "incorrect". As the number of people who habitually use strong crypto grows, the nefarious conversations will be lost in the noise about last night's party and recipes for chocolate truffle cake. The likelihood that any particular conversation is of interest to LE/NS types must drop as well. This will be true unless the number of strongly-encrypted nefarious conversations grows at least as fast as the total number of strongly-encrypted conversations. Somehow I fail to believe that the supply of crooks is so large. From Rolf.Michelsen at delab.sintef.no Wed Mar 2 09:20:30 1994 From: Rolf.Michelsen at delab.sintef.no (Rolf Michelsen) Date: Wed, 2 Mar 94 09:20:30 PST Subject: low-overhead encrypted telnet In-Reply-To: <199403021514.KAA03435@duke.bwh.harvard.edu> Message-ID: On Wed, 2 Mar 1994, Adam Shostack wrote: > I don't, but I would question the wisdom of putting lots of > effort into a telnet encryption scheme. I would think it would be > much more productive to build an encryption scheme at the network > level, say, as packets are being encapsulated, so that users can > specify that they want an encrypted session for telnet or ftp, or even > sendmail could encrypt automatically when sending to certain hosts. I agree with your observation. The Telnet protocol is however independent of any underlying network protocol. In our application the Telnet connection can be established over a lot of different types of networks. Implementing secure IP will not give us much since it does not cover the other possibilities for a Telnet connection. It is also a question of resources (read "time") -- we require a solution *now* (and preferable yesterday :-) No flame, just an observation that what seems to be a better solution is not always suitable... -- Rolf ---------------------------------------------------------------------- Rolf Michelsen Phone: +47 73 59 87 33 SINTEF DELAB Email: rolf.michelsen at delab.sintef.no 7034 Trondheim Office: C339 Norway ---------------------------------------------------------------------- From cme at sw.stratus.com Wed Mar 2 09:42:03 1994 From: cme at sw.stratus.com (Carl Ellison) Date: Wed, 2 Mar 94 09:42:03 PST Subject: Bob Cain's mind switch Message-ID: <199403021741.MAA04800@galt.sw.stratus.com> Bob wrote: >The real issue is that this is an *enabling* technology that allows any >group of people distributed over the world to meet spontaneously in >secret to plan anything. I don't think we can even conceive, nor have >they yet, the ways the real Bad Guys (I hope we can agree that some >do exist) might find to use this new ability. A very clear danger is >sensed in Washington with little real benefit to the civilized and >civil majority. There's no question that this is a possibility. It exists. However, Clipper won't make it go away. There's no Daddy to run home to. In fact, this has always been a possibility, unless you believe that all hotel rooms, bus stations, city parks, farmer's fields, men's rooms, women's rooms, ..., are bugged and will continue to be (so that clandestine meetings can be overheard). Now, the next step for the NSA and FBI is to get on the stick and discover ways to counter this threat. Now that PCs permit criminal organizations to create their own strong crypto and worldwide communication allows them to telecommute cheaply, interaction among criminals for planning purposes will be enhanced just as interaction among businesspeople and computer designers is. The world is changing -- as usual -- and LE needs to keep up -- as usual. --------- That isn't hopeless. However, it requires thinking in new ways and I don't expect bureaucrats to be able to do that. Perhaps technical people need to be given a free hand. :-| Maybe the result is that there is no security. For example, we should not expect to achieve more protection from plans laid during electronic meetings than we would achieve from plans laid during physical meetings. ..and, no, I don't believe there should be a law prohibiting private physical meetings. There will *always* be some insecurity. There is always a nut with a gun out there. There are also car accidents. I am not totally safe and would not want to live in a world in which the police are powerful enough to make it that safe. ---------- What I kept suggesting to Dorothy Denning, as this flap was building, was that: 1. the gov't should immediately drop the Clipper proposal because it's alienating people who need to be on the gov't's side; 2. the gov't should actively promote encryption of cellular calls with an untappable algorithm, for the over the air link (with conversion back to clear voice once it hits the cellular office) -- providing the public with trustworthy security, addressing the public's biggest security threat and therefore reducing the market demand for encryption which interferes with wiretaps; and 3. the LE and intelligence community should recognize that the world has changed beyond the point of no return, thanks to the PC and to communications technology, and there is no way to prevent criminals from using totally secure cryptography to aid in their plans. Criminals have always had access to strong cryptography for their communications (cf., Kahn talking about the rum runners, for example (Elizabeth Friedman's efforts as a cryptanalyst)) and the world hasn't fallen apart yet. However, the PC and high speed digital communications mark a slight change in the landscape and these changes need to fuel some good, creative, technical work -- not a bureaucratic running-scared retreat to an impotent "there oughtta be a law". I don't know if it's too late, thanks to the FBI and NSA serious alienation of people (like us) who matter. It might be. Once they declared war on us, it's unlikely to expect us to suddenly look at them as good guys. However, if they followed my 3 step plan right now, they'd have a chance still -- at least, I believe they would. - Carl From mccoy at ccwf.cc.utexas.edu Wed Mar 2 09:46:04 1994 From: mccoy at ccwf.cc.utexas.edu (Jim McCoy) Date: Wed, 2 Mar 94 09:46:04 PST Subject: low-overhead encrypted telnet In-Reply-To: <9403021646.AA21038@toad.com> Message-ID: <199403021745.AA00455@tramp.cc.utexas.edu> smb at research.att.com writes: > > Agreed -- sadly its arriving VERY slowly. 4.4BSD Lite comes with a > standards-compliant encrypted telnet implementation, however. > > What standards? There are no RFCs, nor any current drafts, that define > a telnet encryption option. The last draft I saw was from 1991, and > Internet drafts expire after 6 months. As I recall, the idea that was > being pushed then was to integrate encryption more closely with > authentication. There is currently a chunk of code in the standard 4.3/4 telnet ref implementation that does encryption (DES in OFB, CFB, and ECB modes) It is a part of the AUTH-ENCRYPT module that is part of the telnet option specifications. There is work being done by the AUTH-ENCRYPT working group to try to get authorization tied more closely to the encryption options (last I heard they were slowing down and had hit a problem exchanging IVs for the encryption.) This work is using authorization methods (Kerberos, SPC, RSA) to drop in the key for the encryption. There is work being done by the IPSEC working group to add encryption to the IP layer of the protocol stack (telnet et al work at higher levels) but I have not read anything recent from this group in a while and last I checked they were still hashing out design details so I would not expect anything on this front for a while. There are a couple of people in Austin who have a version of the telnet ref implementation that will do a D-H exchange of 688 bits which can then be used by the ENCRYPT option and are trying to figure out which direction the AUTH-ENCRYPT people are going so that they can make the DHX option fit in seamlessly with the AUTH-ENC stuff (the DHX exchange tries to be first and start up an encrypted stream and if the AUTH-ENC option is invoked after the DHX exchange we want to switch to the new key without disruption.) Unfortunately 1994 has been a busy year, but hopefully there will be an alpha or beta for CPs to test next week... jim From russw at netcom.com Wed Mar 2 09:47:14 1994 From: russw at netcom.com (Russell Earl Whitaker) Date: Wed, 2 Mar 94 09:47:14 PST Subject: ALERT: UK anti-porn network proposal Message-ID: <199403021747.JAA20523@mail.netcom.com> The author of the following notice is in a sensitive vocational position, and has asked me to post the following... ###BEGIN### A Home Office press release issued on 15 Feb 94 announces the intention of the Home Secretary to crack down on computer-distributed pornography. Accordingly, last week the government introduced an amendment to the Criminal Justice and Public Order Bill which is pending before Parliament. The new clause in the Bill would amend the definition of *publication* in the Obscene Publications Act 1959. It is currently considered *publication* of a pornograph image if one *record, shows, plays, or projects it.* The proposed amendment would change this to read: ... record, shows, plays, or projects it, or, where the matter is stored electronically, transmits that data. The problem, of course, is that there is no definition of what it means *to transmit* pornographic data. There is no distinction drawn between primary and secondary transmission. This could mean that bulletin board sysops, commercial sites with Usenet feeds, and even BT, could ALL be engaged in the *transmission* of pornographic data. If this is correct, then people in the position of innocent intermediary would have to rely upon a defense of *innocent dissemination*, much like that found in UK defamation law. Essentially, if the police could show that pornographic images had passed over one's computer equipment, then one would have to prove that he *had not examined the [pornographic] article and had no reasonable cause to suspect* that its publication was illegal. Aside from being in the uncomfortable position of having to prove one's ignorance, the *reasonable cause* language may imply a duty to inspect certain data in a vain attempt to see if it contains pornographic images. This especially could be true where one provides a data feed to a known past-pornographer. It is not entirely clear why the Home Office thinks that this amendment is necessary. If the intention is to catch commercial pornographers, it would appear that *record* should include recording to CD-ROM or into RAM. Likewise, *play* should catch purchasers. The justification might be that proof of recording and playing is much more difficult than proof of transmission. CAVEAT: This discussion does not include radio and television broadcasts. There is a seperate section of the Act which specifically addresses this area. It is not clear whether or not the proposed *transmits* language would have any effect upon that section, but presumably it could. It is difficult to believe that large players like BT, Mercury, CompuServe, etc, will let this pass without a fight. It could also be, however, that they are unaware of the possible ramifications of the proposed amendment. ###END### [I will forward responses to this message. - Russell] Russell Earl Whitaker russw at netcom.com Director, Extropy Institute 408-366-5435 ================================================================ From koontzd at lrcs.loral.com Wed Mar 2 09:49:26 1994 From: koontzd at lrcs.loral.com (David Koontz ) Date: Wed, 2 Mar 94 09:49:26 PST Subject: Clipper/Skipjack Message-ID: <9403021748.AA06716@io.lrcs.loral.com> >just a quick note to tell you all that I just read an editorial in >info security by John Droge. >Anyway, I was wondering why any sane, 1/10 intelligent person would be >defending the Clipper chip...then I read his bio...he is a VP at >Mykotronx. He is also the marketing manager for CLIPPER/CAPSTONE From wex at media.mit.edu Wed Mar 2 09:54:39 1994 From: wex at media.mit.edu (Alan (Miburi-san) Wexelblat) Date: Wed, 2 Mar 94 09:54:39 PST Subject: Dorothy Denning In-Reply-To: <199403020410.UAA07525@netcom9.netcom.com> Message-ID: <9403021753.AA28687@media.mit.edu> Wow, Bob, what a vision. You (and Dr Denning and certainly the gov't) seem to be afraid that: > any group of people distributed over the world [can] meet spontaneously in > secret to plan anything. Freedom of association was so revered by the founders of this country that they put it in the very first amendment to the Constitution. If I am not free to meet with my friends, associates or others, then what freedom do I have? Yes, I'm a First Amendment purist. I'm sorry, but visions of nameless, faceless "Bad Guys" with nameless, faceless nefarious plans just don't move me. I understand that the pro-Clipper people feel a real danger and are trying to block against it. But there are real nameable, quantifiable dangers all around me and if I want protection I'll ask for it. Till then... First they stole the fourth amendment. I said nothing because I don't deal drugs. Then they took the sixth amendment. I was silent because I know I'm not guilty. When they came for the second amendment, I kept quiet because I don't own a gun. Now they've come for the first amendment, and I can't say anything at all. --Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard Media Lab - Advanced Human Interface Group wex at media.mit.edu Voice: 617-258-9168 Page: 617-945-1842 na53607 at anon.penet.fi We are Chaos Boys. We are coming to a paradigm near you. From mccoy at ccwf.cc.utexas.edu Wed Mar 2 09:55:45 1994 From: mccoy at ccwf.cc.utexas.edu (Jim McCoy) Date: Wed, 2 Mar 94 09:55:45 PST Subject: low-overhead encrypted telnet In-Reply-To: <199403021514.KAA03435@duke.bwh.harvard.edu> Message-ID: <199403021755.AA00466@tramp.cc.utexas.edu> Adam Shostack writes: > > A general framework, based on public key encryption would be a > far more flexible, powerful and useful tool for generating security on > the net than simply securing TELNET. I sincerely doubt that such a system would be designed or implemented before the turn of the century. All one needs to do is take a look at the PEM key certification authority clusterfuck to see just how difficult it can be to implment something like this. The additional benefits that adding encryption to telnet offer is that the telnet protocol is used in more areas than telnet. Many programs and protocols use the telnet system for control channels and other bits so that a significant change to telnet can have ramifications beyond just the obvious ones... jim From wex at media.mit.edu Wed Mar 2 10:05:50 1994 From: wex at media.mit.edu (Alan (Miburi-san) Wexelblat) Date: Wed, 2 Mar 94 10:05:50 PST Subject: 'Nother possible Stego place... Message-ID: <9403021805.AA03150@media.mit.edu> It's a bit of a hack, but don't most char implementations in C just ignore the high-order bit? --Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard Media Lab - Advanced Human Interface Group wex at media.mit.edu Voice: 617-258-9168 Page: 617-945-1842 na53607 at anon.penet.fi We are Chaos Boys. We are coming to a paradigm near you. From ejohnson at pmip.dist.maricopa.edu Wed Mar 2 10:28:26 1994 From: ejohnson at pmip.dist.maricopa.edu (Eric Johnson) Date: Wed, 2 Mar 94 10:28:26 PST Subject: encrypting the list (Was Re: Insecurity of public key) Message-ID: <199403021828.LAA22914@pmip.dist.maricopa.edu> : Eric Johnson says: : > I don't think "adjust[ing] on a case by case basis" is necessary. : > I was suggesting just the opposite. It obviously isn't a security : > issue. I believe it is more of a first principles issue; "Thou : > shall encrypt thy communications, lest thou draw attention to thy : > self, and the right be removed by thine opponents." : : You miss the point, Eric. We are advocating that IN THE FUTURE all : communications should be encrypted. However, FOR THE MOMENT this is : often impractical. Cypherpunks write code in an effort to try to bring : this future closer. However, making our lives impossible right now : will delay that future. This is hyperbole. It would not make our lives impossible. And far from delaying the future, as it relates to communications on the list, I would argue that it would reduce the signal-to-noise ratio immensely, thereby hastening the deployment of tools. So I don't think I'm missing the point simply by disagreeing with you. : I encrypt things whenever possible. Some people I communicate with : can't encrypt, so I adjust, on a case by case basis. Someday, : hopefully within the next year or two, things will be different. : : Encrypting this list ever would be useless -- but fine if it would : be easy to do. Since it isn't easy or useful, it is a bad idea. It's usefulness depends both upon whether you think increasing the ratio of cryptext vs. cleartext to your system is useful, and whether easy is defined by the least capable systems on the list. Don't worry. I'll drop it here. : : Perry BTW, you don't have to shout. I can read upper-lower case text without difficulty. --Eric From tcmay at netcom.com Wed Mar 2 10:38:38 1994 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 2 Mar 94 10:38:38 PST Subject: Laziness? In-Reply-To: <199403021451.JAA28312@styracosaur.cis.ohio-state.edu> Message-ID: <199403021838.KAA19172@mail.netcom.com> (I've changed the subject line to something much shorter than the 2 lines+ of the previous subject line. And hopefully more germane to my point.) Nathan Loofbourrow writes: > Ah - so provide an unencrypted list for the software-challenged and > the merely lazy. > > The incentive for using the encrypted list, then? Simple -- > 1. Increasing ones personal encrypted-to-unencrypted ratio > and > 2. The old chestnut -- delay the unencrypted list 24 hours. ... > I believe it's traditional to reply "Indeed." Indeed---NOT! I don't consider myself especially "lazy" when it comes to this list, nor do I consider myself "software-challenged." I connect to the Net from my home Mac IIci or PowerBook 170 over a 14.4 modem line to Netcom, an Internet service provider many of you are familiar with. Once on Netcome, I have access to a wide range of standard UNIX tools. However, I do NOT run PGP on these machines! Rather, I run MacPGP (or PGP on my DOS machines, in emergencies, or even "MailSafe" in rare circumstances) on my *home* machine, after first downloading the mail with "Eudora 2.0," a nice off-line mail reader. It still takes several steps, as most of you can imagine. I don't plan to start using PGP on insecure machines, even with a shortened "UNIX-grade" key. Especially not for a mailing list, where encryption is pointless (except to increase encrypted traffic a bit). Downloading and then decrypting 100 or more messages a day is not a viable option, and such a move would cause me to unsubscribe from the list rather quickly. (To clarify this: I read the list with "elm," when I am on Netcom doing other things as well, like reading NetNews, and am thus able to delete about half of all messages before eventually--every few days, typically--dowloading the whole batch. Encrypted traffic would make this screening and immediate response much more difficult.) If Nathan is running PGP on a multi-user system, such as campus machines at Ohio State, he is likely deluding himself about actual security. Others at the site may already have his private key and passphrase captured. If he is running PGP on his own private machine, with good Net connectivity, congratulations. Most of us--I think it's safe to say--don't have these options. Many are reading from university accounts, from commercial services like CompuServe, and even from multiple services (depending on location). Not running PGP on each and every message doesn't mean we're lazy--it means we've got better things to do with our time. As for Nathan Loofbourrow's charge that this must mean I am lazy and/or software-challenged, I suggest he try writing more posts for this list and/or writing code. Sorry to sound harsh, but calling us lazy and software-challenged is not addressing the real issues. --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^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway." From deeb at meceng.coe.neu.edu Wed Mar 2 11:15:09 1994 From: deeb at meceng.coe.neu.edu (Stephen Humble) Date: Wed, 2 Mar 94 11:15:09 PST Subject: 'Nother possible Stego place... In-Reply-To: <9403021805.AA03150@media.mit.edu> Message-ID: <9403021910.AB17243@meceng.coe.neu.edu> "Alan (Miburi-san) Wexelblat" sez: > It's a bit of a hack, but don't most char implementations in C just > ignore the high-order bit? No. A char in C is signed or unsigned according to the whim of the compiler designer, but all bits are significant. Some UN*X editors have a nasty habit of nuking the high bit. Vi frequently does, GNU emacs doesn't. Stephen From pmetzger at lehman.com Wed Mar 2 11:23:08 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 2 Mar 94 11:23:08 PST Subject: encrypting the list (Was Re: Insecurity of public key) In-Reply-To: <199403021828.LAA22914@pmip.dist.maricopa.edu> Message-ID: <9403021922.AA22150@andria.lehman.com> Eric Johnson says: > : You miss the point, Eric. We are advocating that IN THE FUTURE all > : communications should be encrypted. However, FOR THE MOMENT this is > : often impractical. Cypherpunks write code in an effort to try to bring > : this future closer. However, making our lives impossible right now > : will delay that future. > > This is hyperbole. It would not make our lives impossible. Speak for yourself. I process five hundred or more messages a day. Anything that would add even moments to the time it takes me to reply to a message would eliminate whats left of the time I spend with my friends and S.O. Maybe you have lots of time on your hands, but the rest of us have real lives and don't want to spend them trying to set up a cryptography system for each of our correspondants. In a year or so, maybe this will all likely be practical -- but it isn't now. You are more or less like someone in 1976 advocating that everyone quit typing and start using only word processors, when the computers weren't yet cheap enough. Have some patience. Perry From rre-request at weber.ucsd.edu Wed Mar 2 12:04:27 1994 From: rre-request at weber.ucsd.edu (rre-request at weber.ucsd.edu) Date: Wed, 2 Mar 1994 12:04:27 -0800 Subject: archive send: prescription In-Reply-To: <199403022004.PAA22755@eff.org> References: <199403022004.PAA22755@eff.org> Message-ID: <199403022004.MAA04685@weber.ucsd.edu> File: prescription BEGIN---------------cut here------------------ Date: Fri, 18 Feb 94 15:33:43 +0000 From: G.Joly at cs.ucl.ac.uk (Gordon Joly) Subject: MICE Seminar for February 22 at 14:00 GMT. Newsgroups: dec.mail.lists.rem-conf You are invited to the next MICE International Seminar which will take place next week. Please limit traffic for two hours from 14:00 GMT on Tuesday, February 22. This seminar will be transmitted on the usual multicast addresses (please see the sd entry), and will be advertised in sd from Tuesday morning. Further information of this and future seminars is kept in the URL http://www.cs.ucl.ac.uk/mice/seminars.html Bruno Struif (GMD) speaking from Darmstadt, Germany will give a presentation on: "The Privacy Enhanced Electronic Prescription". Abstract -------- In Germany, more than 500 millions prescriptions are issued per year. Normally, the patient receives the prescription in the doctor's practice and takes it to a pharmacy where he gets his medicaments. From the pharmacy, the prescription is physically transported to a pharmacy computer center where it will be processed in different ways. Finally the patient health insurance gets this prescription with listings containing the result of the processing in the pharmacy computer center. Since the prescription is a paper document, the processing is difficult, time-consuming and cost-intensive. The introduction of the health insurance card in Germany will improve the technological environment in the doctor's practices.The prescriptions will be produced in the future by using the health insurance card, a personal computer and a printer. The model presented shows that the electronic presentation of the prescription produced in the doctor's PC can be maintained so that the difficult and expensive way of processing paper prescriptions in the pharmacy, the pharmacy's computer center and finally by the health insurance can be avoided. The solution described and already implemented at GMD is - to sign the electronic prescription by the doctor with its physician smartcard capable to compute digital signatures - to write the electronic prescription in the patient's smartcard - to prove the authorization of a pharmacist for the access to the patient's smartcard by using a pharmacist smartcard - to electronically transmit the electronic prescription together with pharmacy information (name of the pharmacy, prescription cost etc) to the pharmacy computer center or the health insurance computing center where it can be automatically processed. The patient gets therefore two representation forms of the prescription, the electronic form and the paper form. The paper form is still necessary in the relationship doctor/patient/pharmacist, since - the patient has a right to look on the issued prescription, - in case of malfunction of the patient's smartcard in the pharmacy the delivery of the medicaments has still to be possible and - the assembly of the medicaments is easier with a paper form in the hand. In the new release of the electronic prescription model a step in the direction of data privacy has been made. The personal data of the patient and the doctor are replaced by digital pseudonyms in a way that the pharmacy computing center and the health insurance can verify only certain characteristics, e.g. that the prescription has been issued by a registered doctor and that the related patient is a member of the respective health insurance. In special cases, a re-identification of the doctor or the patient is possible by using re-identification smartcards. Gordon Joly Phone +44 71 380 7934 FAX +44 71 387 1397 Email: G.Joly at cs.ucl.ac.uk UUCP: ...!{uunet,uknet}!ucl-cs!G.Joly Comp Sci, University College, London, Gower Street, LONDON WC1E 6BT WWW WWW WWW http://www.cs.ucl.ac.uk/mice/gjoly.html WWW WWW WWW END-----------------cut here------------------ -- Stanton McCandlish * mech at eff.org * Electronic Frontier Found. OnlineActivist F O R M O R E I N F O, E - M A I L T O: I N F O @ E F F . O R G O P E N P L A T F O R M O N L I N E R I G H T S V I R T U A L C U L T U R E C R Y P T O From area51 at aol.com Wed Mar 2 12:48:21 1994 From: area51 at aol.com (area51 at aol.com) Date: Wed, 2 Mar 94 12:48:21 PST Subject: Defenders of Clipper Message-ID: <9403021547.tn186608@aol.com> Hi everyone, I've been watching this list for a few weeks now, and I really don't see any real basis for defending Clipper. It seems the essential arugment of Denning and others is, "Well, we can't tell you what we're afraid of, but trust us, we should be afraid". Can they not tell us because they don't know? Or is it some sort of "secret" they fear? Obviously, widespread secure communications would make life much easier for criminals. Yes, terrorists will be able to make their secret plans using cryptography. But, I would hasten to point out that the Trade Center bombers managed to pull their attack off with NO encrypted conversations that I've heard about. And yes, next time it might be a nuclear bomb. There, is that the unnamed terror? Or is it that the intelligence community is learning all the neat-o toys they bought for SIGINT are rapidly becoming worthless, and in reality there's absolutely nothing they can do about it. They'll have to strengthen their long neglected human intel-gathering side, much as some members of their own community have been arguing for years. The real reason Denning, the NSA, et al are arguing for Clipper is that they realize their professions are becoming obsolete. Welcome to the ranks of the techo-unemployed. Just as nuclear proliferation marches on slowly but surely, so will high-tech crypto. Information wants to be free, as they say, and the implication here is you just can't stop it. Does the government really think they can stop everyone in the world who wishes this nation harm from using crypto? I think not....So they better get on the ball really defending us... Sorry for rambling on.... Rod Ramsey Area51 at aol.com From pfarrell at netcom.com Wed Mar 2 12:51:10 1994 From: pfarrell at netcom.com (Pat Farrell) Date: Wed, 2 Mar 94 12:51:10 PST Subject: PEM, was Re: low-overhead encrypted telnet Message-ID: <57220.pfarrell@netcom.com> In message Wed, 2 Mar 1994 11:55:32 -0600 (CST), Jim McCoy writes: > I sincerely doubt that such a system would be designed or implemented > before the turn of the century. All one needs to do is take a look at the > PEM key certification authority clusterfuck to see just how difficult it > can be to implment something like this. I have to admit that PEM's RSN availability against PGP 2.X's 20+ months of worldwide availability has made me not keep up with PEM and the latest hierarchical, government controlled certification process... But is there an intrinsic problem with a PGP-style web of trust for remote telnet/rlogin applications. I really don't expect to login to arbitrary nodes on the net, but is that required? or simply a robust way (SecureID in software?) Maybe PCMCIA cards with PGP once desktop systems have them. If i'm cluelessly missing something essential, please email me the news. Thanks Pat Pat Farrell Grad Student pfarrell at gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via firger #include From pfarrell at netcom.com Wed Mar 2 12:51:24 1994 From: pfarrell at netcom.com (Pat Farrell) Date: Wed, 2 Mar 94 12:51:24 PST Subject: Laziness? Message-ID: <57234.pfarrell@netcom.com> In message Wed, 2 Mar 1994 10:38:55 -0800 (PST), tcmay at netcom.com (Timothy C. May) writes: > I connect to the Net from my home Mac IIci or PowerBook 170 over a > 14.4 modem line to Netcom, an Internet service provider many of you > are familiar with. Once on Netcome, I have access to a wide range of > standard UNIX tools. However, I do NOT run PGP on these machines! > > Rather, I run MacPGP (or PGP on my DOS machines, in emergencies, or > even "MailSafe" in rare circumstances) on my *home* machine, after first > downloading the mail with "Eudora 2.0," a nice off-line mail reader. > It still takes several steps, as most of you can imagine. I use a similar system to Tim's, except that I use NUpop on a "PC" to download 150+ messages a day from cypherpunks and a bunch of other lists. We have to move the tools to the user's controlled, secure environment. For some that may be Unix, but for close to 98% of the 'net community, a controlled computer is a Mac or PC. At GMU, a few supported grad students have personal Suns or other workstations, maybe 50 students out of 22,000. But nearly all of the students in the techy schools have at least a PC or mac that is under their personal control. Multi-user Unix solutions don't cut it. More importantly, if all 700+ of us on this list used encrpytion for _every message every day_ it would be only an insignificant portion of the net volume. We have to get encryption out to the masses. Pat Pat Farrell Grad Student pfarrell at gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include From pfarrell at netcom.com Wed Mar 2 12:51:34 1994 From: pfarrell at netcom.com (Pat Farrell) Date: Wed, 2 Mar 94 12:51:34 PST Subject: Windows Programming help wanted. Message-ID: <57247.pfarrell@netcom.com> This is a repeat of a request that I made last fall. I got no real response then. Perhaps as the list has grown, someone will respond.... I am looking for help on a Microsoft Windows development project. I have most of a Windows Client SMTP mail client program written, but I can't devine how to make the Windows Communications API work with any marginal success. I need help from someone who has written Windows communications software. The program is functionally equivalent to NUpop or Eudora. It is designed to work over dialup asynchronous lines without TCP/IP. Not that I dislike all the nice functionality tht TCP/IP provides, but because some netowrk providers (such as George Mason University) refuse to support SLIP/PPP for political reasons, and because other providers (Netcom for one) charge orders of magnitude more for SLIP/PPP than for async support. The resulting product will be user firendly, a native Windows program with the usual buttons, icons, context sensitive help, etc. It will have PGP, and maybe RIPEM, support built in. Automagically. I plan to release the code to the net, and will give full credit in the About Box, documentation, etc. for any help. Please respond via email. Cypherpunks write code. Thanks Pat Pat Farrell Grad Student pfarrell at gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include From jpp at markv.com Wed Mar 2 13:08:27 1994 From: jpp at markv.com (jpp at markv.com) Date: Wed, 2 Mar 94 13:08:27 PST Subject: low-overhead encrypted telnet In-Reply-To: Message-ID: <9403021307.aa10907@hermix.markv.com> The IP security program I have been working on (slowly) is a packet redirector and cryptdec. You ask it to encrypt packets comming in on one socket, and pass them out to another socket (also to decrypt those comming in on the second socket and pass them out the first socket). Thus you can run one of these on the X server, and one on the X client, and all the X trafic becomes encrypted over the net. You can telnet to the local redirector, to the forign redirector, and then to the standard telnet port. Or FTP, or whatever. I am still learning about net software, and this vision may not be easly implemented, or sockets may be the wrong level of interface to the net, I dunno. But I do know that my unix (SCO) and my X server (WINDOWS) both support this stratagy. j' From loofbour at cis.ohio-state.edu Wed Mar 2 13:29:40 1994 From: loofbour at cis.ohio-state.edu (Nathan Loofbourrow) Date: Wed, 2 Mar 94 13:29:40 PST Subject: Laziness? In-Reply-To: <199403021838.KAA19172@mail.netcom.com> Message-ID: <199403022129.QAA28485@styracosaur.cis.ohio-state.edu> Timothy C. May writes: > As for Nathan Loofbourrow's charge that this must mean I am lazy > and/or software-challenged, I suggest he try writing more posts for > this list and/or writing code. I'll address the last first: I meant to imply neither. I don't think encrypting traffic from cypherpunks tomorrow would have the desired effect. However, I'll gladly work towards the day when such a change can be transparent to its readers. > I connect to the Net from my home Mac IIci or PowerBook 170 over a > 14.4 modem line to Netcom, an Internet service provider many of you > are familiar with. Once on Netcome, I have access to a wide range of > standard UNIX tools. However, I do NOT run PGP on these machines! > Rather, I run MacPGP (or PGP on my DOS machines, in emergencies, or > even "MailSafe" in rare circumstances) on my *home* machine, after first > downloading the mail with "Eudora 2.0," a nice off-line mail reader. > It still takes several steps, as most of you can imagine. > I don't plan to start using PGP on insecure machines, even with a > shortened "UNIX-grade" key. Especially not for a mailing list, where > encryption is pointless (except to increase encrypted traffic a > bit). I would like to see greater independence from the list. With the help of anonymous mailing and forwarding services, and with the use of a secure machine, I may be able to read and respond to the list without ever betraying my participation. Why announce to the world that I read cypherpunks if I don't have to? > Downloading and then decrypting 100 or more messages a day is not a > viable option, and such a move would cause me to unsubscribe from the > list rather quickly. (To clarify this: I read the list with "elm," > when I am on Netcom doing other things as well, like reading NetNews, > and am thus able to delete about half of all messages before > eventually--every few days, typically--dowloading the whole batch. > Encrypted traffic would make this screening and immediate response > much more difficult.) Your particular connectivity and the ease of reading mail on-line seem to have conspired to make decryption (as well as offline reading and archiving!) quite onerous. If you lack a secure, connected machine at the office, and have no IP (or UUCP!) service at home, I think you're at a strong disadvantage towards reading any encrypted traffic at all. Is there no means for you to automate offline mail reading? The user with a 300 baud modem and a VT100 terminal at home should not expect to be practicing secure encryption. Any better-equipped user has the hardware needed to encrypt and decrypt securely -- they just haven't written the software. > If Nathan is running PGP on a multi-user system, such as campus > machines at Ohio State, he is likely deluding himself about actual > security. Others at the site may already have his private key and > passphrase captured. If he is running PGP on his own private machine, > with good Net connectivity, congratulations. Most of us--I think it's > safe to say--don't have these options. Many are reading from > university accounts, from commercial services like CompuServe, and > even from multiple services (depending on location). Not running PGP > on each and every message doesn't mean we're lazy--it means we've got > better things to do with our time. Point taken; but if you receive unencrypted mail on a multi-user system, you're likely deluding yourself about its security as well. I am motivated to provide the list to anyone that wants it without advertising your subscription (and its traffic) to your service provider. Anonymous posting, meet anonymous subscribers. I can think of several reasons why cypherpunks would not be the only list for which encrypted traffic might be desired. > Sorry to sound harsh, but calling us lazy and software-challenged is > not addressing the real issues. "Indeed." I hadn't intended this to be taken as name calling. Really. nathan From ao27+ at andrew.cmu.edu Wed Mar 2 13:35:16 1994 From: ao27+ at andrew.cmu.edu (Anthony D Ortenzi) Date: Wed, 2 Mar 94 13:35:16 PST Subject: Increasing the encrypted/unencrypted ratio (was Re: Insecurity of public key crypto #1 (reply to Mandl)) In-Reply-To: <9403021622.AA10519@ah.com> Message-ID: Excerpts from internet.cypherpunks: 2-Mar-94 Increasing the encrypted/un.. by Eric Hughes at ah.com > >The incentive for using the encrypted list, then? Simple -- > > 1. Increasing ones personal encrypted-to-unencrypted ratio > >and > > 2. The old chestnut -- delay the unencrypted list 24 hours. > > I'll consider doing this after a whole bunch more stuff is developed, > like checking for digital signatures on posts and delaying those > without them. > > We're now running majordomo for the list, so if these features get > added to the standard majordomo distribution, we could more easily > deploy them. That's a hint, since I have higher priority things to > work on. Well, I know that this might be a bit of a "crazy" idea, but would the best way to distribute an encrypted mailing list be to have a PGP setup where there is a public key to the mailing list, and all recipients are given copies of the secret key? I know that it might be a bit stupid from the security side, but if each person was using PGP, the secret key would be PGP encrypted and sent with that person's public key, ensuring that only subscribers would get it, and then using that secret key to decrypt the messages as they are recieved? Just wonderin'.... Anthony From wcs at anchor.ho.att.com Wed Mar 2 13:41:49 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Wed, 2 Mar 94 13:41:49 PST Subject: Insecurity of public key crypto #1 (reply to Mandl) Message-ID: <9403022140.AA22586@anchor.ho.att.com> A while back, when people were starting to talk about encrypting the list, someone like Eric Hughes pointed out that, if you *want* to run an encrypted, or batch-digested, or whatever, version of cypherpunks, you were free to do so - just set up your system and have it forward cypherpunks to your subscribers. Somebody could still do it now (not me! :-), preferably outside the US where the problems of RSA/PKP patents don't apply. The flip side of the problem is building an automagic decryptor for mail sent *to* cypherpunks, though you could accomplish part of that by using the extropia anonymous remailer which accepts encrypted mail. On the other hand, doing either of these functions on toad.com today risks subjecting John and friends to harassment from RSA (unless toad.com happens to be a Sun 486i or really hot box with SoftPC that can emulate Intel code fast enough to run ViaCrypt.) Bill From ao27+ at andrew.cmu.edu Wed Mar 2 13:42:40 1994 From: ao27+ at andrew.cmu.edu (Anthony D Ortenzi) Date: Wed, 2 Mar 94 13:42:40 PST Subject: Dorothy Denning In-Reply-To: <9403012335.AA01986@toad.com> Message-ID: Excerpts from internet.cypherpunks: 1-Mar-94 Re: Dorothy Denning by Black Unicorn at access.dig > -> > Also, I've gotten a message through to Ross Perot about our fight > against Clipper, and how to reach me, so if I get a response, I'll let > you guys know. > > Anthony > <- > > Oh god, that is all the cause needs. > I can see it now: > > "Transistor brain Ross Perot opposes it! It must be evil!" Chill... I thought that our prime objective was to defeat Clipper... even if you don't like Ross, he does have some pull with the people of this country, and that's what we need... we need the *PEOPLE* to fight Clipper. We need the fight not to just be "a group of civil libertarians", but the general populous. Maybe Ross isn't the answer, but at least I've taken a real step to try to oppose Clipper. What the hell have you done, Black Unicorn? Anthony From talon57 at well.sf.ca.us Wed Mar 2 14:24:48 1994 From: talon57 at well.sf.ca.us (Brian D Williams) Date: Wed, 2 Mar 94 14:24:48 PST Subject: Denning Message-ID: <199403022224.OAA12373@well.sf.ca.us> -----BEGIN PGP SIGNED MESSAGE----- I agree with those who oppose unwarranted attacks on Dr Dennings character. She is by all accounts an intelligent, well-mannered person and deserves to be treated as such. I completely disagree with her about clipper however. I have watched with growing horror as our government over the last 15 years has slowly turned into a near fascist state. Black clad commandos storming a religious group's compound deliberately inciting an armed confrontation, then harrassing for more then a month, then initiating an attack that left most members including the children dead. People who had not been convicted of anything. We are told if we only knew, we would support clipper, I think not. Hide behind your secret information if you chose, we have a general idea of what you fear anyway. We are less worried about nuclear/chemical/biological/informational terrorists then we are of what our government could become with such fascist tools. After all, there are terrorist acts now, when you can listen. Its about privacy...... Its about adults making their own decisions, not some paternalistic government, no matter how well meaning, doing it for us. We will build the tools we need, we will bypass attempts to stop us, we will advance till our communication ressembles noise. Brian Williams Extropian Cypherpatriot "Cryptocosmology: Sufficently advanced comunication is indistinguishable from noise." --Steve Witham -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLXUQbdCcBnAsu2t1AQG9OgQApYhHWjg47wShhzMfQL2LedmAv5j52Ijb H7V+0EO3V4VFsJ2qgtEvOZNHDs2XBCcIthxbpfALOn+V+PY/0eayff5gHBfirKpX AyXRSdGabqA7uVu0PgSSH31fG4OLL4j91crI/9HrVccztfOMGv2dcZGdpyNLBGRi OEW8ZBGieCg= =I02i -----END PGP SIGNATURE----- From lefty at apple.com Wed Mar 2 14:38:13 1994 From: lefty at apple.com (Lefty) Date: Wed, 2 Mar 94 14:38:13 PST Subject: Dorothy Denning Message-ID: <9403022236.AA01224@internal.apple.com> >Chill... I thought that our prime objective was to defeat Clipper... >even if you don't like Ross, he does have some pull with the people of >this country, and that's what we need... we need the *PEOPLE* to fight >Clipper. Mark Twain once said that the only people entitled to use the word "we" when referring to themselves were kings, editors and people with tapeworms. I assume that you're speaking on behalf of your intestinal parasites. Ross Perot is a reactionary head-case. He is the _last_ person I would think to bring into the Clipper debate, right after Bob Packwood and Jesse Helms. >We need the fight not to just be "a group of civil libertarians", but >the general populous. Maybe Ross isn't the answer, but at least I've >taken a real step to try to oppose Clipper. What the hell have you >done, Black Unicorn? Well, for starts, he's posted things that demonstrate possession of a nervous system a few levels above a notochord. What on earth would lead you to believe that you have any claim whatsoever to doing something significant to oppose Clipper in relation to others on this list? You sent a bloody piece of email, and to very much the wrong person: BFD. Don't hold your breath waiting for either a medal or a parade. Your ravings regarding Dorothy Denning pretty much set the tone for all of your contributions since then: juvenile, poorly thought out, and ineptly executed. Goodbye, Mr. Ortenzi. Down the oubliette with you. *plonk* -- Lefty (lefty at apple.com) C:.M:.C:., D:.O:.D:. From kinney at bogart.Colorado.EDU Wed Mar 2 14:46:42 1994 From: kinney at bogart.Colorado.EDU (W. Kinney) Date: Wed, 2 Mar 94 14:46:42 PST Subject: Clipper (Re: Dorothy Denning) Message-ID: <9403022246.AA03841@bogart.Colorado.EDU> -----BEGIN PGP SIGNED MESSAGE----- I write: > I think this is very perceptive. Clipper is perhaps the best > they could _think_ of given an outmoded set of axioms. Bill Stewart writes: >I disagree. My opinion is that the axioms involved are >1) We're in power, and want to stay there. >2) Some kinds of technology greatly enhance our power if we control them. >3) Crypto Technology is a major threat to our power unless we control it. Looks to me like we substantially agree with one another, actually. I might, however, throw out an additional concept, which, to me at least, is a very significant consideration. The basic reasoning of our government with regard to individual rights has always been that rights are agreed on by society as a whole, and one of the social roles of government is to act both as protector and _arbiter_ of those rights. I think this shows through every time somebody talks about "trade-offs" -- this is government acting as arbiter, trying to enforce an assumed role as the body charged with deciding what rights _mean_ in a practical social context. Under many circumstances, this is an appropriate role: the government acts to protect free speech more often than it acts to suppress it, for instance. But the spooky illogic of Clipper comes, I think, from this model of rights as things the government can, but doesn't take away from its citizens. Cryptography breaks this paradigm, because privacy becomes something posessed by the citizen independent of the government's good will. Clipper is an effort to restore the traditional paradigm, to return the government quite literally to its traditional role of "keeper of the keys". It is a failure to recognize that the rules of the world are changing, and a failure to adapt. This is more frightening in a lot of ways than any "Nixon-esque" intrigue could ever be. -- Will -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLXSzcffv4TpIg2PxAQGhMwP9EXJdIgj3vJVLYdavBon4GAPQF3lWDh/b E8nRToSPKR5iac7X3tmoEyl2AHiArneKgeqcdFh+1AZapfGyRl0iWQDZgQxlDMrt Vix9GxQ/wDVJTjopWyTIMFtgPz86B47ObRXi2doCG7od1+Rlw5rvwTARW0H4jUep ZvVsgmaOx+c= =R7+u -----END PGP SIGNATURE----- From lefty at apple.com Wed Mar 2 14:49:14 1994 From: lefty at apple.com (Lefty) Date: Wed, 2 Mar 94 14:49:14 PST Subject: Insecurity of public key crypto #1 (reply to Mandl) Message-ID: <9403022248.AA01608@internal.apple.com> Eric Johnson writes: > > I was suggesting just the opposite. It obviously isn't a security > issue. I believe it is more of a first principles issue; "Thou > shall encrypt thy communications, lest thou draw attention to thy > self, and the right be removed by thine opponents." Am I missing something, or is this equivalent to saying that the way to oppose gun control is by brandishing a gun as much as possible? -- Lefty (lefty at apple.com) C:.M:.C:., D:.O:.D:. From SJB8195 at ZEUS.TAMU.EDU Wed Mar 2 16:10:54 1994 From: SJB8195 at ZEUS.TAMU.EDU (Scott Beaudreau) Date: Wed, 2 Mar 94 16:10:54 PST Subject: Peace initiative Message-ID: <940302181035.2180273e@ZEUS.TAMU.EDU> Hello cypherpunks, Please consider my suggestions. Send flames via anonymous remail to /dev/null. I would like to see the following discussions end: 1. Attacks on Dr. Denning. (She is only an opponent, not Damien Thorn.) 2. Defense of Dr. Denning. (More important topics exist.) 3. Attacks of Ross Perot or his supporters. 4. Attacks on each other. I am more interested in these topics: 1. Corporations, money, and IRS. Sandy and others. 2. Rating systems. 3. Phone and fax security. 4. Clipper chip news. 5. Security software news. PGP Tools, etc. These ideas are simply my opinion. There is too much talent on this group to throw at flames. Casually yours, Scott Beaudreau From mike at EGFABT.ORG Wed Mar 2 16:14:12 1994 From: mike at EGFABT.ORG (Mike Sherwood) Date: Wed, 2 Mar 94 16:14:12 PST Subject: clipper==bad, but how do you explain this to average joe 6-pack? Message-ID: How do we go about explaining why clipper is bad to average joe 6-pack? I've noticed that most normal people seem to think the reasons against clipper are just paranoid concerns of a bunch of conspiracy theorists. Average joe 6-pack doesn't seem concerned that the government will have the keys to decrypt anything he does using a cellular phone with a clipper chip. Or in the key database were compromised, such things could be forged, but that's what average joe 6-pack sees as being the imaginations of a bunch of conspiracy theorists in action. How can this be explained to people who have a hard time differentiating a 5.25" floppy from a small paper plate? (Well, they couldn't do it 2 out of 3 times) If we can't effectively convince the average citizens that clipper is bad, they'll accept it because the government told them it is good and alternative crypto is bad because the only reason to hide something from our benevolent, democratic government(which is always acting in our best interests) is if we're hideous criminals. Any comments would be appreciated. -Mike -- Mike Sherwood internet: mike at EGFABT.ORG uucp: ...!sgiblab!egfabt!mike From ejohnson at pmip.dist.maricopa.edu Wed Mar 2 16:20:35 1994 From: ejohnson at pmip.dist.maricopa.edu (Eric Johnson) Date: Wed, 2 Mar 94 16:20:35 PST Subject: Insecurity of public key crypto #1 (reply to Mandl) Message-ID: <199403030019.RAA23965@pmip.dist.maricopa.edu> : Eric Johnson writes: : > : > I was suggesting just the opposite. It obviously isn't a security : > issue. I believe it is more of a first principles issue; "Thou : > shall encrypt thy communications, lest thou draw attention to thy : > self, and the right be removed by thine opponents." : : Am I missing something, or is this equivalent to saying that the way to : oppose gun control is by brandishing a gun as much as possible? : : -- : Lefty (lefty at apple.com) : C:.M:.C:., D:.O:.D:. If you replace the word "brandishing" with "carrying", I find nothing disagreeable about your sentence. RKBA and all that. ^ --Eric From wcs at anchor.ho.att.com Wed Mar 2 16:25:51 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Wed, 2 Mar 94 16:25:51 PST Subject: Increasing the encrypted/unencrypted ratio (was Re: Insecurity of public key crypto #1 (reply to Mandl)) Message-ID: <9403030024.AA01382@anchor.ho.att.com> > [List could use a PGP key where everybody shares the private key?] No point. First of all, anything that everybody on the list has isn't going to be a secret anyway; it'd get out, and who knows how many of the subscribers are really spooks anyhow. Second, the reason for using public-key systems is so you don't have to distribute secret information - if you're going to do that anyway you might as well distribute the secret key for a symmetric-key algorithm, such as "pgp -c". Third, the newer PGP versions can handle multiple recipients (unless I'm mixing it up with the plans for the next version?), so you can have the message encrypted once with one secret key, and N versions of the secret key (+a random string) encrypted with user i's public key. From pmetzger at lehman.com Wed Mar 2 16:29:03 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 2 Mar 94 16:29:03 PST Subject: clipper==bad, but how do you explain this to average joe 6-pack? In-Reply-To: Message-ID: <9403030028.AA22931@andria.lehman.com> Mike Sherwood says: > How do we go about explaining why clipper is bad to average joe 6-pack? You don't. They don't matter much anyway. Just concentrate on the people who matter. Contrary to popular belief, the people don't run this country. If we can convince Congress that this is a bad idea, the opinions of their constituents won't matter. Convincing the people who think is likely more effective than convincing the folks who hang out at Bowl-O-Rama anyway -- the congressmen don't care about the Bowl-O-Rama folks because they never vote anyway. Perry From hughes at ah.com Wed Mar 2 16:36:49 1994 From: hughes at ah.com (Eric Hughes) Date: Wed, 2 Mar 94 16:36:49 PST Subject: clipper==bad, but how do you explain this to average joe 6-pack? In-Reply-To: Message-ID: <9403030029.AA11533@ah.com> >How do we go about explaining why clipper is bad to average joe 6-pack? "When the national health care system decides that your beer is bad for you, they won't make beer illegal, they'll just raise your insurance rates. And because you can't protect your privacy they'll know exactly how much beer you buy." Substitute your favorite commodity above, such as motorcycle helmets, condoms, greasy food, cigarettes, or pronography. Eric From hughes at ah.com Wed Mar 2 16:39:56 1994 From: hughes at ah.com (Eric Hughes) Date: Wed, 2 Mar 94 16:39:56 PST Subject: Laziness? In-Reply-To: <199403022129.QAA28485@styracosaur.cis.ohio-state.edu> Message-ID: <9403030032.AA11554@ah.com> >Why announce to the world that I read >cypherpunks if I don't have to? This is one reason that we have not disable the 'who' command on the toad.com majordomo server. If you want the public not to know you're on the cypherpunks list, get and use an alias. >Point taken; but if you receive unencrypted mail on a multi-user >system, you're likely deluding yourself about its security as well. There are two issues here. I don't mind reading most mail on a shared machine, but I'm sure as hell not going to let my private key inside its RAM. Eric From tcmay at netcom.com Wed Mar 2 16:51:17 1994 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 2 Mar 94 16:51:17 PST Subject: clipper==bad, but how do you explain this to average joe 6-pack? In-Reply-To: Message-ID: <199403030051.QAA05871@mail.netcom.com> Mike Sherwood writes: > How do we go about explaining why clipper is bad to average joe 6-pack? Well, there are many approaches to take. Most of us (sorry, Lefty, for speaking as a tapeworm :-} ) are totally opposed to Clipper and key escrow in all its forms, as I'm sure most readers of this list know. (A few defenders of Clipper have appeared here recently....draw your own conclusions about the overall sentiment of the list.) > I've noticed that most normal people seem to think the reasons against > clipper are just paranoid concerns of a bunch of conspiracy theorists. I've found just the opposite. Most of my non-crypto friends and family understand the issues once they are explained. We've made these points so many times before on this list, so I'll be brief. Mike and others will have to use their imagination to flesh these points out. (And the several excellent articles on crypto in "Wired," "Whole Earth Review," "Communications of the ACM," "The Village Voice," etc., are a good place to go for more details. Some of these article are available on-line.) Limiting crypto is analogous to: - requiring all letters to be written on postcards instead of sealed in envelopes (Phil Zimmermann came up with this one) - insisting that all locks on doors have their keys "escrowed" with the local cops, just in case the cops want to make a midnight "inspection" of your house. - outlawing window shades and other obstructions to those who are videotaping you through your windows. - requiring that all photo processing labs make a duplicate set of all photos and "escrow" them with the local Legion of Decency or Child Protective Services Agency, just in case child nudity or other evidence of criminality is suspected - "Diary escrow," in case one's diary is suspected of containing subversive writings or admissions of criminal behavior - bugging of church confessionals...for obvious reasons. I mean, if people are "confessing" their sins, shouldn't the police know? Dorothy Denning certainly thinks so. ....Use your imagination to construct similar analogies to educate your friends and opponents. The issues don't require any expertise in number theory or cryptology to comprehend. .... > clipper chip. Or in the key database were compromised, such things could > be forged, but that's what average joe 6-pack sees as being the > imaginations of a bunch of conspiracy theorists in action. How can this > be explained to people who have a hard time differentiating a 5.25" > floppy from a small paper plate? (Well, they couldn't do it 2 out of 3 > times) Don't phrase things in terms of computers, modems, floppy disks, etc. Use familiar examples, such as locks on doors and personal diaries. > If we can't effectively convince the average citizens that clipper is > bad, they'll accept it because the government told them it is good and > alternative crypto is bad because the only reason to hide something from > our benevolent, democratic government(which is always acting in our best > interests) is if we're hideous criminals. > Personally, I'm not fighting the battle of trying to convince my neighbors and folks I meet at the gym that key escrow is bad. We reach a lot more folks by talking to and educating journalists. I of course spoke to several of them before the Clipper thing broke. (But two of them got in contact with _me_ precisely because I'd written about the evils of key escrow half a year before Clipper was even announced....this meant their articles hit at the same time Clipper was hitting.) I recently spent 2 hours on the phone answering the many questions of a Southern California reporter who is writing a long article on crypto and Clipper that he hopes to resell to many other papers. I dwellt heavily on analogies like the ones I described above....he seemed to think these analogies will be easily understandable to his readers. The more contact I have with journalists (Levy, Kelly, Dibbell, Markoff, others), the more impressed I am. True, these are mostly science or computer-literate folks, but their overall grasp of the issues is impressive. --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^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway." From mech at eff.org Wed Mar 2 16:54:30 1994 From: mech at eff.org (Stanton McCandlish) Date: Wed, 2 Mar 94 16:54:30 PST Subject: digi-script? Message-ID: <199403030054.TAA29367@eff.org> Sorry I didn't find this sooner, but the info is still of interest even if the conf is over. Forwarded message: From arthurc at crl.com Wed Mar 2 17:09:48 1994 From: arthurc at crl.com (Arthur Chandler) Date: Wed, 2 Mar 94 17:09:48 PST Subject: clipper==bad, but how do you explain this to average joe 6-pack? In-Reply-To: <9403030029.AA11533@ah.com> Message-ID: If ol' Joe happens to read "Doonesbury," ask him what Duke would do if he held the Clipper key. From nates at netcom.com Wed Mar 2 17:45:50 1994 From: nates at netcom.com (Nate Sammons) Date: Wed, 2 Mar 94 17:45:50 PST Subject: clipper==bad, but how do you explain this to average joe 6-pack? In-Reply-To: Message-ID: <199403030146.RAA14530@netcom10.netcom.com> I have to agree with Time, etc that many of my friends say the equivilant of "what a stupid idea... it'll never pass" when I explain what the gov is trying to do to us. Some of my friends, however, think I am totally paranoid (not completely false) and that I should just chill out a bit. The problem is that many people say that clipper is so stupid it'll never pass, so they assume that their congress-critter will do the "right" thing and dump clipper. This is where most people fail. Our congress-critters are most likely *not* going to do the right thing, since their ears are being pulled by the NSA and the FBI, etc... who think that unless all of us are watched, we'll hurt ourselves or hurt eachother like a bunch of infants. -nate -- +--------- | Nate Sammons PGP Key and fingerprint via finger. | Clipper == Big Brother Inside. Question Authority. Encrypt everything. +--------- From mike at EGFABT.ORG Wed Mar 2 17:55:00 1994 From: mike at EGFABT.ORG (Mike Sherwood) Date: Wed, 2 Mar 94 17:55:00 PST Subject: clipper==bad, but how do you explain this to average joe 6-pack? In-Reply-To: <199403030051.QAA05871@mail.netcom.com> Message-ID: tcmay at netcom.com (Timothy C. May) writes: > Well, there are many approaches to take. Most of us (sorry, Lefty, for > speaking as a tapeworm :-} ) are totally opposed to Clipper and key > escrow in all its forms, as I'm sure most readers of this list know. > (A few defenders of Clipper have appeared here recently....draw your > own conclusions about the overall sentiment of the list.) I also oppose the whole clipper/key escrow idea just because it's the governments' idea. The reason that makes it bad is because they have a lot more power to "promote" their "good ideas" whereas those of us out here have the option to choose if we're happy with des or if we'd prefer pgp. However, this is more of a religious issue than anything else, and the average people don't understand serious religious issues - they're too caught up on the silly ones that no one cares about like creation vs evolution. =) > - insisting that all locks on doors have their keys "escrowed" with > the local cops, just in case the cops want to make a midnight > "inspection" of your house. well, the cops can do that anyway with their magic door-breaking key. And as we've seen in the case of steve jackson games, they'd much rather break things apart than let people give them keys to open them. =) > - outlawing window shades and other obstructions to those who are > videotaping you through your windows. this applies to crypto in general. clipper gives this protection from everyone *BUT* law enforcement. how do we justify "hiding" everything from the police without giving the inference that what we want to keep private is illegal or highly questionable? I've found a lot of people more willing to assume the government's intentions are good than to accept that individuals are. > Personally, I'm not fighting the battle of trying to convince my > neighbors and folks I meet at the gym that key escrow is bad. any thoughts on an approach for bringing this to the attention of those people at the gym that don't care about crypto? or perhaps a speech to a captive audience that has to listen because it's a public speaking class that is part of silly required GE? =) -- Mike Sherwood internet: mike at EGFABT.ORG uucp: ...!sgiblab!egfabt!mike From klbarrus at owlnet.rice.edu Wed Mar 2 18:19:24 1994 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Wed, 2 Mar 94 18:19:24 PST Subject: MAIL: remailer list Message-ID: <9403030219.AA27285@flammulated.owlnet.rice.edu> Cypherpunks, I was just informed by Chris Walker that the remailer elee9sf at menudo.uh.edu is now down. If you send mail, it bounces with "this account is expired". Sheesh, in the space of two weeks I've lost all four remailers I had running at UH. Time to set up another ;) -----BEGIN PGP SIGNED MESSAGE----- Cypherpunk anonymous remailers, 3/3/94 Q1: What are the anonymous remailers? A1: 1: remailer at chaos.bsu.edu 2: nowhere at bsu-cs.bsu.edu 3: hh at soda.berkeley.edu 4: hal at alumni.caltech.edu 5: ebrandt at jarthur.claremont.edu 6: catalyst at netcom.com 7: remailer at rebma.mn.org 8: hfinney at shell.portal.com 9: remailer at utter.dis.org 10: remailer at entropy.linet.org 11: remail at extropia.wimsey.com NOTES: 1-3 no encryption of remailing requests 4-11 support encrypted remailing requests 11 special - header and message must be encrypted together 7,9,10,11 introduce larger than average delay (not direct connect) 7,9,11 running on privately owned machines 3 features USENET posting ====================================================================== Q2: What help is available? A2: Check out the pub/cypherpunks/remailer directory at soda.berkeley.edu (128.32.149.19). chain.zip - program that helps with using remailers dosbat.zip - MSDOS batch files that help with using remailers hal's.instructions.gz - in depth instruction on how to use hal's.remailer.gz - remailer code pubkeys.tar.gz - public keys of remailers which support encryption pubkeys.zip - MSDOS zip file of public keys scripts.tar.gz - scripts that help with using remailers Or try the cypherpunks gopher site (chaos.bsu.edu) and look in "Anonymous Mail" for instructions. Mail to me (klbarrus at owlnet.rice.edu) for further help and/or questions. ====================================================================== Q3. Email-to-Usenet gateways? A3. 1: group-name at cs.utexas.edu 2: group.name.usenet at decwrl.dec.com 3: group.name at news.demon.co.uk 4: group.name at news.cs.indiana.edu 5: group-name at pws.bull.com 6: group-name at ucbvax.berkeley.edu NOTES: * This does not include ones that work for single groups, like twwells.com. * Remember to include a Subject: with your post, may cause failures if missing #6 blocks from non-berkeley sites (so use the berkeley remailers :-) ====================================================================== This is the remailer.data file I use with nestping, a script for pinging anonymous remailers: 01:n:remailer at chaos.bsu.edu 02:n:nowhere at bsu-cs.bsu.edu 03:n:hh at soda.berkeley.edu 04:y:hal at alumni.caltech.edu 05:y:ebrandt at jarthur.claremont.edu 06:y:catalyst at netcom.com 07:y:remailer at rebma.mn.org 08:y:hfinney at shell.portal.com 09:y:remailer at utter.dis.org 10:y:remailer at entropy.linet.org 11:s:remail at extropia.wimsey.com -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLXVIg4OA7OpLWtYzAQFp1gP9EBxByjifFHwNRzXo9/aBAOUlZeeLKlTe r8bDbVCsX3KH3DKPETGZrT5+KbTZOeNAJWbJXb+pv6LCPN0s9cMnQt9hf5znPaS0 ZbYz/JNaMGenqt+oZAy/xN1GWc+0UcuKEyr2dZrqrZB1be6Ilv2G77tIC1H1HZ1b 2GcsRMUair8= =/PYK -----END PGP SIGNATURE----- From rcain at netcom.com Wed Mar 2 18:48:31 1994 From: rcain at netcom.com (Robert Cain) Date: Wed, 2 Mar 94 18:48:31 PST Subject: Clipper (Re: Dorothy Denning) In-Reply-To: <9403020738.AA12338@anchor.ho.att.com> Message-ID: <199403030249.SAA28948@netcom9.netcom.com> bill.stewart at pleasantonca.ncr.com +1-510-484-6204 sez: > > I disagree. My opinion is that the axioms involved are Me too. I would like to substitute a bit. > 1) We're in power, and want to stay there. No argument there. :-) > 2) Some kinds of technology greatly enhance our power if we control them. 2) Some kinds of technology greatly enhance the power of those that are ruthless and dangerous. > 3) Crypto Technology is a major threat to our power unless we control it. 2) Crypto technology could well be a major threat to the world's safety unless we control it. > 4) Maybe we can stop it if we act quickly, at a cost to society > that's low enough that we won't cause a major revolt 4) Maybe we can stop it if we act quickly while still providing society the benefits it wishes. > 5) If we pull that off, the success will help consolidate our power. 5) If we pull that off, the success will help protect society from being disrupted, damaged or held hostage by those wishing power. > 6) The public believes almost anything we tell them, at least for a while, > as long as we sound sincere. 6) The public feels we are interested in their private lives and we must change that perception toward our actual concerns. > > > Clipper is just the kind of woefully clueless thing people in > > that position would come up with. > > It's not at all clueless. It's offensive, unAmerican, and probably > won't win, but there's a subtle malignity to it that's almost > Nixonesque in its cleverness, and it's tacky enough they may be > able to pull it off. It's not at all clueless, offensive or unAmerican and it still probably won't win. It represents nothing more or less than a studied and earnest offer of a method that can compromise so as to give society the potential benefit of the technology while also giving us the protection that it is and has been their job to give. All that they can do in fact, and they know this, is to attempt to persuade people to voluntarily leave them with that ability. The most valuable thing that Clipper is doing I think is showing the unscrupulous and scrupulous within government (and I still believe the unscrupulous to be a small subset even though I think there are entire agencies without scruples) what messing with the people in the fashion of unconvicted forfiture, can cause. I mean c'mon, who is going to believe that a group who can and will take all of a person's belongings and sell them before convicting the person and not return them on aquittal will stop short of arbitrary, fishing expedition privacy invasion? I hope that those in the NSA, the intelligence community and the military, who see the now potentially disasterous consequences of the actions of a few of their cousins in government like the DEA, will slap them around a bit. They could ya' know. If it were not for clowns like those who have seeemed to a very large segment of society to have run totally amuck I think there would not be the sturm and drang that this issue now stirs up in groups like this. You men and women in and close to government who are sincerely concerned about crypto for good reason don't have to look very far to see who created this problem for you. What comes 'round goes 'round is the lesson here. I just hope the lesson isn't as harmful to student and teacher alike as it has the potential to be. Peace, Bob -- Bob Cain rcain at netcom.com 408-354-8021 "I used to be different. But now I'm the same." --------------PGP 1.0 or 2.0 public key available on request.------------------ From klbarrus at owlnet.rice.edu Wed Mar 2 20:05:11 1994 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Wed, 2 Mar 94 20:05:11 PST Subject: LIST: encrypted Message-ID: <9403030405.AA05697@flammulated.owlnet.rice.edu> About receiving this mailing list encrypted.... I beleive Hal Finney is (was?) offering such a service. Basically you send in your public key, and Hal pipes all list mail through pgp and remails it you, from one of his anonymous remailers. I don't think many people opt for this :) but the option is there (unless Hal isn't offering it anymore). He'll probably answer when he reads the list mail! -- Karl L. Barrus: klbarrus at owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories From dan at kypris.com Wed Mar 2 20:36:10 1994 From: dan at kypris.com (Daniel A. Nichols) Date: Wed, 2 Mar 94 20:36:10 PST Subject: help getting files off csn.org??? Message-ID: <9403030156.AA10552@kypris.com> Hey all! Can someone help me out as to how to get the pgp-related stuff off csn.org? Unfortunately I don't have real ftp, only ftp through the ftp-mail-server. I have grabbed the README.MPJ file and immediately sent an ftp request to get files from the ever-changing I_will_not_export/??? directory, but get back a "no such directory". How often does the directory name change? Am I just not going to be able to get them through ftp-mail requests? Thanks, Dan --- Daniel A. Nichols Voice: (214) 307-0474 Kypris Software Systems Fax: (214) 306-3409 2601 Frankford Rd. #2703 E-Mail: dan_nichols at kypris.com Dallas TX 75287-4517 NeXTMail Welcome! From CCGARY at MIZZOU1.missouri.edu Wed Mar 2 20:57:24 1994 From: CCGARY at MIZZOU1.missouri.edu (Gary Jeffers) Date: Wed, 2 Mar 94 20:57:24 PST Subject: Standard for Stenography? Message-ID: <9403030457.AA05934@toad.com> Firstly, congratulations for Sergey Goldgaber's stubborn pushing of this topic, for Bill Stewart's observation: "simple stego-programs, stealthy encryption programs", & for Norman Hardy's notice of the possibility of non-randomness in the low order bits of pixels. Here are my proposed standards & suggestions for stenography. 1. The stenography module is just a simple program for inserting data into a picture. The data is not plaintext! Ideally, stealth pgp is the encryption method. There should be no clever variable positional stenography. No security through obscurity. No "TOWERS of BABBLE". It must be standardized for easy conversation. I agree with Bill Stewart on this: simple stego programs, stealthy encryption programs. 2. The 1st position of the stenography is defined as the 1st pixel transmitted or received. The 1st several pixels should make up the header. The header should be of a fixed size with fixed sized & positioned fields. The header follows: 1____6 7_________17 18>>>>>>> checksum; "STENOGRAPHY"; the encrypted text The numbers refer to pixels. One bit of encrypted data per pixel. The 1st field is a checksum particular to that RSA key. The 2nd field consists of the word "STENOGRAPHY" in caps. The remainder is devoted to the encrypted msg. itself. The checksum is a standardized checksum method that has the same checksum as the RSA key. You need this in case you have given out several public keys. The checksum may also be an integral multiple of the RSA key. The reason for the checksum is in case the recipient has multiple keys, this will help him select the correct one without using huge numbers of cycles. Only 6 bits are used since that would be all that would be necessary & to eliminate the possibility of a huge number that would be large enough to constitute a legal proof. Also, by using a small number, investigators are not given much of a clue. By allowing integral multiples, you allow a fairly large number of keys but also stop small numbers from popping up a lot - no statistical suspensions! The reason for the "STENOGRAPHY" field is to assist your computer in determining if this is a stenography file & that the correct key was chosen without attempting to decrypt the whole file. I know that this presents the possibility of a small "known plaintext attack", but a good encryption system should stand up to such an attack. RSA can ... can't it? 3. No "lossy" picture methods! Two methods immediately suggest them -selves: JPEG & GIF. JPEG is ordinarily a lossy method but I am told that it has a no loss option. GIF is not a lossy method. I hear that JPEG has the ability to carry more bits per pixel than GIF so I would suppose JPEG. Also, while earlier I suggested 1 bit of encrypt per pixel it may be cool to use more. 4. Norman Hardy has suggested something that I have wondered about: are low order bits of pixels really randomly distributed? You graphic/ statistic ace's out there need to check this out & inform us. Possibly, some methods do & some don't? Inquiring cypherpunks need to know! I don't know too much about graphics, so I could use a lot of help. 5. What are the best pictures to use? I would suggest soft focus pin- up girls, mountain ranges, clouds, fields of grain, dense vegetation. Would soft focus help in all these types? note: I think kiddie-porn would be a bad idea. The above suggestions support the stealth method- strong encryption- simple stenography- public key- standardized model. If I have missed anything or you have a better idea, please let us know. Yours Truly, Gary Jeffers From unicorn at access.digex.net Wed Mar 2 21:25:43 1994 From: unicorn at access.digex.net (Black Unicorn) Date: Wed, 2 Mar 94 21:25:43 PST Subject: Dorothy Denning Message-ID: <199403030525.AA29615@access1.digex.net> -> Chill... I thought that our prime objective was to defeat Clipper... even if you don't like Ross, he does have some pull with the people of this country, and that's what we need... we need the *PEOPLE* to fight Clipper. We need the fight not to just be "a group of civil libertarians", but the general populous. Maybe Ross isn't the answer, but at least I've taken a real step to try to oppose Clipper. What the hell have you done, Black Unicorn? Anthony <- In the circles I travel in Mr. Perot is considered a dangerous paranoid. I agree he has the ear of some *PEOPLE* (as you so nicely put it) but as much as you fear the branding of the anti-clipper movement as JUST "a group of civil libertarians," it is possible that there are other brands just as destructive to credibility. Mr. Perot is in my opinion represenative of one such brand. The Good Perot Keeping Seal might sink the "general populous" boat we would so much like to travel on. As far as your efforts in this matter v. mine, Anyone can post some messages to the list Mr. Ortenzi. -uni- (Dark) From rarachel at prism.poly.edu Wed Mar 2 21:39:03 1994 From: rarachel at prism.poly.edu (Arsen Ray Arachelian) Date: Wed, 2 Mar 94 21:39:03 PST Subject: clipper==bad, but how do you explain this to average joe 6-pack? In-Reply-To: <9403030029.AA11533@ah.com> Message-ID: <9403030526.AA17582@prism.poly.edu> > "When the national health care system decides that your beer > is bad for you, they won't make beer illegal, they'll just raise your > insurance rates. And because you can't protect your privacy they'll > know exactly how much beer you buy." > > Substitute your favorite commodity above, such as motorcycle helmets, > condoms, greasy food, cigarettes, or pronography. How soon would it be before they will decide that anyone who is afraid of what the NSA and its fans must be paranoid, so paranoid that they must be insane and thus, must be put in a mental institution because they are a danger to themselves and others. Never mind that there aren't any mental institutions left, they can reopen them. Oh, and anyone who disagrees with King Kongress and Billary must also be insane, why would anyone disagree with the direct descendents of the Gods! :-) From jef at ee.lbl.gov Wed Mar 2 22:32:48 1994 From: jef at ee.lbl.gov (Jef Poskanzer) Date: Wed, 2 Mar 94 22:32:48 PST Subject: Standard for Stenography? Message-ID: <9403030632.AA13653@hot.ee.lbl.gov> > Firstly, congratulations for Sergey Goldgaber's stubborn pushing of >this topic, for Bill Stewart's observation: "simple stego-programs, >stealthy encryption programs" I disagree with pretty much everything in your message, and since I'm the one who opened the topic and who is writing the code, my opinion would seem to count for quite a bit more than yours. I'm not going to repeat the reasons why the kind of standard you propose is a bad idea, you can fetch the messages as easily as I can. Cc:ed to the list only so that no one thinks Gary's proposal was accepted. The permutation idea remains the best. By the way, this discussion is an example of something I have labelled the "silence is invisible" phenomenon. It goes like this: there's a discussion; some of the participants work out an answer, and as far as they're concerned the discussion is over. However, other participants don't understand the answer, and keep on talking. In a physical meeting, the talkers would notice the annoyed looks on the faces of everyone else; or if the meeting had a good facilitator, he or she would catch on to the misunderstanding and correct it; but in cyberspace, those feedback mechanisms don't happen. --- Jef From rarachel at prism.poly.edu Wed Mar 2 22:53:03 1994 From: rarachel at prism.poly.edu (Arsen Ray Arachelian) Date: Wed, 2 Mar 94 22:53:03 PST Subject: PC Expo, Mac World, Comdex, etc... Message-ID: <9403030641.AA18606@prism.poly.edu> If a few of us who have a bit of money to spend on disks and duplication could come together (or work apart) we could just go out infront of PC Expo, or any other expo and simply hand out free disks with stuff like PGP, SecureDrive and whatever else, maybe even include a flyer with info about getting more info on issues like clipper and such... Perhaps some sort of self running hypertext demo to show analogies, say via a caricature of Dorothy Denning or Billary Clingon trying to install bugs in the phones of the viewers, cameras in cable TV boxes, microphones in bathrooms etc, all bearing the word "Clipper" on them... :-) (The distribution method isn't my idea, a dude who runs or works for an internet mail/news only carrier approached me and gave me a flyer...) "Get your free PGP disks here, learn about how Uncle Sam is spying on your privacy, etc..." :-) Now for some rude awakenings to follow... are there any laws against handing out >FREE< disks to people exiting or entering a convention center? (hopefully not too many.) Putting up an informercial will reach a lot of people who couldn't care less. Putting this stuff in the hands of those who have the interests of big business will reach a wider bit of the people we need to reach. From rarachel at prism.poly.edu Wed Mar 2 23:15:33 1994 From: rarachel at prism.poly.edu (Arsen Ray Arachelian) Date: Wed, 2 Mar 94 23:15:33 PST Subject: Missing(??) April 94 DDJ!!???!!??? In-Reply-To: Message-ID: <9403030703.AA18870@prism.poly.edu> Speaking of DDJ's nice crypto articles for April 94, I just had a truly weird thing arrive in the mail today. It was a plastic mailer bag from DDJ which contained Vol 1., Issue 1. of DDJ's Developer Update. The plastic envelope was larger than needed for such a mailing. All the bag contains is the 8 page Dev. Update issue and a card with my name and the return address for the snail mail folks to be able to process the package. There was NOT any April 94 issue of DDJ. Have I been ripped, or did DDJ goof, or was this mailing supposed to contain only the 8 page thinggie??? If anyone receives their DDJ April 94 issue >ALONG< with the developer update, please let me know so I can bitch. :-) If anyone received the same package without the DDJ issue, I ask that you also let me know so that I silence myself patiently for the DDJ April 94 issue. :-) However, one nice thing is that one of the aside boxes at the left side of the 8 page thinggie has "Crypto Chip Debuts." This is on the cover under News Briefs. Okay, it's small, I'll type it: "National Semiconductor has released the iPower encryption chip which is designed for use in PCMCIA cards and provides a range of security features. The chip can encrypt via multiple encryption algorithms (none listed) and will self destruct upon any tampering attempt, using a self contained chemical. Cards that use the iPower chip can also provide additional functions such as tracking users access times. The iPower division is based is (sic) Santa Clara, CA 408-721-8797." #include From rarachel at prism.poly.edu Wed Mar 2 23:31:57 1994 From: rarachel at prism.poly.edu (Arsen Ray Arachelian) Date: Wed, 2 Mar 94 23:31:57 PST Subject: on international transmissions In-Reply-To: <9403012200.AA08101@ah.com> Message-ID: <9403030719.AA18965@prism.poly.edu> <> Another scenario. Suppose Person A has a unix account they don't use very often. Say once every few months. Suppose person X is a hacker and breaks into Person A's account. Person X then sets up a small program that acts as a remailer, *BUT* in a very specific way. This remailer looks for a particular message, specifically the requested cryptographic software sent from person B who is a crypto author. Person X is outside of the USA and has grabbed many many accounts and has installed similar programs on each machine, which strip out all headers of forwarded mail, and encrypt/stego all traffic through them. Person X wants to get his hands on a new, but very strong cypher or interesting program that he doesn't have. So through his captured accounts whose profieles match person A's, he manages to set up the transaction and receive the software. The remailer programs have a very specific code in them that when triggered will remove all trace of their existence within the captured accounts. (ie: the program rm's itself and overwrites the original .login file to the one person X has hacked.) In other words, he gets his hands on the software, sends the kill code to one mailer which sends it on to the next and kills itself, all mailers die. The resulting trail is a long, but quickly disappearing one. Nevermind that the odds are that Person X willbe caught before he manages to set up his "network" and all that. Cliff Stoll is/was an exceptional sniffer with a lot of time on his hands talking to deaf ears until he talked through a megaphone and was taken seriously. The law in theory has been broken. In practice, Person C, F, and N, are pretty much out of luck, unless they get some other breaks leading to person X. :-) Now suppose that Person A = Person X. Would you say that person A has an aliby that his account had been hacked in and he wasn't aware of it until a few months later his password mysteriously appeared in 2600 or Phrack or elsewhere and a few people told him of the "breech" of security? :-) Okay, that's it, time for me to get some sleep. Too many theoretical, useless schemes. A true sign of sleep deprivation. From tcmay at netcom.com Thu Mar 3 00:32:23 1994 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 3 Mar 94 00:32:23 PST Subject: Standard for Stenography? In-Reply-To: <9403030457.AA05934@toad.com> Message-ID: <199403030833.AAA29880@mail.netcom.com> > Here are my proposed standards & suggestions for stenography. > > 1. The stenography module is just a simple program for inserting data > stenography. No security through obscurity. No "TOWERS of BABBLE". > 2. The 1st position of the stenography is defined as the 1st pixel > checksum; "STENOGRAPHY"; the encrypted text > consists of the word "STENOGRAPHY" in caps. The remainder is devoted > The reason for the "STENOGRAPHY" field is to assist your computer in > determining if this is a stenography file & that the correct key was Wasn't stenography standardized in the last century? Or am I thinking of shorthand? Though I avoid spelling flames, the repeated confusion of steganography ("covered/hidden writing") with what court reporters and secretaries do is really getting to me. And the statistics of the low-order bits in various sorts of images were discussed about six months ago here, by various folks. --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^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway." From tcmay at netcom.com Thu Mar 3 00:56:08 1994 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 3 Mar 94 00:56:08 PST Subject: What's Wrong with the List In-Reply-To: <9403030632.AA13653@hot.ee.lbl.gov> Message-ID: <199403030856.AAA02891@mail.netcom.com> I agree completely with Jef Poskanzer's observation: (Ironically, experienced list members generally avoid "I agree" comments, which means disagreements over the basics generally get more "air time" than agreements. This is a related point to the one Jef is making, and is the reason I'm speaking up here to agree with him.) > By the way, this discussion is an example of something I have labelled the > "silence is invisible" phenomenon. It goes like this: there's a discussion; > some of the participants work out an answer, and as far as they're concerned > the discussion is over. However, other participants don't understand the > answer, and keep on talking. In a physical meeting, the talkers would > notice the annoyed looks on the faces of everyone else; or if the meeting > had a good facilitator, he or she would catch on to the misunderstanding > and correct it; but in cyberspace, those feedback mechanisms don't happen. An important observation! I'm sure many of us who've been on the list for a long time (since the start for many of us, without a break!) are feeling frustrated at the same old tired topics being aired and--worse--the same old errors being promulgated. Supposedly new ciphers, rehashes of TEMPEST, continuous explanations of "stenography" by people who don't know how to spell it, and so on. Every one of these tired topics get rehashed every month or so by a new "entering class." Since there's no moderation, the "senior class" can't really stop the freshmen from going on about some pet theory. (Not to trash pet theories, you understand. We all have them. I just want to _again_ encourgage newcomers to do several things. First, read the list for a while--perhaps a month--before making serious posts. Second, read some of the crypto literature. Third, read sci.crypt and talk.politics.crypto and bear in mind that this list is not meant to be a substitute for either. Fourth, read what other people write and carefully think about the implications. That ought to do for starters.) When the list had 300 people, a year or so ago, this was beginning to be a problem, but at least the topics were relatively fresh for many folks. Now, a year later, there are more than 750 people on the list. A continuous input of new subscribers. A constant stream of rehashed ideas and perpetuated mistakes. (Don't get me wrong, though! Some new ideas and new code from folks like Product Cypher have been fantastic! But a lot of newcomers seem unaware of the basics of crypto and want to "share" their thought processes with all 750 subscribers. Some are even speaking favorably of Clipper and key escrow....one wonders why they are on this list.) Anyway, I don't want to sound like I'm dismissing newcomers to the list. I'm just agreeing with Jef's observation and suggesting that too many topics are being taken over by the "clue challenged." Read the literature! Or at least parts of it. Read the stuff in the Cypherpunks archive site (soda.berkeley.edu, in pub/cypherpunks), including the "Glossary" that Eric Hughes and I put together for the first Cypherpunks meeting in September, 1992. Yes, a FAQ is sorely needed. I'm still working on a FAQ for this list, but I fear it will largely go unread by many of the folks who need to read it the most. Please prove me wrong. --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^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway." From tcmay at netcom.com Thu Mar 3 01:21:12 1994 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 3 Mar 94 01:21:12 PST Subject: What's Wrong with the List--Part 2 Message-ID: <199403030922.BAA05223@mail.netcom.com> While I'm on a rant about what's wrong with the way the list is going, let me mention another serious problem: * People who want others to "do more." It seems that every few months someone starts loudly whining that others are not doing enough. This is very grating. For example, Detweiler started down his path to neurosis by begging and pleading for folks on the list to do more to help fulfill his vision of a "whisteblowing" group (note that others had discussed this idea, too, so Detweiler cannot claim all the credit). His pleas were eventually answered by Miron Cuperman, who went ahead and newgrouped "alt.whistleblowing" or similar. This is, by the way, now an essentially zero traffic group. More recently, "Xenon" got it into his head that the most important project in the universe was "Stealth PGP." Again, a good idea (and one that Phil Zimmermann, Kelly Goen, and others were calling by that exact same name more than a year ago). But Xenon figured that if he excoriated us enough for not immediately implementing his vision, we'd eventually work on it. He flamed out after a brief stint on the list and says he is now unsubscribed. (Which is too bad, as he had some good ideas. His problem is that he got _too excited_ about some particular ideas. Yes, getting "too excited" can be a problem: when one exhorts others to do the work one cannot or will not do oneself. In other words, badgering, lecturing, and moralizing. Xenon apparently came to see the lack of a rush to his flavor of steganography as some sort of failure of will by the Cypherpunks, and unsubscribed.) These are the dangers. Whenever I feel the urge to exhort others to work harder and longer at some task, I think about this situation. (I have no problem with political rants, exhorting folks to adopt my point of view on something. But I avoid--I hope--asking others to do work that I am unwilling or unable to do. It just isn't right. If one wants others to do something concrete, a less "bossy" approach is called for, and one should be prepared to give something in return.) Closely related to this issue is the habit some have of talking about what "we" have decided "our" goals are and how these goals of "ours" should be fulfilled. (As a sidenote, L. Detweiler kept asking what the "Cypherpunks goals" were and what the "leaders" expected to be done. When many folks told him in no uncertain terms just what kind of anarchy the List is, poor Detweiler just couldn't handle it. I think "control freaks" like Detweiler want plans, want others in harness to fulfill these plans, and want to boss others around.) I'll stop with the rants for now. Take my comments any way you like, but I hope they are taken in the spirit in which they are given--as honest observations of some of the problmes affecting a list with nearly 800 subscribers. Cheers! --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^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway." From tcmay at netcom.com Thu Mar 3 02:08:33 1994 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 3 Mar 94 02:08:33 PST Subject: HUMOR: Sternlight on the CPSR Clipper Petition Message-ID: <199403031009.CAA09426@mail.netcom.com> Cypherpunks, And now for some humor amidst my rants. This is a post I did that makes light of David Sternlight's bizarre assertion that the anti-Clipper petition of the CPSR contains few valid signatures because he, David Sternlight, asked those who signed the petition to send him e-mail....and he only got 35 responses! QED, the CPSR either faked the signatures or others forged messages. (Sternlight even cites "cypherpunks" as likely culprits, noting that they are skilled at creating phantom identities....I guess Detweiler was listened to by at least one kindred soul.) The methodological flaws in Sternlight's line of reasoning are too obvious to go into here, and Sternlight has sunk to a new low in terms of respect. His claims that he was recently a senior government policy advisor give me new insights into why the government is as screwed up as it is. Finally, I've avoided flaming Sterno in public, and I had some qualms about kicking him while he's so much of a fool over this issue, but my satirical urges got the best of me. Here it is: Newsgroups: comp.org.eff.talk,alt.privacy.clipper,alt.security.pgp,talk.politics.crypto,alt.security.ripem,alt.fan.david-sternlight From: tcmay at netcom.com (Timothy C. May) Subject: Re: CPSR Clipper Petition test results Message-ID: Date: Thu, 3 Mar 1994 09:50:47 GMT Matt Austern (matt at physics2.berkeley.edu) wrote: : The US government claims that over 100 million people voted in the : 1992 Presidential election. Fewer than 50 people, however, personally : told me that they voted in that election. : It won't play, fellas. 50 people out of 100 million? Clearly, this : supposed "election" didn't really happen. This effect is far more widespread than you suspect. Several days ago I posted a request in rec.skate for people to send me e-mail if in fact they watched the Olympics--any or all of it. While the pundits at CPSR (Central Polling for Sports Research) would have us belief that _more than_ 100 million Americans (which is "many" but not "most") watched some or all of the Olympics, I received a paltry 3 responses, and one of these was a string of moronic insults, so I really only count 2 valid response. Could 100 million Americans have watched the Olympics if I only received 2 valid responses to my poll? My many years advising the government in senior policy postions, and my Ph.D in statistics tells me "Not on your life." Applying the Black-Scholes significance test (with a quartile scatter factor normalized to the Kolmogorov constant), I have concluded that the actual number of Olympics watchers was 135 plus or minus 7.32. I thus conclude that CBS, the Olympic Committee, the Tonya Harding Kneecapping Club, and the ever-treacherous CPSR are all lying to us! I will, however, not discuss this matter any further! (At least not until I do.) --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^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway." From kryten at shell.portal.com Thu Mar 3 02:23:22 1994 From: kryten at shell.portal.com (Greg - Kucharo) Date: Thu, 3 Mar 94 02:23:22 PST Subject: Hands On Action Message-ID: <199403031024.CAA24935@jobe.shell.portal.com> > Thanks for your posts Tim.They really got me motivated.Indvidual action gave > us the rights we now enjoy and are threatned.Invidual action will save them > from extinction.When George Washington got fed up with the British slagging > on his rights he didn't sit around a Mt.Vernon getting stoned with Martha > and saying how nice it would be if those lackeys down in Boston would kick > the Redcoats out.He got his musket,saddled his horse and marched his army to > get them out himself,and make way for The Constitution.I don't have a musket > or a horse,but I do have a computer,knowledge of programming and a Computer > Club.It took awhile,but the DeAnza Computer Club is now educated in PGP and > we now turn to our fellow students.As young Americans we arent as used to > being jerked around by our government,and we don't intend to start getting > used to it.I will probably spend a great deal of my adult life on the network > I'll need my rights in there just as much as outside. > Since I have educated my fellow club members and forwarded List posts to them > we are going to start writing crypto programs for use here on campus and on > our club machine.If everyone takes up Crypto arms,we can drive out the Redcoats > and make George proud. From michael.shiplett at umich.edu Thu Mar 3 02:42:53 1994 From: michael.shiplett at umich.edu (michael shiplett) Date: Thu, 3 Mar 94 02:42:53 PST Subject: Missing(??) April 94 DDJ!!???!!??? In-Reply-To: <9403030703.AA18870@prism.poly.edu> Message-ID: <199403031041.FAA17053@totalrecall.rs.itd.umich.edu> "ara" == Arsen Ray Arachelian writes: ara> Speaking of DDJ's nice crypto articles for April 94, I just had a ara> truly weird thing arrive in the mail today. It was a plastic ara> mailer bag from DDJ which contained Vol 1., Issue 1. of DDJ's ara> Developer Update. The plastic envelope was larger than needed ara> for such a mailing. All the bag contains is the 8 page Dev. ara> Update issue and a card with my name and the return address for ara> the snail mail folks to be able to process the package. My Dr. Dobb's Developer Update contained a sheet of paper which stated DDDU is a new monthly update to the magazine in order for DD to cover "timely, ... news & industry oriented, ... product specific" information. The April DDJ arrived yesterday. michael From werner at mc.ab.com Thu Mar 3 04:04:26 1994 From: werner at mc.ab.com (tim werner) Date: Thu, 3 Mar 94 04:04:26 PST Subject: Standard for Stenography? Message-ID: <199403031204.HAA23056@sparcserver.mc.ab.com> >Date: Wed, 02 Mar 94 22:32:39 PST >From: Jef Poskanzer > > In a physical meeting, the talkers would >notice the annoyed looks on the faces of everyone else; Don't forget the pleased looks on the faces of people who are glad to see that Jef P is working on stego. :-) From unicorn at access.digex.net Thu Mar 3 04:07:43 1994 From: unicorn at access.digex.net (Black Unicorn) Date: Thu, 3 Mar 94 04:07:43 PST Subject: Standard for Stenography? Message-ID: <199403031207.AA10243@access3.digex.net> -> The reason for the "STENOGRAPHY" field is to assist your computer in determining if this is a stenography file & that the correct key was chosen without attempting to decrypt the whole file. I know that this presents the possibility of a small "known plaintext attack", but a good encryption system should stand up to such an attack. RSA can ... can't it? <- The problem with your approach (I believe) is that if MY computer can (without an attempt at desteging and decryption with the proper key) tell the file is a stego file, then anyone can filter all traffic and just pick out the stego files. This of course removes half (or most) of the incentive to use stego in the first place. The flaw in your basic motivation is that you place processing speed at a higher value than security. Even if the only loss were a small known plaintext attack potential, it still is not worth (IMHO) the security shortfall that results. Have I misunderstood your suggestion? -uni- (Dark) From unicorn at access.digex.net Thu Mar 3 04:22:21 1994 From: unicorn at access.digex.net (Black Unicorn) Date: Thu, 3 Mar 94 04:22:21 PST Subject: MacPGP a plant? Message-ID: <199403031222.AA10439@access3.digex.net> Now I'm sure I'm jumping to conclusions, but consider the following: 1> The MacPGP2.3 source is, as near as I can tell, unreleased and unavailable. 2> The output from MacPGP2.3 is easily distinguishable from MSDOS output. (MacPGP headers all messages with "Version 2.3" and not "Version 2.3a") 3> The signature file intended to show the applications is intact from the author is not included with the compressed application on any of the sites I have seen MacPGP2.3 on. The implications are left as an exercise for the reader. MacPGP2.3 has been in release for some time now, yet no one has commented (that I have seen) on the absence of a signature file or detached signature with the release. Is this because I just can't find the signature, or is there no signature available? -uni- (Dark) From anonymous at extropia.wimsey.com Thu Mar 3 05:11:15 1994 From: anonymous at extropia.wimsey.com (anonymous at extropia.wimsey.com) Date: Thu, 3 Mar 94 05:11:15 PST Subject: "Children's Letters to Benificent Stalin" Message-ID: <199403031232.AA17647@xtropia> Uu> URBANA -- A University of Illinois student has been arrested for Uu> threatening the life of President Clinton, U.S. Attorney Frances Hulin Uu> announced today. Uu> Christopher James Reincke, 18, of Townsend Hall, Urbana, Uu> allegedly sent an electronic mail message to the White House on Dec. 4 Uu> threatening Clinton, Hulin stated in a press release. About all this proves is that whitehouse.gov reads their e-mail after all, bless their little cotton socks, but one has to use a bit of heavy rhetoric to get any attention. As has been mentioned in another forum, there are Federal laws that require immediate and vigorous investigation of any threat made on the life of the president, serious or not. I am curious as to the practicability of using this (not personally, mind you) as a "barium test" of encryption and remailer security. "Barium" is the old British intelligence term for inserting a dummy message inside normal "secure" communications channels as a check. The content of this message would be so explosive that if the opposition had compromised the communications system, a certain, observable reaction would be forthcoming. To my knowledge, no serious barium testing has been done of either the remailers or PGP, among other "secure" privacy measures. The Sacramento child-molestation case seems to indicate that if PGP was compromised by law enforcement assets (to FBI level in that particular case) this fact would not be revealed for a purpose as politically-insignificant as breaking up a child molestation ring. From pfarrell at netcom.com Thu Mar 3 05:25:55 1994 From: pfarrell at netcom.com (Pat Farrell) Date: Thu, 3 Mar 94 05:25:55 PST Subject: DC 'punks meeting Message-ID: <30511.pfarrell@netcom.com> I'm willing to try to russle up a suitable place for a physical meeting in the DC area in parallel with next Sat's politically oriented left coast meeting. But the number of folks attending will change where I can hold it. If you are interested in attending a DC-area meeting next Saturday, 3PM EST until 5 or so, please send me email. Thanks Pat Pat Farrell Grad Student pfarrell at gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include From m5 at vail.tivoli.com Thu Mar 3 05:45:20 1994 From: m5 at vail.tivoli.com (Mike McNally) Date: Thu, 3 Mar 94 05:45:20 PST Subject: Clipper (Re: Dorothy Denning) In-Reply-To: <199403030249.SAA28948@netcom9.netcom.com> Message-ID: <9403031345.AA23344@vail.tivoli.com> Robert Cain writes: > > 2) Some kinds of technology greatly enhance our [the > > government's] power if we control them. > > 2) Some kinds of technology greatly enhance the power of those > that are ruthless and dangerous. Gee, these statements seem kinda similar... > > 3) Crypto Technology is a major threat to our power unless we > > control it. > > 2) Crypto technology could well be a major threat to the > world's safety unless we control it. I don't understand why I can't participate in making that decision. Why should I trust the government to do so in a way that's even close to representing my values? Isn't this supposed to be a representative democracy? How did such decisions get moved out of the realm of public debate? > > 4) Maybe we can stop it if we act quickly, at a cost to society > > that's low enough that we won't cause a major revolt > > 4) Maybe we can stop it if we act quickly while still providing > society the benefits it wishes. Uhh... I'd rather not pay my government to "provide" me with "benefits" like privacy; I'll take care of that myself, thanks. > > 5) If we pull that off, the success will help consolidate our power. > > 5) If we pull that off, the success will help protect society > from being disrupted, damaged or held hostage by those > wishing power. Says who? Why should I believe it? > > 6) The public believes almost anything we tell them, at least for > > a while, as long as we sound sincere. > > 6) The public feels we are interested in their private lives > and we must change that perception toward our actual > concerns. Yea right. Pull the other one. -- | GOOD TIME FOR MOVIE - GOING ||| Mike McNally | | TAKE TWA TO CAIRO. ||| Tivoli Systems, Austin, TX: | | (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" | From habs at warwick.com Thu Mar 3 07:00:51 1994 From: habs at warwick.com (Harry Shapiro Hawk) Date: Thu, 3 Mar 94 07:00:51 PST Subject: DC 'punks meeting Message-ID: <9403031605.AA00267@uucp.warwick.com> Pat Wrote: > I'm willing to try to russle up a suitable place for a physical > meeting in the DC area in parallel with next Sat's politically oriented > left coast meeting. But the number of folks attending will change > where I can hold it. I can't make that meeting, but I will be in the Baltimore area on the weekend of 19th. hakw Harry Shapiro Hawk Manager of Computer Services Warwick Baker & Fiore habs at uucp.warwick.com From KEPERRIER at setpoint.com Thu Mar 3 08:03:10 1994 From: KEPERRIER at setpoint.com (Kent Perrier) Date: Thu, 3 Mar 94 08:03:10 PST Subject: Need info on Encyption book Message-ID: <9403031603.AA13543@toad.com> Hi all, I have joined the "Small Computer Book Club" and in their "Top 10 Best Sellers" is a book by Gilbert Held called _Top_Secret_ - Data Encryption Techniques. Below is the text description: "Learn how to get people the information they need...without prying eyes getting a look at it, too. This book/disk package introduces you to techniques you can use to secure messages transmitted over internal company networks or public electronic message systems. You'll learn how to protect your communications with techiques for transposing characters in text, replacing characters, with new ones, using arrays, and more. Plus, your free disk features source code for the book's enciphering programs. Softcover, with 3.5" disk. 218pp 1993." Has anyone heard of this book and is it with the $19.95 that they want for it? Thanks Kent Perrier keperrier at setpoint.com (work) kperrier at neosoft.com (play) Corporations don't have opinions, people do. These are mine. PGP 2.3a Public Key available by request From hughes at ah.com Thu Mar 3 08:03:41 1994 From: hughes at ah.com (Eric Hughes) Date: Thu, 3 Mar 94 08:03:41 PST Subject: "Children's Letters to Benificent Stalin" In-Reply-To: <199403031232.AA17647@xtropia> Message-ID: <9403031554.AA00897@ah.com> >To my knowledge, no serious barium testing has been done of either the >remailers or PGP, among other "secure" privacy measures. And a good thing too for the remailers, since they're not secure yet. This is not a problem, however. There are two often overlooked aspects of crypto deployment that the current remailers satisfy nicely: 1) People have to get in the habit of using security tools. 2) The non-cryptographic software infrastructure has to support security tools. For practical purposes, these two aspects are more important than the actual security of the systems created, because the best system is worthless if it goes unused. The remailers work sufficiently well to satisfy these two criteria, well enough to support transparent encryption and remailing in the mail user agents, e.g. elm, rmail. Unfortunately, progress along these lines has been slow. The problem is not primarily technical, however. The way I see it, this is yet another manifestation of one of the really bad social values in the Unix and Internet community. Namely, that integration and ease-of-use just aren't cool. Value and respect are accorded to those endeavors which require high levels of abstractional difficulty or complex optimizations, not to the person who rights an auto-installation routine. There is something of a contempt for the person who's installing software if they can't just tweak the Makefile or some configuration headers a bit. Very few programs don't take some greater or lesser skill as a programmer in order to get working. And Unix-lovers wonder why more people don't use Unix. This hierarchy of value mimics society at large, where design engineers are accorded much more respect that manufacturing engineers. A design engineer creates a nice product and gives it to someone lower on the chain to figure out how to make. This is changing somewhat, but the placement of design over manufacture is still firmly in place. Let me praise Sameer Parekh here for writing an auto-install script for the current remailer. His work is not finished, but it's better than nothing. Also let me critique the ease of use of some of the other crypto applications we have. As far as interface goes, PGP sucks. I've been trying to get a good system running on MSDOS to read my encrypted mail more easily. When PGP gets an error, watch out, and don't expect predictable behavior. PGP doesn't have enough separation of function to determine what the problem is in an automated fashion. Installation of Secure Drive requires, to my knowledge, futzing with disk partition tables in order to use it on an existing harddisk. More programmer skills. The makers of this and similar efforts should find some code for a disk defragmenter and write a program to automatically create a partition, safely moving the existing information out of the way or over to the other partition. The remailers, and regular encryption of email, for that matter, are going to remain mostly unused until these capabilities are integrated into the average mail user agent, and then become part of the standard distributions for these packages. And lastly, for those that might want to call me a hypocrite, remember that I'm working on packaging digital money into a business, the necessary and inevitable ease-of-use packaging for this technology. Eric From hfinney at shell.portal.com Thu Mar 3 08:06:49 1994 From: hfinney at shell.portal.com (Hal) Date: Thu, 3 Mar 94 08:06:49 PST Subject: Standard for Stenography? Message-ID: <199403031607.IAA08429@jobe.shell.portal.com> From: Jef Poskanzer > > > Firstly, congratulations for Sergey Goldgaber's stubborn pushing of > >this topic, for Bill Stewart's observation: "simple stego-programs, > >stealthy encryption programs" > > I disagree with pretty much everything in your message, and since I'm the > one who opened the topic and who is writing the code, my opinion would seem > to count for quite a bit more than yours. I'm not going to repeat the > reasons why the kind of standard you propose is a bad idea, you can fetch > the messages as easily as I can. > > Cc:ed to the list only so that no one thinks Gary's proposal was accepted. > The permutation idea remains the best. I share Jef's disagreement with the spectacularly bad "neon sign" steganography header, but I don't think Sergey's approach was correct and I hope he does not feel the issue is closed yet. Bill Stewart is IMO far more experienced and has far better understanding of the issue than Sergey, who has been a list member for only a few weeks and again IMO suggests a very naive security-through-obscurity approach. Bill Stewart, Norm Hardy, and other list members who have more experience and who have discussed these issues in the past will I think agree that the correct approach is to separate the function of the stegonography program to be a simple and clean insertion, and to have other components be responsible for assuring that what is inserted is statistically indistin- guishable from what is replaced. This notion that a "secret offset" will prevent the stego from being discovered is highly naive IMO. The correct approach is to make it so that the stego cannot be recognized even if the opponent knows where it is. Adding offsets is like attempting to "improve" regular RSA by putting a secret amount of noise padding at the front (not of a stego file, but of an openly encrypted file). This is unnecessary if you trust your encryption, and if you don't trust it then this approach should not make you trust it. Similarly, if your stego is so weak that knowing where it is in the file will allow the opponent to detect it, adding a random offset should not make you feel secure. The correct approach is to have statistical identity between what you are inserting and what you are removing. The stego program itself should then be as simple as possible. Now I will add my own little moral lesson, in the spirit of Tim and Jef. Sometimes when these discussions are re-hashed, old-timers are too busy or bored to join in. New list members express naive views that are not vigor- ously refuted. This is OK, but then some other new member takes these views to represent list consensus. I think it is great that Jef is working on a steganography implementation, but IMO the notion of "random offsets" is so fundamentally misguided that I hope he will reconsider. Hal Finney hfinney at shell.portal.com From hughes at ah.com Thu Mar 3 08:08:44 1994 From: hughes at ah.com (Eric Hughes) Date: Thu, 3 Mar 94 08:08:44 PST Subject: clipper==bad, but how do you explain this to average joe 6-pack? In-Reply-To: <9403030526.AA17582@prism.poly.edu> Message-ID: <9403031559.AA00930@ah.com> >How soon would it be before they will decide that anyone who is afraid >of what the NSA and its fans must be paranoid, so paranoid that they >must be insane and thus, must be put in a mental institution because they >are a danger to themselves and others. Never underestimate the capacity for opressive national governments to put dissidents in mental institutions. Eric From fhalper at pilot.njin.net Thu Mar 3 08:29:15 1994 From: fhalper at pilot.njin.net (Frederic Halper) Date: Thu, 3 Mar 94 08:29:15 PST Subject: spooks Message-ID: <9403031629.AA09423@pilot.njin.net> If there are any spooks on this list aren't they required by law to say that they are if somoeon asked if anyone on on th list was employed by CIA, DOD, FBI or NSA? Reuben Halper From pmetzger at lehman.com Thu Mar 3 08:53:45 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Thu, 3 Mar 94 08:53:45 PST Subject: spooks In-Reply-To: <9403031629.AA09423@pilot.njin.net> Message-ID: <9403031652.AA28856@andria.lehman.com> Frederic Halper says: > If there are any spooks on this list aren't they required by law to > say that they are if somoeon asked if anyone on on th list was > employed by CIA, DOD, FBI or NSA? No. Where did you get such an idea? .pm From jef at ee.lbl.gov Thu Mar 3 09:10:41 1994 From: jef at ee.lbl.gov (Jef Poskanzer) Date: Thu, 3 Mar 94 09:10:41 PST Subject: Standard for Stenography? Message-ID: <9403031710.AA14345@hot.ee.lbl.gov> >I think it is great that Jef is working on a steganography implementation, >but IMO the notion of "random offsets" is so fundamentally misguided that I >hope he will reconsider. I already did - the offsets idea was my second thought, permutation is third. I'm a big fan of the rigidly separated software tools approach. Just look at the pbmplus tookkit. But I also think it's perfectly ok to combine functions when there's a good enough reason. I think this is such a case. The problem is the length field - you've got to have it, and it's recognizable because it begins with a run of 0s. So the stego program should hide it. Mac Stego hides it by XORing with the 2nd-to-lsb of the following 32 bytes - that's a hack, and it won't slow an attacker down for a microsecond. jsteg, if I remember right, does some variable field width encoding - better, but it also remains recognizable to some extent. My solution is to store the file's bits in a specified pseudorandom permutation of the image's available bit positions. It's kind of like the frequency hopping of spread spectrum radio. This hides the length field very thoroughly. It also happens to hide anything else recognizable about the original file. Yes, you should use Stealth PGP for complete security, and my man page will tell you this. However, even with regular PGP the permutation will give you good security against casual attacks, perhaps even commercial attacks. Now, if you can think of a natural, simple interface for a standalone file permutation generator, I'll be happy to separate that part out, and make pnmstego just read bits and stick them in the image in order. The problem with separating it is the bits you want to leave alone. Either the file permutation generator has to generate *trinary* output, which seems gross, or the stego pipeline will have to include an initial DEstego step to extract the unmodified bits from the image. Either of those possibilities is more complicated than just building the permuter into pnmstego. --- Jef From solovay at math.berkeley.edu Thu Mar 3 09:25:31 1994 From: solovay at math.berkeley.edu (Robert M. Solovay) Date: Thu, 3 Mar 94 09:25:31 PST Subject: Next Physical Gypherpunks meeting Message-ID: <199403031725.JAA21991@math.berkeley.edu> Is it scheduled for March 5 or March 12th? --Bob Solovay From mmarkley at microsoft.com Thu Mar 3 09:25:48 1994 From: mmarkley at microsoft.com (Mike Markley) Date: Thu, 3 Mar 94 09:25:48 PST Subject: Forbes magazine against the Clipper? Message-ID: <9403031726.AA02703@netmail2.microsoft.com> I just noticed in the March 14, 1994 issue of Forbes magazine that there is a small blurb about Clipper/Skipjack. >From page 26 "HIGH-TECH SNOOPS" "The Administration is about to browbeat American computer manufacturers (as well as cable and telephone operators) into installing in its machines a special chip that would enable the government to eavesdrop on all computer and telephonic transmissions." It goes on to somewhat describe the governments theory on why they need to do this. Then the article says the following. "This is a really dumb idea. High-tech exports will be devestated. Foreigners aren't going to buy equipment with such a decoding device. More to the point, criminals and terrorists won't either." "The Clinton Administration promises that the enormous power that the Clipper Chip gives the feds will not lead to abuses of our privacy. Baloney." This is not a full reproduction of the article but covers the main direction of it. All quotes are fully intact and not paraphrased. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mike Markley || The opinions here do not represent the mmarkley at microsoft.com || opinions of my employer. Attempts to || associate the two are pointless. "I want to look at life, In the available light" - Neil Peart - From sergey at delbruck.pharm.sunysb.edu Thu Mar 3 09:36:21 1994 From: sergey at delbruck.pharm.sunysb.edu (Sergey Goldgaber) Date: Thu, 3 Mar 94 09:36:21 PST Subject: standard for stegonography? Message-ID: On Tue, 01 Mar 94, you wrote: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Then that generator is used to make a *permutation* > of the bit locations in the image, and the file's bits are stored in > the permuted order. Will this be reversible? Will a plain-text header be neccessary for the intended recipient to how to reverse the function? > I'm not going to have ITAR problems with this, am I? RNGs are still > legal to export? Haven't you heard? Everything mathematical is under restriction now! ;) Sergey From mnemonic at eff.org Thu Mar 3 09:38:00 1994 From: mnemonic at eff.org (Mike Godwin) Date: Thu, 3 Mar 94 09:38:00 PST Subject: Internet World article on Clipper Message-ID: <199403031738.MAA16760@eff.org> A Chip Over My Shoulder: The Problems With Clipper Column for July 1994 issue of Internet World By Mike Godwin "Only in a police state is the job of a policeman easy." --Orson Welles Your government is deeply troubled by the possibility that you can keep a secret. Or, to put it more precisely, the government is disturbed by the prospect of widespread powerful encryption tools in individual hands. Once you can keep your communications and data truly secret, officials worry, the value of wiretapping, an important law-enforcement and intelligence tool, will evaporate. It's unclear whether the government's arguments are valid. But regardless of whether they are, the government's latest efforts to prevent us from adopting powerful and uncrackable encryption technologies raise serious questions about personal liberty, the role of government, and the possibility of privacy in the 21st century. If you're not already familiar with these efforts, here's an update. The Clinton Administration has embarked on an ambitious plan to prevent a mass market for uncrackable encryption from arising. The first step in this plan has already been announced: the Administration has called for the entire federal government to adopt the Clipper Chip--an encryption standard with a "back door"--for communications and data security. In addition, the government has declared its intention to use every legal method short of outright prohibition to discourage alternative forms of encryption technology. "Just what is this Clipper Chip?" you may be wondering. The short answer is: the chip is an encryption device, developed to National Security Agency specs, that keeps your communications and data secret from everyone ... except the government. To understand how the chip works, you need to look at what officials call its "key escrow encryption method." Manufactured by a private company called Mykotronix, the chip uses an NSA-developed algorithm called "Skipjack, " which, by all accounts so far, is a remarkably powerful algorithm. But the chip also includes the "feature" that its primary encryption key can be divided up mathematically into two "partial keys." The government proposes that each partial key be held by a separate government agency--the Administration has picked the Department of the Treasury and the National Institute of Standards and Technology (NIST)--from which the keys can be retrieved when government officials obtain a wiretap order. The NSA and the FBI love this idea. With the Clipper Chip in your phone or computer, they believe, you have the power to keep your information private from crooks and industrial spies and anyone else who wants to pry--except of course for law enforcement and the NSA. Law enforcement and intelligence agencies would be barred from seeking those escrowed keys in the absence of legal authorization, normally a court order. "And of course you needn't worry about us," say government officials. "We're here to protect you." Chips Off the New Block The current initiative has been a long time coming. It was in April of last year the Clinton Administration first announced Clipper--the announcement was met with a public outcry from civil-liberties and industry groups. Civil libertarians were concerned about the government's insistence on its need to prevent citizens from having access to truly unbreachable privacy technologies. Computer and telecom industry leaders worried about a standard that might crush a potentially vital market in such technologies. At first the Administration expressed a willingness to listen. The Digital Privacy and Security Working Group, a coalition of industry and public-interest organizations headed by the Electronic Frontier Foundation, outlined its objections and expressed the hope of engaging in talks with the Administration about the issue. In early February of this year, however, the Clinton Administration and various agencies announced to the world that, in spite of the grave misgivings of civil-liberties and industry groups, it would be proposing the Clipper Chip's encryption scheme as a new Federal Information Processing Standard (FIPS). The standard, stresses the government, will be entirely "voluntary"--but the government plans to use export-control laws and other methods to frustrate the market for any competitive form of encryption technology. Current export-control laws restrict the sales in foreign controls of encryption hardware and software. The laws have not been entirely effective in keeping commercial encryption technologies out of foreign hands--it's possible these days to buy encryption products in Moscow, for example. But the laws do succeed in deterring the American software industry from developing powerful and easy-to-use encryption products, since any company that does so is denied the right to sell the product on the global market. Still, if Clipper is voluntary, you may ask, what does it matter to *individuals *what standard the government adopts? The government also adopted the ADA programming language, after all, yet there are still people programming in all sorts of languages, from BASIC to C++. The answer is simple--"freedom of choice" is meaningful only if there are real choices. The government's export-control strategy is designed to make sure that there aren't any choices. If commercial software companies aren't allowed to sell encryption to the world market, they're unlikely to develop strong, easy-to-use alternatives to Clipper. And that means individuals won't have access to alternatives. Now, it's perfectly possible, in theory, to thwart the government-approved Clipper scheme by using a non-commercial encryption application, such as PGP, to pre-encrypt your messages before sending them through Clipper-equipped devices. But PGP and other products, because of their slowness or difficulty, are never likely to expand beyond the circle of hobbyists that enthusiastically support them. For encryption products to give rise to a genuine consumer market, they have to be quick and almost transparently easy to use. The government knows this, which is why their focus is on nipping (clipping?) the commercial encryption software market in the bud. It's the commercial market that really matters. The government's side When asked to substantiate the need for Clipper, or the threat of unbreakable encryption, the government often talks about crime prevention. As a practical matter, however, wiretaps are almost always used *after* crimes are committed--to gather evidence about the individuals the government already suspects to have been involved in a crime. So, the hypothetical cases involving nuclear terrorism or murder-kidnappings aren't really convincing--it's the rare case in which a wiretap prevents a crime from occurring. As a practical matter, the single most important asset to law enforcement is not wiretaps but informants. And nothing about unbreakable encryption poses the risk that informants are going to disappear. One of the more rational statements of the government's case for Clipper comes from my friend Trotter Hardy, a law professor at William and Mary, who writes: "The government's argument, I take it, is that the benefit is law enforcement. That strikes me as at least as great a benefit as minimum wage laws; perhaps more, since it protects everybody (at least in theory), whereas [minimum] wage laws primarily benefit their recipients. Maybe EPA regs are the better analogy: everybody gets reduced pollution; with Clipper, everybody gets reduced criminal activity. Is that not a reasonable trade-off?" But the problem is that the government refuses to be forthcoming as to what kind of trade-off we're talking about. According to government statistics, there are fewer than 1000 state and federal law-enforcement wiretaps per year, and only of a minority of these wiretaps leads to convictions. Yet we are being asked to abandon the chance for true privacy and to risk billions of dollars in trade losses when there has never been shown to be any crime associated with uncrackable encryption whatsoever. And we're also being asked to believe that the kind of criminals who are smart enough to use encryption are dumb enough to choose the one kind of encryption that the government is guaranteed to be able to crack. Moreover, there are fundamental political issues at stake. This country was founded on a principle of restraints on government. A system in which the privacy of our communications is contingent on the good faith of the government, which holds all the encryption keys, flies in the face of what we have been taught to believe about the structure of government and the importance of individual liberty. In short, the government fails to make its case in two separate ways--pragmatically and philosophically. Trotter goes on to write: ".... I don't think the government cares whether an accountant in India can password protect a spreadsheet. I would guess that even Clipper or DES [the government's current Digital Encryption Standard] or whatever would be more than enough protection for such a person. I think the government cares that it be able to detect foreign intelligence that is relevant to US security or interests. I am not sure where I come out on the question, but at the very least it seems to me that the government is reasonable in this desire." Yet there are some premises here that need to be questioned. Do we really suppose that "foreign intelligence" is dependent on the American software industry to develop its encryption tools? Diffie-Helman public-key encryption and DES are already available worldwide, yet Microsoft can't export software that contains either form of encryption. No, the real issue is that, to the extent that a mass market arises for encryption products, it makes the NSA's job more difficult, and it may at some future time make some investigations more difficult as well. When asked to quantify the problem, however, the government invariably begs off. Instead, government spokespeople say, "Well, how would you feel if there were a murder-kidnapping that we couldn't solve because of encryption?" To which my answer is, "Well, I'd feel about the same way that I'd feel if there were a murder-kidnapping that couldn't be solved because of the privilege against self-incrimination." Which is to say, I understand that limits on government power entail a loss in efficiency of law-enforcement investigations and intelligence-agency operations. Nevertheless, there is a fundamental choice we have to make about what kind of society we want to live in. Open societies, and societies that allow individual privacy, are *less safe*. But we have been taught to value liberty more highly than safety, and I think that's a lesson well-learned. What's more, we need to be able to engage in rational risk assessment, and that's something that the government resists. Instead, the government subscribes to the reasoning of Pascal's Wager. Pascal, you may recall, argued that the rational man is a Christian, even if the chances that Christianity is true are small. His reasoning is quasi-mathematical--even if the chances of Christianity's truth are small, the consequences of choosing not to be a Christian are (if that choice is incorrect) infinitely terrible. Eternal torment, demons, flames, the whole works. This is precisely the way that the government talks about nuclear terrorism and murder-kidnappings. When asked what the probability is of a) a nuclear terrorist, who b) decides to use encryption, and c) manages otherwise to thwart counterterrorist efforts, they'll answer "What does it matter what the probability is? Even one case is too much to risk!" But we can't live in a society that defines its approach to civil liberties in terms of infinitely bad but low-probability events. Open societies are risky. Individual freedom and privacy are risky. If we are to make a mature commitment to an open society, we have to acknowledge those risks up front, and reaffirm our willingness to endure them. We face a choice now. After a century of technological development that has eroded our ability to keep our personal lives private, we finally possess, thanks to cheap computing power and advances in cryptography, the ability to take privacy into our own hands and make our own decisions about how much, and how well, to protect it. This prospect is frightening to a government that has come to rely on its ability to reach into our private lives when it sees the need to do so. But I have faith that our society is not dependent on our government's right to mandate disclosure of our personal records and private communications--that a mature society can tolerate a large degree of personal privacy and autonomy. It's a faith I hope you share. From qjones at infi.net Thu Mar 3 09:38:48 1994 From: qjones at infi.net (Wayne Q Jones) Date: Thu, 3 Mar 94 09:38:48 PST Subject: Applied Crypto In-Reply-To: <9403012345.AA19252@pilot.njin.net> Message-ID: They dont ....I was there today. mrcnext.......? On Tue, 1 Mar 1994, Frederic Halper wrote: > Does anyone know if Project Guttenberg(or anyone else) has electronic books > such as applied cryptography? > Thanks, > Reuben Halper > **************************************************************************** * Qjones at infi.net So I'm a dog...what else is new? * * Qjones at larry.wyvern.com Quote from life and times of a man * **************************************************************************** From lefty at apple.com Thu Mar 3 09:53:10 1994 From: lefty at apple.com (Lefty) Date: Thu, 3 Mar 94 09:53:10 PST Subject: Need info on Encyption book Message-ID: <9403031752.AA23634@internal.apple.com> >Has anyone heard of this book [_Top_Secret_ - Data Encryption Techniques] and >is it with the $19.95 that they want for it? Only if you have a pressing and immediate need for a doorstop, or need special help solving the "Cryptoquotes" in your local paper. Based on my inspection of a copy at a local bookstore, it's utter and complete rubbish. Spend the extra thirty bucks and get a copy of Bruce Schneier's book _Applied Cryptography_ instead. -- Lefty (lefty at apple.com) C:.M:.C:., D:.O:.D:. From a2 at ah.com Thu Mar 3 09:55:24 1994 From: a2 at ah.com (Arthur Abraham) Date: Thu, 3 Mar 94 09:55:24 PST Subject: Dorthy Denning In-Reply-To: <9403021557.AA10445@ah.com> Message-ID: <9403031745.AA01291@ah.com> Robert Cain writes: > exist and that liklihood is very small. Persuasion is not working and > the press has been whipped into a near hysterical state over this by we > and our friends (yes, we on the internet are considered to be the force > that has derailed their hopes and that was unforseen.) > How did it happen that "we on the internet" was an unforseen force? The first answer is obvious: they didn't realize that cohesive action would arise out of the internet. The second is not so obvous, but illuminates part of the Clipper strategy: The Clipper promoters assumed the the issue to be beyond most citizen's technical horizo. However, the unexpected thing which happened was that the initial few who did understand rapidly interneted the information to others.i Without the internet, the information, and opposition, would have spread more slowly. Cain observes that Denning and friends are afraid of the *unknown* that will come out of the new communications technologies. The reaction to Clipper, and how developed, should convince them they are right. -a2 From mg5n+ at andrew.cmu.edu Thu Mar 3 10:09:43 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Thu, 3 Mar 94 10:09:43 PST Subject: Need info on Encyption book In-Reply-To: <9403031603.AA13543@toad.com> Message-ID: > You'll learn how to protect your communications with > techiques for transposing characters in text, replacing > characters, with new ones, using arrays, and more. Haha... sounds more like "How to encrypt messages so that prying eyes can read them too." Character substitution? You'll need to do a lot better than that to beat cryptanalysis. A simple character substitution array wouldn't fool most people on this list if they took a serious crack at it. From bsteve at zontar.attmail.com Thu Mar 3 10:24:51 1994 From: bsteve at zontar.attmail.com (Steve Blasingame) Date: Thu, 3 Mar 94 10:24:51 PST Subject: D.Denning Reply Message-ID: <9403031641.AA27701@zontar.attmail.com> Here is Dorothy Denning's reply to my response to her Newsday article. The shocking features are that she does not seem able to differentiate legality from morality, and doesn't seem to believe that law should flow from a popular majority, but from the state. Sure sounds like she wants a police state to me. Steve Blasingame bsteve at zontar.com -------------------- From daemon Mon Feb 28 09:06:58 1994 Date: Mon Feb 28 11:25:34 -0500 1994 From: netcomsv!chair.cosc.georgetown.edu!denning Subject: Re: Newsday Editorial To: internet!attmail!zontar!bsteve Reply-To: netcomsv!chair.cosc.georgetown.edu!denning (Dorothy Denning) Thanks for your comments. I have tried to address the law enforcement issues you raised in a more thoughtful way in the attached. Dorothy Denning --------------- Encryption and Law Enforcement Dorothy E. Denning Georgetown University February 21, 1994 Summary Although encryption can protect information from illegal access, it can also interfere with the lawful interception of communications by government officials. The goal of this report is to describe the effect of encryption technology and the government's new Escrowed Encryption Standard [EES] on law enforcement, mainly from the perspective of law enforcement. The information presented here was obtained from public documents and testimonials by law enforcement officials, from private conversations with people in the FBI and other law enforcement agencies, and from comments I received by people in law enforcement on an earlier version of this report. Some of this research was performed in conjunction with my earlier study of the FBI's proposal on Digital Telephony [DT, Denning]. The following summarizes the key points, which are discussed in greater depth in the sections that follow: 1. The need for wiretaps: Court-authorized interception of communications is essential for preventing and solving many serious and often violent crimes. Electronic surveillance not only provides information that often cannot be obtained by other means, but it yields evidence that is considerably more reliable and probative than that obtained by most other methods of investigation. No other investigative method can take its place. 2. The threat of encryption to lawful surveillance: Because encryption can make communications immune from lawful interception, it threatens a key law enforcement tool. The proliferation of high quality, portable, easy-to-use, and affordable encryption could be harmful to society if law enforcement does not have the means to decrypt lawfully intercepted communications. Although encryption of stored files is also of concern, 99% of the issue is telephone communications (voice, fax, and data). 3. Digital Telephony: Encryption is not the only threat to lawful electronic surveillance. Advances in telecommunications also threaten the ability of law enforcement to conduct authorized interceptions. 4. Encryption policy and the EES: The government's Escrowed Encryption Standard offers a balanced solution to the encryption problem that takes into account the equities of public safety, effective law enforcement, and national security along with those of privacy, security, and industry success. The technology and accompanying procedures provide strong encryption and a high level of security, while accommodating the need for real-time or near real-time decryption of intercepted communications. The program is the best known solution, at least for the intended initial application, mainly voice, fax, and data encryption over the public switched network. 5. Criminal use of Non-EES Encryption: Although some criminals may seek to use other forms of encryption, the escrowed encryption standard may succeed and become ubiquitous as the chief form of encryption, making it much harder for criminals to evade interceptions by using non-standard, non-interoperable encryption. 6. International problem: The impact of encryption on law enforcement is an international problem. The U.S. government exercised strong leadership by recognizing the problem and developing a solution before it becomes serious. 1. The Need for Wiretaps Law enforcement views court-authorized interception of communications as essential for preventing and solving many serious and often violent crimes, including terrorism, organized crime, drugs, kidnaping, major white collar crime brought against the government, and political corruption [DT, DT Cases, Kallstrom]. In testimony before the Computer Systems Security and Privacy Board, James Kallstrom, former Chief of the FBI's Engineering Section, estimated that wiretaps are used in excess of 90% of all cases involving terrorism, often with the result of preventing a terrorist act. For example, in a Chicago case code-named RUKBOM, the FBI successfully prevented the El Rukn street gang, which was acting on behalf of the Libyan government, from shooting down a commercial airliner using a stolen military weapons system [Kallstrom, DT Cases]. Examples of other terrorist attacks successfully prevented with the help of electronic surveillance include the bombing of a foreign consulate in the U.S. and a rocket attack against a U.S. ally. Electronic surveillance is used against organized crime, widespread fraud, bribery, and extortion. It was used to help solve a case involving corruption associated with organized crime control of the International Longshoremen's Union, which cost the citizens of New York city 10-12 cents on every dollar spent on consumer items coming through the port of New York, and to help solve another case involving organized crime control over the construction trade of New York City, which had led to 3-5% of all construction contracts being escalated by that percentage [Kallstrom]. Evidence obtained from electronic surveillance in a case involving the Concrete and Cement Workers Union prevented an economic loss to the public of $585 million [DT Cases]. According to the FBI, the hierarchy of La Cosa Nostra has been neutralized or destabilized through the use of electronic surveillance, and thirty odd years of successes would be reversed if the ability to conduct court-authorized electronic surveillance was lost. Almost two thirds of all court orders for electronic surveillance are used to fight the war on drugs, and electronic surveillance has been critical in identifying and then dismantling major drug trafficking organizations. In an operation code named "PIZZA CONNECTION," an FBI international investigation into the importation and distribution of $1.6 billion worth of heroin by the Sicilian Mafia and La Cosa Nostra resulted in the indictment of 57 high-level drug traffickers in the U.S. and 5 in Italy [DT Cases]. The FBI estimates that the war on drugs and its continuing legacy of violent street crime would be substantially, if not totally, lost if law enforcement were to lose its capability for electronic surveillance. Wiretaps are used for cases involving murders and kidnapings. As the result of wiretaps, sufficient evidence was obtained to arrest and convict a serial-murderer who had been operating for three to four years, and to locate and subsequently convict two other persons who had been involved with the murders [DT Cases]. By intercepting voice, fax, and communications on a local bulletin board system, the FBI prevented the proposed kidnaping and murder of a young child for the purpose of making a "snuff murder" film [Kallstrom]. Through wiretaps, the FBI prevented a group from bombing a man's house and killing him and his family [Kallstrom]. Electronic surveillance has been used to investigate aggravated governmental fraud and corruption. A recent military-procurement fraud case ("Ill-Wind") involving persons in the Department of Defense and defense contractors has so far led to 64 convictions and about $260 million in fines, restitutions, and recoveries ordered. In another case, U.S.District Court Judge Robert Collins was convicted of soliciting and accepting bribes [DT Cases]. John Kaye, Prosecutor for Monmouth County, New Jersey, reported that almost every police officer indicted in his county has been indicted because of a wiretap [Kaye]. In the decade from 1982 to 1991, state and federal agencies were granted 7,467 court orders for interceptions under Title III of the Omnibus Crime Control and Safe Streets Act and equivalent state statutes. At the end of 1991, these had led to 35,851 arrests and 19,259 convictions. Convictions resulting from interceptions conducted in the last few years are still accumulating, as trials regarding those subjects are held. Because the number of arrests associated with wiretaps is a small fraction of all arrests each year, some people have questioned whether wiretaps are necessary or worthwhile given the availability of other investigative techniques. By law, wiretapping cannot be used if other methods of investigation could reasonably be used instead. Such normal investigative methods usually include visual surveillance, interviewing subjects, the use of informers, telephone record analysis, and Dialed Number Recorders (DNRs). However, these techniques often have limited impact on an investigation. Continuous surveillance by police can create suspicion and therefore be hazardous; further, it cannot disclose the contents of telephone conversations. Questioning identified suspects or executing search warrants at their residence can substantially jeopardize an investigation before the full scope of the operation is revealed, and information can be lost through interpretation. Informants are useful and sought out by police, but the information they provide does not always reveal all of the players or the extent of an operation, and great care must be taken to ensure that the informants are protected. Moreover, because informants are often criminals themselves, they may not be believed in court. Telephone record analysis and DNRs are helpful, but do not reveal the contents of conversations or the identities of parties. Other methods of investigation that may be tried include undercover operations and stings. But while effective in some cases, undercover operations are difficult and dangerous, and stings do not always work. Law enforcers claim that no other method can take the place of wiretaps [Kallstrom]. Each court order must provide evidence for the need to wiretap by demonstrating that normal investigative procedures have been tried and have failed or reasonably appear unlikely to succeed or would be too dangerous [USC 18, DDKM]. This does not mean that the other methods are not used in those cases, as indeed they are, but only that they are inadequate to successfully investigate and prosecute the cases. Wiretaps not only provide information that cannot be obtained by other means, but yield evidence that is considerably more reliable and probative than that obtained by most other methods of investigation. A wiretap is also less dangerous than sending in a civilian informant or undercover agent who is wired since the risk of discovery puts that person's life in jeopardy. Finally, a wiretap may be less invasive of privacy than placing a bug in a subject's home or using an undercover agent to establish an intimate relationship with the subject. Although the number of arrests from wiretaps is relatively small compared to the total of all arrests, those criminals that are arrested and convicted with the aid of wiretaps are often the leaders of major organized crime, drug trafficking, and terrorist groups. In reviewing a proposal for a wiretap, law enforcement agencies determine whether the subjects of the proposed interception are worthy targets of investigation and whether the interception is worth doing. The law enforcement community views electronic surveillance as essential to effective law enforcement, and law enforcement as essential not only to public safety and our economic well-being, but to a free society. In his remarks at the Computer Ethics Conference, Alan McDonald of the FBI summed it up: "We have been fortunate as a society to enjoy unparalleled freedom. It has resulted because we live under a compact of ordered liberty. One need only consider the number of countries where law enforcement is ineffective and where the violence and corruption of organized crime reign to see true diminishments of freedom, liberty, and personal privacy" [McDonald]. 2. The Threat of Encryption to Lawful Surveillance Encryption has been available to criminals for a long time. Until recently, however, voice encryptors were extremely bulky and the quality of the voice low, so criminals who tried encryption would typically cease using it [Kallstrom]. But recent advances in encryption technology are leading to products such as the AT&T 3600 Telephone Security Device that are small, portable, easy-to-use, affordable, and have high quality audio. Law enforcers expect that criminals will flock to such devices, not only to hide their communications from the government, but to safeguard them from their competitors [Kallstrom, Meeks]. The effect could be that criminals are able to make their communications immune from government search and seizure even under probable cause of criminal activity. The proliferation of such encryption products ultimately could be harmful to society if government officials do not have the means to decrypt lawfully intercepted communications, at least in most cases. On behalf of the National District Attorney's Association, President Robert Macy writes: "In an increasingly dangerous world, law enforcement cannot afford to be blindfolded by advanced technologies including encryption devices" [Macy]. Roy Kime, Legislative Counsel for the International Association of Chiefs of Police, makes the analogy that people in law enforcement are being "outgunned" by the criminals with respect to advances in technology [Kime]. In testimony before Congress, Donald Delaney, Senior Investigator with the New York State Police, said he believed that if we adopted an encryption standard that did not permit lawful intercepts, we would have havoc in the United States [Delaney]. Although there are no "dead bodies" as yet, Kallstrom believes there will be a "horror show" if the encryption that proliferates in the market does not factor in an equity for law enforcement [Kallstrom]. Criminals can use encryption to conceal stored information as well as communications. In a child pornography case on the West coast, encrypted data files have slowed down the investigation of a large international ring dealing with child pornography and the possible smuggling of children [Kallstrom]. However, although law enforcement is concerned about the use of encryption to conceal computer files, their primary concern is with communications, particularly telephone conversations. This is because intercepts play a much more important role in investigations than documents. Real-time intercepts pick up the criminal dialogue, the plotting and planning that glues crimes together. By revealing conversations about possible future activities, wiretaps also may be used to prevent crimes from occurring. Thus, while being able to decrypt files is valuable, 99% of the issue today is telephone conversations [Kallstrom]. In addition, while communications over high speed computer networks are expected to become an issue, the primary concern today is with voice, fax, and data over the public switched network (telephone system). 3. Digital Telephony Encryption is not law enforcement's only concern about wiretaps. They are also concerned about changes in telecommunications technologies. Many of the new digital-based technologies and services such as ISDN, fiber optic transmissions, and the increasing number of mobile telecommunication networks and architectures cannot be tapped using the traditional methods used to intercept analogue voice communications carried over copper wire. In addition, increases in transmission speed have made interceptions more difficult. Although it is technically feasible to intercept the new communications, not all systems have been designed or equipped to meet the intercept requirements of law enforcement. According to the FBI, numerous court orders have not been sought, executed, or fully carried out because of technological problems. To address these problems, the Department of Justice proposed Digital Telephony legislation [DT] that would require service providers and operators to meet their statutory assistance requirements by maintaining the capability to intercept particular communications. So far, the proposal has not been introduced in Congress. 4. Encryption Policy and the EES Law enforcement seeks an encryption policy that takes into account the equities of public safety, effective law enforcement, and national security along with those of privacy, security, and industry success [Kallstrom]. They support the use of encryption by law abiding citizens and organizations to protect sensitive information, and recognize the importance of encryption to safeguarding information assets [Settle]. They generally favor strong encryption over weak or "dumbed down" encryption [Kallstrom]. To implement lawful interceptions of encrypted communications, they need a real-time or near real-time decryption capability in order to keep up with the traffic and prevent potential acts of violence. Since there can be hundreds of calls a day on a tapped line, any solution that imposes a high overhead per call is impractical. These requirements for strong encryption and near real-time decryption led to the Escrowed Encryption Standard [EES] and its related key escrow system. Upon receiving a chip's unique key components from the two escrow agents, law enforcers can readily decrypt all conversations encrypted with the chip until the wiretap terminates, at which time all chip-related keys are destroyed. The escrow agents need not get involved in the decryption of each conversation, which would be overly cumbersome. Law enforcers consider the EES to be the best known approach for addressing the dual need for secure communications and court-ordered access, at least for the intended initial application, namely voice, fax, and data encryption of telephone communications transmitted over the public switched network. The EES will significantly enhance communications security by making strong encryption available in a way that makes illegal wiretaps virtually impossible, while permitting those that are lawfully authorized. The key escrow mechanisms and procedures are being designed to provide a high level of protection for keys and to protect against compromises or abuses of keys, thereby assuring that no person or entity, including government, can improperly access one's EES communications. Although there is no evidence of widespread abuse of wiretaps by law enforcement officials, the EES will effectively thwart any potential abuse, thereby providing greater protection from illegal government wiretaps than currently exists. The Presidential Decision Directive [PDD] on escrowed encryption is viewed as offering a balanced solution to the encryption problem that is consistent with basic tenets found in the Constitution and in the Bill of Rights, which does not grant an absolute right to privacy, but rather seeks to balance individual privacy with the need to protect society as a whole [McDonald]. William A. Bayse, Chief Scientist of the FBI, observed: "It is well recognized that Anglo-American law has historically balanced the personal privacy of the individual with the legitimate needs of Government. ... As can be seen from a review of the Fourth Amendment to the U.S. Constitution ..., an individual's privacy rights are not absolute, and they give way to more compelling Governmental rights when criminality is demonstrated or suspected." [Bayse]. Similarly, Alan McDonald noted "... the dictum of the Bill of Rights, and the Fourth Amendment in particular, is a balance between individual liberty and privacy and the legitimate need of Government to protect society as a whole -- a balance to prevent the tyranny of absolutist Government and the tyranny of lawlessness and anarchy. ... The electronic surveillance statutes, like the Fourth Amendment, are founded on the concept of balancing fundamental individual and governmental interests -- personal privacy and the public safety. ... Encryption technology creates no legal rights under our Constitution, the Fourth Amendment, or under our electronic surveillance statutes" [McDonald]. 5. Criminal Use of Non-EES Encryption Some people have argued that criminals will not use EES, but rather will use encryption methods that defeat law enforcement. While acknowledging that some criminals may use other means, law enforcers assume most vendors will not manufacture an encryption device unless they perceive a large, legal market [Kallstrom]. The hope is that the EES, or some other approach that takes into account the law enforcement equities, will proliferate in the legitimate encryption market in this country and become transparent, thereby cutting down on the availability and use of encryption that does not include the law enforcement equities [Kallstrom]. There is some evidence that through market forces and government purchasing power, the EES may become the de facto national standard for telephone encryption. When AT&T announced its 3600 Telephone Security Device in Fall 1992, the device used a DES chip for encryption, and did not include a capability for law enforcement access. Priced at $1200, it would have been attractive to criminals, and could have led to the promulgation of encryption technology that would have posed a major threat to law enforcement. However, when the government announced the key escrow initiative on April 16, 1993, AT&T simultaneously announced that the TSD would use instead the new Mykotronx MYK-78 chip, aka "Clipper", which uses the EES. The government ordered several thousand of the modified devices. Since EES products can be exported to most places, there is an additional incentive for vendors to incorporate the EES into their products rather than, say, the DES, which is subject to stricter export controls. However, there are other factors relating to the nature of the technology and to public acceptance that could interfere with widespread adoption of EES by vendors. Criminals need to talk with many people outside their circle in order to carry out their activities, for example to rent or purchase needed goods and services. To conduct those conversations, which may be incriminating, they will either need to use an encryption method identical to that used by the other parties or else forego encryption entirely. Assuming EES dominates in the legitimate market, criminals may prefer to use it over communicating in the clear since the EES will at least protect them from their competitors. Criminals are often sloppy in protecting their conversations from law enforcement, making incriminating statements over the phone while acknowledging their phones may be tapped. Even if criminals do not use the EES, the government's objective of making strong encryption available to the public in a way that is not harmful to society will be achieved. Criminals will not be able to take advantage of the strong algorithm to thwart law enforcement. Since it is extremely difficult to develop high quality, strong encryption products, law enforcement may be able to access many non-EES encrypted criminal communications. 6. An International Problem The impact of encryption on effective law enforcement is an international problem, and U.S. law enforcers have observed other countries looking at solutions based on "dumbing down" the encryption or on key escrow. The U.S. government exercised strong leadership by recognizing the problem and developing a solution before it became serious. While the U.S. solution will not necessarily provide an international solution, it as a starting point for solving a global problem. References [Bayse] Bayse, William A., Written statement presented at Part I of the Forum on Rights and Responsibilities of Participants in Networked Communities, panel on Privacy and Proprietary Interests, Computer Science and Telecommunications Board, National Research Council, October 1992. [Delaney] Delaney, Donald P., statement in "Hearings before the Subcommittee on Telecommunications and Finance of the Committee on Energy and Commerce, House of Representatives," June 9, 1993; Serial No. 103-53, pp. 163-164. [DDKM] Delaney, Donald P; Denning, Dorothy E.; Kaye, John; and McDonald, Alan R., "Wiretap Laws and Procedures: What Happens When the Government Taps a Line," September 23, 1993; available from Georgetown University, Department of Computer Science, Washington DC, or by anonymous ftp from cpsr.org as cpsr/privacy/communications/wiretap/ denning_wiretap_procedure.txt. [EES] "Escrowed Encryption Standard," Federal Information Processing Standard Publication (FIPS PUB) 185, National Institute for Standards and Technology, 1994. [Denning] Denning, D. E., "To Tap or Not to Tap," Comm. of the ACM, Vol. 36, No. 3, March 1993, pp. 25-35, 42-44. [DT] "Digital Telephony," U.S. Department of Justice, Federal Bureau of Investigation. [DT Cases] "Digital Telephony Case Examples," distributed with press packet for Presidential Decision Directive on "Public Encryption Management." [Kallstrom] Kallstrom, James K., Presentation at the Computer System Security and Privacy Advisory Board Meeting, National Institute of Standards and Technology, July 29, 1993. [Kaye] Kaye, John, Presentation at the Computer System Security and Privacy Advisory Board Meeting, National Institute of Standards and Technology, July 29, 1993. [Kime] Kime, Roy, Presentation at the Computer System Security and Privacy Advisory Board Meeting, National Institute of Standards and Technology, July 29, 1993. [Macy] Macy, Robert H., Letter submitted to the Computer System Security and Privacy Advisory Board on behalf of the National District Attorneys Association for June 2-4 Meeting, May 27, 1993. [McDonald] McDonald, Alan R., Written statement presented at 2nd National Computer Ethics Conference, April 29, 1993. [Meeks] Meeks, Bud, Presentation at the Computer System Security and Privacy Advisory Board Meeting, National Institute of Standards and Technology, July 29, 1993. [PDD] Presidential Decision Directive on "Public Encryption Management," and Statement by the Press Secretary, The White House, April 16, 1993. [Settle] Settle, James C., Presentation at INFOEXPO '93, Information Security and Virus Prevention Conference and Exhibition, National Computer Security Association, June 11, 1993. [USC 18] Title 18 USC, Sections 2510-2521. (These sections codify Title III of the Omnibus Crime Control and Safe Streets Act of 1968, as amended by the Electronic Communications Privacy Act of 1986.) ------------------------ From cowen at glia.biostr.washington.edu Thu Mar 3 10:29:44 1994 From: cowen at glia.biostr.washington.edu (cowen at glia.biostr.washington.edu) Date: Thu, 3 Mar 94 10:29:44 PST Subject: No Subject Message-ID: <9403031840.AA12486@glia.biostr.washington.edu> about this meeting you all are having. once you have had the meeting will those of us that are un able to attend for one reason or another, be able to find out what went on??? ie a sort of points made at he meeting and other general info, in a post to this list. i would love to be there. but i don't have access to the irc. and my computer time is whenever i get the chance. thanks charles the monster maker From banisar at washofc.cpsr.org Thu Mar 3 11:07:39 1994 From: banisar at washofc.cpsr.org (Dave Banisar) Date: Thu, 3 Mar 94 11:07:39 PST Subject: Clipper Radio Debate Tonigh Message-ID: <00541.2845547700.4151@washofc.cpsr.org> Clipper Radio Debate Tonight Clipper Debate on CBS Radio Tonight The Clipper Chip will be debated on CBS National Radio on Thursday, March 3. Dorothy Denning, professor of computer science at Georgetown University, will argue is favor of the Clipper proposal Marc Rotenberg, CPSR Washington director, will argue against the Clipper proposal. The program will run on 150 CBS radio stations across the country between 8 pm and 9 pm EST. Internet users interested in more information about Clipper, should explore the CPSR Internet Library at CPSR.ORG. Clipper materials may be found at cpsr/privacy/crypto/clipper or by sending email to clipper-info at cpsr.org. From wex at media.mit.edu Thu Mar 3 11:30:37 1994 From: wex at media.mit.edu (Alan (Miburi-san) Wexelblat) Date: Thu, 3 Mar 94 11:30:37 PST Subject: YA semi-novice question Message-ID: <9403031930.AA19033@media.mit.edu> Can someone please tell me how 3-way calling would work under Clipper (or other encrypted phone system)? That is, I'm Alan talking to Betty. During the conversation Clive calls me and I want to "add" him so that we have a 3-way conversation. How do the key/session exchanges happen? --Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard Media Lab - Advanced Human Interface Group wex at media.mit.edu Voice: 617-258-9168 Page: 617-945-1842 na53607 at anon.penet.fi We are Chaos Boys. We are coming to a paradigm near you. From rarachel at prism.poly.edu Thu Mar 3 11:32:01 1994 From: rarachel at prism.poly.edu (Arsen Ray Arachelian) Date: Thu, 3 Mar 94 11:32:01 PST Subject: PC Expo, Mac World, Comdex, etc.. In-Reply-To: <9403031432.AA09033@jungle.meaddata.com> Message-ID: <9403031919.AA04499@prism.poly.edu> That internet guy who handed out the flyer was in NYC. at the last internet expo at Javitz. I don't know how much setting up a booth would cost, however, doing it that way is not as effective as simply handing out disks to every Joe Yuppie who goes out the door. People will visit whatever booths they are interested in. However someone handing out disks as to those who walk out is far more likely to get the disks accepted as they are freebies. Especially if the target is ignorant to crypto and Billary. :-) At some point he may try the hypertext thinggie, if it sparks some interest he may look and use the software. If he doesn't recycle the disks, he may pass them on to others... At some point some big cheeze will get his hands on it, and start worrying about how the WireTap act, Clipper and other issues may affect his company. (Don't forget to include a mention that we suspect that Clipper has other back doors beside the key-escrow and "Imagine how much damage a hacker who tripps over this back door can do to your COMPANY!!! The old FUD method...) Disks, in bulk are cheap and we can get them preformatted. I have (a long time ago) written a disk image duplicator program called DIM (BTW: I lost the sources to the most recent version, so I don't plan to update it anymore) but we can use it to mass duplicate disks. If we could get just four-five folks in every expo to chip in $20 do the duplication and distribution, we can have an effective awareness raising campaign.. MEI Microcenter sells preformatted (DOS) disks in bulk for $0.39 cents! Two $20 contributions can buy about 100 disks! That's quite a lot of people to wake up. The biggest problem is designing the software to be in the form of animation so it'll be watched. Plain text is nice too, but not everyone has the time to read. Most folks like TV and like to vegetate infornt of the TV. If we can have a self running animated demo of sorts (without having to install to the guys hard drive!) and still have enough room for neat stuff like PGP and SecureDrive and such, we have got it made. Another issue is printing flyers to go with the disks so we can get them interested in viewing/copying the disks. (Perhas include a program to duplicate the disks on the demo disk so that the DOS virgins can spread the disk...) Also, we need to have professional looking labels on the disks. I'd be weary of accepting a disk that has a cheap looking label. My 1st reaction would be "Is this a trojan???" Quality control and virus checking MUST be included in the package. Perhaps when the program 1st runs it can do a CRC of all the files on the disk to make sure that they have not been altered and tell the viewer of this... Once we have the collection of programs ready, I can ftp a disk image over to a few FTP sites so that other cypherpunks can join in on the fun. (Also a postscript file for the flyers and such...) 1st things 1st, I reccomend that Secure Drive 1.3x and PGP 2.3x and PGPShell are on the disk. Are there any other crypto packages that your average y yuppie, (possibly ODS virgin) would find useful? Remember that we need enough space on the disk to include clipper articles. We probably can't distribute the New York Times articles, so we'll have to write our own (and insert the FUD factor!!!) We need to write/use a freeware hypertext/hypermedia program to list, print, and extract those files. A small disk copy program can be included which would simply read in the whole disk, ask the viewer for a blank, formatted disk and write to it. We can use the user's hard drive for temp space (check the DOS TEMP variable 1st!) possibly XMS and EMS so that the user doesn't have to swap disks. Batch files are neat but may not always work right on every machine. Keep in mind that with the DOS wars we can't use any special features found in any DOS above 3.30 (DR DOS, IBM DOS, MS-DOS, etc.) We should use EGA/CGA for the demo, (check for EGA and use it!) and use highly compressed, or better yet vector images for the animation so that we don't fill up the disk quickly. We could use text mode graphics and ANSI like pictures, but we'd need our own display program as not all machines have ANSI installed, and we can't ask a DOS virgin to do that. We also don't want to modify the user's hard drive if we can help it as that would keep their fears down. From hughes at ah.com Thu Mar 3 12:16:22 1994 From: hughes at ah.com (Eric Hughes) Date: Thu, 3 Mar 94 12:16:22 PST Subject: Next Physical Gypherpunks meeting In-Reply-To: <199403031725.JAA21991@math.berkeley.edu> Message-ID: <9403032006.AA01702@ah.com> The next physical meeting will be Saturday, March 12, 12:00 noon PST. This is not an official announcement, but the time and date won't change. The title, for now, is Cypherpunks distributed meeting Politics, Strategies, and Action We're going to try to carry this one on the MBONE. Details are in the process of working themselves out. The EFF looks like it will be hosting one meeting at its offices in DC. There will be another in the Boston area, but I don't know the location yet. I haven't yet tried to jump-start a New York site. Colorado is interested, but needs to come up with a voice-over-IP site. If we do MBONE, we'll have a San Diego participant, but I don't know if he's going to be hosting a meeting or not. If you have a T1, a sparc, a speaker/microphone, a meeting room, and the desire to host a meeting, get in touch with me. We'll need some coordination. Eric From tcmay at netcom.com Thu Mar 3 12:29:01 1994 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 3 Mar 94 12:29:01 PST Subject: Having Meetings is the Most Important Issue In-Reply-To: <9403031943.AA01625@ah.com> Message-ID: <199403032026.MAA26066@mail.netcom.com> (I'm copying the main list as well, as I make some points about the general idea of having local gatherings. I suspect more detailed comments on the mechanics of arranging the meetings, establishing the links, etc., should best be kept on the cypherpunks-meeting-planners at ah.com list.) Thanks, Eric, for creating this sub-list. I don't plan to do most of my writing here, though. (Praise the stars.) I've been engaged in a dialog with Pat Farrell about planning the D.C. meeting, getting a place, etc. It sounds like the EFF venue may be the best solution. Let me very briefly make again some of the points I made to Pat and Eric: - having any meeting at all is much more important than whether it is linked partly or fully to the Bay Area meeting. Even if only 5 people show up, this is a start. (I agree that 5 people in attendance does not justify elaborate preparations, special conference rooms, etc. Hence, folks may want to rendezvous at a pizza place or similar. If attendance grows, you can then think of larger, better-connected places.) - most geographic areas are, for whatever reason, not having any meetings at all. This is really too bad, as the physical Cypherpunks meetings in Mountain View have really been important in "gluing together" many activities, and the 5 hours of discussions and debate amongst 20-40 people is very invigorating (few fall asleep, unusually). (If the Bay Area can draw as many as 50 people to a meeting--as our last two meetings have done--then I'm convinced the other major tech areas could draw at least 10 folks each. Maybe not at first, but maybe even than 10 as time goes on.) - the phone or MBONE or whatever link between the groups need not last for long...just long enough to establish a sense of connectivity and community and to discuss certain items of mutual interest. The last time we linked, last April, the main intersite link was for not much more than an hour, as I recall. (It worked well, with Derek Atkins, Mike Godwin, and others in Cambridge, and a bunch in the Northern Virginia area.) - even a brief call-in period would be nice. That is, we could allocate some time, say, 2 p.m. PST, for brief call-ins from folks who want to update the main group (Bay Area, by history and default) on what they're doing and get verbal feedback. Ten minutes per call, several calls perhaps. (Just an idea, perhaps for future meetings....just don't give Detweiler our number!) - regarding travel distances....I'm not too sympathetic. I drive 50 miles over dangerous mountain roads to get from Santa Cruz to the meeting site, Eric Hughes drives 40 miles from Berkeley, John Gilmore 40 miles from San Francisco, and others are as far away as Santa Rosa, about 60-70 miles north. And we do it each and every month! - so, I'm enthusiastic that finally the remote sites will begin to take off. Colorado seems already to be rolling along, and D.C. (which was planned by them to have a natural focus on lobbying and education of Congresscritters) may be reawakening from its slumber. - anybody heard anything from Austin lately? Cheers! --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^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway." From tcmay at netcom.com Thu Mar 3 12:33:58 1994 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 3 Mar 94 12:33:58 PST Subject: Minutes for Meetings? In-Reply-To: <9403031840.AA12486@glia.biostr.washington.edu> Message-ID: <199403032034.MAA26699@mail.netcom.com> > about this meeting you all are having. once you have had the meeting > will those of us that are un able to attend for one reason or > another, be able to find out what went on??? ie a sort of points > made at he meeting and other general info, in a post to this list. > i would love to be there. but i don't have access to the irc. > and my computer time is whenever i get the chance. > thanks > charles the monster maker Sometime minutes of meetings get posted, usually not. It's a lot of work to do this, both in the writing and in taking good notes during a meeting. I've written up minutes for two meetings, I recall, and Arthur Chandler did for a recent meeting. Not much reaction to either, except nit-picking of details by others, so there's not much incentive for any of us to bother. Being an anarchy, we have no officially assigned minutes takers. Another issue raised by some (to me, at least) is that formal minutes could be used against us by some agency or entity, or at least that some folks would be sufficiently worried about being quoted that they would feel less free to speak up on controversial issues. --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^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway." From cowen at glia.biostr.washington.edu Thu Mar 3 13:20:28 1994 From: cowen at glia.biostr.washington.edu (cowen at glia.biostr.washington.edu) Date: Thu, 3 Mar 94 13:20:28 PST Subject: No Subject Message-ID: <9403032131.AA14047@glia.biostr.washington.edu> re the use of clipper and other laws to imprison people for use of any code not the clipper.. why not just make jails everywhere and put everyone in one and then let out only those that are working for the gov't and other "good folks" and leave the rest of us in jail. if this happens. where i have no freedoms i'll just disappear. can't find me in the mountains and though i might spend my time in labs i have also spent time on lonely hill tops looking at nature and being away from it all free our lines, or someone else will enslave us charles the monster maker From mike at EGFABT.ORG Thu Mar 3 13:22:26 1994 From: mike at EGFABT.ORG (Mike Sherwood) Date: Thu, 3 Mar 94 13:22:26 PST Subject: Need info on Encyption book In-Reply-To: <9403031603.AA13543@toad.com> Message-ID: KEPERRIER at setpoint.com (Kent Perrier) writes: > Hi all, > > I have joined the "Small Computer Book Club" and in their "Top 10 Best > Sellers" is a book by Gilbert Held called _Top_Secret_ - Data Encryption > Techniques. Below is the text description: > > "Learn how to get people the information they need...without prying > eyes getting a look at it, too. This book/disk package introduces > you to techniques you can use to secure messages transmitted over internal > company networks or public electronic message systems. You'll learn how to > protect your communications with techiques for transposing characters in > text, replacing characters, with new ones, using arrays, and more. Plus, > your free disk features source code for the book's enciphering programs. > Softcover, with 3.5" disk. 218pp 1993." > > Has anyone heard of this book and is it with the $19.95 that they want > for it? If this is the one I'm thinking of, with source in basic, the algorithms used are mostly primitive things that have been cracked a long time ago. while it may be useful as a text for someone who isn't at all familiar with cryptography to start with, don't be fooled by claims that simple xor is a strong encryption algorithm. I dont think the book covers any serious encryption algorithms (des, idea, public key crypto, etc) but the most memorable thing about it was that it was funny that they believed what they were saying, so my memory may be faulty. -- Mike Sherwood internet: mike at EGFABT.ORG uucp: ...!sgiblab!egfabt!mike From banisar at washofc.cpsr.org Thu Mar 3 13:37:12 1994 From: banisar at washofc.cpsr.org (Dave Banisar) Date: Thu, 3 Mar 94 13:37:12 PST Subject: Clipper Petition Passes 40, Message-ID: <00541.2845556887.4178@washofc.cpsr.org> Clipper Petition Passes 40,000 =============================================== Computer Professionals for Social Responsibility (CPSR) March 3, 1994 Washington, DC The CPSR Internet Petition to oppose the Clipper Proposal has now passed 40,000 signatures. The petition has been signed by users at over 2,600 sites, including 1,100 companies and 800 colleges. For specific sites, MIT has the highest single vote tally, with over 600 messages. Messages continue to arrive at a rate of over 1,000 per day. To sign on to the letter, send a message to: Clipper.petition at cpsr.org with the text "I oppose Clipper" (no quotes) You will receive a return message confirming your vote. To obtain a copy of the petition, email a blank message to petition-info at cpsr.org For more information on Clipper, email clipper-info at cpsr.org. You will receive a copy of the Clipper FAQ. Please distribute and ask your friends and colleges to sign. Thanks for your help. ================================================ From sergey at delbruck.pharm.sunysb.edu Thu Mar 3 15:25:56 1994 From: sergey at delbruck.pharm.sunysb.edu (Sergey Goldgaber) Date: Thu, 3 Mar 94 15:25:56 PST Subject: Standard for Stenography? In-Reply-To: <9403030632.AA13653@hot.ee.lbl.gov> Message-ID: On Wed, 2 Mar 1994, Jef Poskanzer replied to Gary Jeffers: > I disagree with pretty much everything in your message, and since I'm the > one who opened the topic and who is writing the code, my opinion would seem > to count for quite a bit more than yours. I'm not going to repeat the > By the way, this discussion is an example of something I have labelled the > "silence is invisible" phenomenon. > Jef I think this "silence" has a good side. I've only read this list for a short time, but I already respect the oppinions of a few regulars. I don't expect every idea I post to the list to be completely new (quite the opposite, usually). The few replies I, and most other newbies, get are usually not very thought out, and have as many holes in them as the original suggestion. We debate back and forth for a short while, but seem to be generally ignored. The 'elders' on the list stay silent. Its when those respected few regulars speak that my ears prick up. I, for one, haven't read all the literature on the subject. So the oppinions of someone who has are greatly valued. If genuine intrest is shown in something you've proposed it tells you that you're on the right track. Input coming from the 'elders' is doubly important. It would be nice if constructive, intelligent criticism was offered on every post. Unfortuantely, newbies tend to get flamed more often than praised. In that regard, I believe that the "silence" from those who know better is usually good. If I recieved the sort of annoyed response that Gary Jeffers got from you on one of my first post, I don't think I would have stuck around for long. Perhaps some of the senior cypherpunks would prefer a moderated list where all newbie discussion is nipped in the bud. In that case, I suggest that they form the "eLyTe-cYpHeRpUnKs" list, and distribute it privately among themselves. I believe that fresh blood is essential for the development of the "cypherpunks"; so, this route is not recommended. Sergey From mech at eff.org Thu Mar 3 15:33:00 1994 From: mech at eff.org (Stanton McCandlish) Date: Thu, 3 Mar 94 15:33:00 PST Subject: Job Opening: EFF Seeking Executive Director Message-ID: <199403032331.SAA25304@eff.org> Position Announcement Executive Director THE ELECTRONIC FRONTIER FOUNDATION Summary: The Electronic Frontier Foundation (EFF) is seeking an inventive, entrepreneurial, public service-oriented chief executive with a strong background in operations. The Executive Director will expand the scope of the Foundation's activities by developing diverse projects, and will build organizational capacity by implementing sound management, fundraising and membership programs. The new Executive Director will work collaboratively with EFF's current Executive Director, who is moving over to become the Director of Policy in order to provide full time leadership to EFF's intensive and expanding public policy activities. EFF was started in 1990 by Mitchell Kapor, founder of Lotus Development Corporation, and John Perry Barlow, an author and lecturer interested in digital technology and society. Both founders remain active in the organization. EFF identifies significant issues related to information and communication technologies, and creates activities that seek to understand how they will affect society, and change the way that people think, work and interact. Current EFF activities focus on public policy, civil liberties, and public awareness. The new Executive Director will develop EFF projects which integrate the current array of policy initiatives, and will be designed to study and add value to the discourse around particular problems or ideas by bringing together information, resources and individuals outside of EFF who are already working in key areas. Other activities will be intended to promote strategic dialogue and education about specific issues, to encourage the development of new tools and paradigms, or to promote action for social, political, or economic change that expands EFF's current work related to: - information infrastructure; - the development and application of law; - evolution of new technology; and - protection of civil liberties. In addition, new projects will may address topics such as: - changes in social fabric and the meaning of community; - opportunities and effects on commerce/economics; and - international issues. Activities may include conducting research, creating forums to encourage discourse, inventing technical solutions, framing and reframing issues, convening working groups, promoting education and public awareness, persuading, organizing, lobbying and advocating, coalition building, dissemination and publications. About the Electronic Frontier Foundation: Programs EFF's current programs are designed to explore how civil liberties and the practices of democracy are affected in the unique domain created when individuals use electronic media to communicate. EFF has been involved in public interest litigation, providing on-line legal information for computer users, electronic conferencing and broad public education through print and electronic publications and communications activities. EFF has led the public debate on communications privacy, and supports efforts to force broad access to government information. As advancements in technology have stimulated investment in a national information and communications infrastructure, EFF has devised and promoted policy proposals, formed public interest/private sector coalitions, encouraged legislative reform, and organized grass roots support to ensure that the emerging national network is affordable, democratic and widely accessible. EFF also has explored issues related to privatization of the Internet, and information privacy. Management and Administration EFF presently has 8 full time professional staff, and a ten member Board of Directors who meet quarterly. Board members at EFF are committed, active and visible. EFF is a membership organization with a current enrollment of several thousand. The membership program has potential for involving thousands of technology users who are concerned about the future of communications networks, and want to participate in influencing the evolution of the networked world. Membership will be an increasingly important component of EFF's funding and advocacy base in coming years. In 1994, will have an annual budget of $1.6 million. Funds come from corporations, individual donors, grants, and membership. An important goal for the next few years will be to diversify EFF's funding base through a variety of fundraising methods, including major donor programs, membership, foundation grants, and earned income. Responsibilities of the Executive Director: o Management and Administration: The Executive Director sets the tone for a vital and positive organizational culture at EFF, orchestrates the activities of the staff, and ensures that EFF's strategic and operational planning, fiscal practices, and daily administration run smoothly and efficiently. o Resource Development: EFF is in the process of developing and expanding a comprehensive fundraising program Over the short term, the Executive Director will directly identify and secure funding from a variety of sources, including individuals, corporations and foundations. Over the longer term, the Executive Director will be responsible for planning and overseeing the implementation of a fundraising strategy that supports current activities and lays the groundwork for expansion into project areas defined by the Board and staff. o Membership Development and Member Relations: The Executive Director will develop and oversee the implementation of an expansion plan to increase EFF membership that integrates EFF's goals for fundraising, public awareness, and programs, and will work with staff to define and maintain a roster of member services and opportunities for activism. o Project Development and Management: The Executive Director will work with EFF's Board and staff to define, fund, and launch projects, then will oversee their smooth operations. o Board Development and Relations: The Executive Director serves as an ex officio member of the Board of Directors, and is responsible for leveraging the resources represented by the Board and other advisors to benefit the organization. o External Relations and Public Awareness The Executive Director will be in charge of planning and delegating responsibility for a cohesive program for external communications and public awareness that advances EFF through media placement, speaking engagements, and publications. Qualifications: The Executive Director must be skilled at organization building, program development and staff management, with at least ten years of proven experience in a responsible senior executive position. Candidates should enjoy seeing through a range of projects from initial vision through planning to implementation, and attending to the details of staffing, funding, project oversight and evaluation. Qualifications must include a track record of successful, creative fundraising and revenue development. This position is suitable for someone who enjoys engaging in lively exchange of ideas, but who also leans towards the pragmatic application of ideas to problem solving. Applicants will be asked to demonstrate an interest in EFF's work in law and public policy, civil liberties, computer and communications technology, opportunities for commercial development, and social evolution. Candidates must be able to represent the organization in public, so excellent communication skills--including the ability to write and speak persuasively to a range of audiences--are essential. This position requires a flexible and organized individual with advanced interpersonal skills, high energy level, problem solving approach, and the ability to generate and sustain multiple activities. Applicants should enjoy and be effective at negotiating collaborations and partnerships with other organizations and individuals. Diplomacy, political sensibility, and a sense of humor would come in handy. Candidates may come from a variety of backgrounds, including, but not limited to business management, academia, a research or policy institute, a senior fundraising position, public interest leadership, philanthropy, a think tank, or a research and development setting. We encourage individuals with eclectic backgrounds combined with a track record of accomplishments to apply. Experience managing a nonprofit organization is high capital, particularly if it includes development of effective fundraising programs, partnerships, and broad-based membership. Experience with budgeting and financial accountability is required. Because much of EFF's work is conducted electronically, candidates must have direct experience using electronic networks (should have a current email address), and should be aggressive in learning about and using computers and other forms of electronic communication. Compensation: Salary in the low six figures, commensurate with experience. Full benefits include health, disability and life insurance, pension, and vacation. How to apply: This position is located in Washington, DC. Deadline for applications is 31 March 1994. No phone calls please. To apply, send complete vitae, a brief writing sample and a compelling cover letter including salary history, to our executive recruiter: Lisa A. Breit & Associates 54 Rich Valley Road Wayland, Massachusetts 01778 Fax: 508-358-9110 You are encouraged to apply by email (ASCII only please). Address to: search at eff.org The Electronic Frontier Foundation is an equal opportunity employer. From eb at sr.hp.com Thu Mar 3 15:46:41 1994 From: eb at sr.hp.com (Eric Blossom) Date: Thu, 3 Mar 94 15:46:41 PST Subject: YA semi-novice question In-Reply-To: <9403031930.AA19033@media.mit.edu> Message-ID: <9403032345.AA12469@mwmax.sr.hp.com> Alan Wexelblat writes: Can someone please tell me how 3-way calling would work under Clipper (or other encrypted phone system)? That is, I'm Alan talking to Betty. During the conversation Clive calls me and I want to "add" him so that we have a 3-way conversation. How do the key/session exchanges happen? Basically it doesn't, unless you have extra hardware. This is the same problem that you have with ISDN phones. No extensions. If you were going to do it, somebody acts as a hub, call it H, and the other two users A and B connect to the hub. Note that A and B are not directly connected. A <----> H <----> B A and H negotiate a session key. B and H negotiate a session key. H acts as a digital mixer. H decrypts input from A using the A/H key and forwards it to B encrypted under B/H. H decrypts input from B using the B/H key and forwards it to A encrypted with the A/H session key. In the middle of all this (H) all components of the conversation are in the clear. They are mixed appropriately and sent out to the other participants encrypted under the respective session keys. Eric Blossom From jeremy at crl.com Thu Mar 3 15:59:22 1994 From: jeremy at crl.com (Jeremy Cooper) Date: Thu, 3 Mar 94 15:59:22 PST Subject: clipper + enaction = illegal alternate encryption In-Reply-To: <01H9GN16SBXU000676@UNCVX1.OIT.UNC.EDU> Message-ID: On Tue, 1 Mar 1994 VACCINIA at UNCVX1.OIT.UNC.EDU wrote: > Jeremy at crl.com writes: > > >Now why bother going through all the trouble to take out the chip? Why > >not just leave it in there and send RSA encrypted over your phone line? > >Once they _DO_ decrypt your clipper, they will still have another barrier. > >Leaving the chip in there does make it a little harder even for law > >enforcement doesn't it? > > This is the reason all other forms of encryption will be outlawed if the > clipper proposal goes through. I foresee at least two lines of enforcement. > The first is that one is held in contempt of court (assuming they can find > some charges to press) until you give them your key. How long can they keep > you in the slammer on a contempt charge? This option is already available > and seems to work, at least so far. I am talking about the clipper of today, not tommorow. When the government decides to outlaw all other schemes of encryption then we have a different story. I was responding to someone who was going out of their way (or said they would) to remove the chips from his/her equipment. _ . _ ___ _ . _ ===-|)/\\/|V|/\/\ (_)/_\|_|\_/(_)/_\|_| Stop by for an excursion into the-=== ===-|)||| | |\/\/ mud.crl.com 8888 (_) Virtual Bay Area! -=== From fhalper at pilot.njin.net Thu Mar 3 16:00:22 1994 From: fhalper at pilot.njin.net (Frederic Halper) Date: Thu, 3 Mar 94 16:00:22 PST Subject: RIPEM & MacPGP Message-ID: <9403040000.AA29955@pilot.njin.net> I have a friend that uses RIPEM and I use PGP if he sent me his RIPEM public key ther wouldn't be any problems between the 2 would there? Any opinions on which is the better program(seems like PGP is, RIPEM is still kinda raw) Reuben Halper PGP key available on request From sergey at delbruck.pharm.sunysb.edu Thu Mar 3 16:02:44 1994 From: sergey at delbruck.pharm.sunysb.edu (Sergey Goldgaber) Date: Thu, 3 Mar 94 16:02:44 PST Subject: Standard for Stenography? In-Reply-To: <199403031607.IAA08429@jobe.shell.portal.com> Message-ID: On Thu, 3 Mar 1994, Hal wrote: > I share Jef's disagreement with the spectacularly bad "neon sign" > steganography header, but I don't think Sergey's approach was correct > and I hope he does not feel the issue is closed yet. I never thought it was. Thank you for joining in the discussion, BTW. > Bill Stewart is IMO far more experienced and has far better > understanding of the issue than Sergey, who has been a list member for > only a few weeks and again IMO suggests a very naive > security-through-obscurity approach. I welcome any and all of Bill Stewart's comments on this issue. I have, since the beginning, noticed a distinct dislike of "security-through-obscurity" among the senior members of this and other similar lists/newsgroups. Many people preach this dislike. Most don't seem to understand its foundations fully; neverthelless, they consider it a closed issue and usually don't bother to explain why. I am glad that you are offering your insight on this, Hal. > Bill Stewart, Norm Hardy, and other list members who have more experience > and who have discussed these issues in the past will I think agree that the > correct approach is to separate the function of the stegonography program > to be a simple and clean insertion, and to have other components be > responsible for assuring that what is inserted is statistically indistin- > guishable from what is replaced. > This is the most elegant solution, I agree. > This notion that a "secret offset" will prevent the stego from being > discovered is highly naive IMO. The correct approach is to make it so > that the stego cannot be recognized even if the opponent knows where it is. That would be ideal, I agree. > Adding offsets is like attempting to "improve" regular RSA by putting a > secret amount of noise padding at the front (not of a stego file, but of > an openly encrypted file). This is unnecessary if you trust your encryption, > and if you don't trust it then this approach should not make you trust it. I do not trust my encryption to be foolproof. If I believed that adding noise at the front of the file would help, I would do it. I still wouldn't trust it, but I would feel safer with every new security-through-obscurity layer. > Similarly, if your stego is so weak that knowing where it is in the file will > allow the opponent to detect it, adding a random offset should not make you > feel secure. The correct approach is to have statistical identity between > what you are inserting and what you are removing. The stego program itself > should then be as simple as possible. This is my defense of security-through-obscurity: Security-through-obscurity adds layers upon layers of potential effort needed by one's opponents to get at whatever it is that you are obscuring. A good analogy would be the length of one's secret key. A one bit key, you would agree, is not very effective. The bits in the key, the more effort your opponent would have to expend in brute-force analysis. Similarly, the more layers of obscurity one has, the more effort your opponent would have to expend in bypassing/guessing your methods. I have often heard it said that one should always assume that one's opponent knows everything except one's secret key. To me, this makes no sense! If your opponent is good enough and determined enough to get by all the layers of obscurity you may have put up, than its just one more step to getting your secret key. You have stated that my oppinion is naive. Please enlighten me. > Now I will add my own little moral lesson, in the spirit of Tim and Jef. > Sometimes when these discussions are re-hashed, old-timers are too busy or > bored to join in. New list members express naive views that are not vigor- > ously refuted. This is OK, but then some other new member takes these views > to represent list consensus. > So the views of these naive new members should be "vigorously refuted" (ie. flamed) in the intrest of other naive new members? Have you considered changing that to "constructively criticised"? > I think it is great that Jef is working on a steganography implementation, That it is! > but IMO the notion of "random offsets" is so fundamentally misguided that I > hope he will reconsider. > I dissagree. In a perfect world, with perfect encryption and perfect steganography "random offsets" may be superfluous. As it stands now, we need all the obscurity we can get. > Hal Finney > hfinney at shell.portal.com > Sergey From eileen at photon.poly.edu Thu Mar 3 13:16:30 1994 From: eileen at photon.poly.edu (Eileen Tronolone) Date: Thu, 3 Mar 1994 16:16:30 -0500 (EST) Subject: PC Expo, Mac World, Comdex, etc... (fwd) In-Reply-To: <9403031858.AA04241@prism.poly.edu> from "Arsen Ray Arachelian" at Mar 3, 94 01:58:17 pm Message-ID: <9403032116.AA26345@photon.poly.edu> Also Sprach Arsen Ray Arachelian: > > >I LOVE IT! LET'S DO IT!!!!!!! > > Disks are dirt cheap. $0.39 per disk in 150 packs. > If we could get a few people to chip in $20, we can > buy quite a lot, over a hundred. The hard part is > duplicating them. (BTW: those disks come preformatted > for DOS. This is from MEI Microcenter.. 800-634-3478) What we need are people to take a portion of them and format them for Unix and Macintosh and any other versions of PGP that are there. Can the Unix version of PGP fit on a single disk? Also, we have to have the sort of people involved who won't just take the disks and walk with them. > The hardest part is printing labels that look > professional enough to prevent most of the yuppies > from being suspicious about a few kids handing out > disks. Piece of cake. My lover has his own desktop publishing buisness. With an HPLJ4 at home. No problem. We can make professional-looking handouts too. (We'll have to wear suits too in order to > not get them scared off... Sad, but effective..) You have to wear a suit (or at least reasonably dressy clothing) to be taken seriously at any Expo at all. One concern I have - did Zimmerman sell out to RSA yet? He was being sued as I recall, and the latest info I have is that he watered down version 2.3 to shut them up temporarily. What is the latest on that, and is 2.3 still the latest version of PGP? -- Eileen Tronolone | internet: eileen at photon.poly.edu | EARTH System Administrator | usenet: redsonja at olias.linet.org | JUICE! Polytechnic University | voice: (718) 260-3846 | -- RTF Brooklyn, NY 11201 | Self possession is 9/10 of the law.| From tcmay at netcom.com Thu Mar 3 16:24:54 1994 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 3 Mar 94 16:24:54 PST Subject: Newbies on the List In-Reply-To: Message-ID: <199403040025.QAA03656@mail.netcom.com> Sergey Goldgaber writes: (quoting Jef P.) > > By the way, this discussion is an example of something I have labelled the > > "silence is invisible" phenomenon. > > > Jef > > I think this "silence" has a good side. I've only read this list > for a short time, but I already respect the oppinions of a few regulars. > I don't expect every idea I post to the list to be completely new (quite > the opposite, usually). The few replies I, and most other newbies, get are > usually not very thought out, and have as many holes in them as the original > suggestion. We debate back and forth for a short while, but seem to be > generally ignored. The 'elders' on the list stay silent. I want to take this opportunity to say that I do _not_ disparage the enthusiasm of newcomers like Sergey G. and Gary Jeffers. The "problem," to the extent theere is one, is that newcomers frequently have a bunch of things they really want to say (which is good), but lack the context to see how their points fit in with what's possible to do, what's already been done, and what is naive (which is bad). And after a while, having said what they wanted to say their posts taper off. (A few of us are still blabbing incessantly a year and a half after joining the list. Hey, it beats working for a living.) Gary sent me some e-mail inquiring about the archive of past postings--regrettably, my current understanding is that the toad.com archives are not (yet?) available for browsing and retrieval of past posts. Maybe someday. Chronological age has little to do with being an "old-timer" or a "newcomer." For example, Sameer Parekh is but a freshman at Berkeley, but he is surely and old-timer. Stick around for several months on the list, and you'll be an old-timer. > Its when those respected few regulars speak that my ears prick up. I, for > one, haven't read all the literature on the subject. So the oppinions of > someone who has are greatly valued. If genuine intrest is shown in > something you've proposed it tells you that you're on the right track. > Input coming from the 'elders' is doubly important. Here are some things newcomers can do: 1. Immediately run out and buy a copy of Bruce Schneier's "Applied Cryptography." Do this before doing anything else. It covers so many of the areas we deal with that to not have it handy is a waste of your and our time. The book is pricey, at $45, but go out and mow some lawns or donate some blood if you can't afford it. You can't afford to be on this list without it (or some equivalent texts). 2. Read the various articles on crypto that are mentioned here fairly often (and which will be in the FAQ). 3. Speaking of FAQs, some good ones already exist in sci.crypt. The "Crypt Cabal" puts out a good one every month or so. Others exist. Read them. 4. In general, read sci.crypt and talk.politics.crypto. And comp.org.eff.talk. And maybe the Clipper and PGP groups. 5. Speaking of PGP, some good stuff in the documentation for PGP. 6. Finally, hold off on posting for at least a few weeks after joining the list. Too many folks "shoot their wad" by hyperenthusiastically expounding on a basically flawed idea too early in their history on the list. > It would be nice if constructive, intelligent criticism was offered on > every post. Unfortuantely, newbies tend to get flamed more often than > praised. In that regard, I believe that the "silence" from those who > know better is usually good. The problem is that about 700-800 people are on this list--though I find this hard to believe...and certainly many of them must be deleting nearly everything unread. If each "Has anyone ever heard of foo?" post was carefully replied to.... > If I recieved the sort of annoyed response that Gary Jeffers got from you > on one of my first post, I don't think I would have stuck around for long. > Perhaps some of the senior cypherpunks would prefer a moderated list > where all newbie discussion is nipped in the bud. In that case, I > suggest that they form the "eLyTe-cYpHeRpUnKs" list, and distribute it > privately among themselves. I believe that fresh blood is essential for > the development of the "cypherpunks"; so, this route is not recommended. I think the response Gary got were actually quite polite, especially the ones that stated the fact that his views were likely wrong and should not, by silent assent, be taken as the consensus of the list. No one called him names or told him to get off the list. Even my comments on "stenography" were not all that harsh, in my opinion. (And we've since exchanged e-mail.) I don't think any of us want to see newbies "nipped in the bud." But we certainly all want to see newbies brought up to speed. A moderated list is not being sought by anyone I know, at least not for the Cyperpunks list (though Perry Metzger has proposed his own moderated list on crypto issues). Many newcomers to crypto have become serious contributors in short order. Likewise, many old-timers (like David Sternlight) have never reached the point of being a "contributor," so draw your own conclusions. --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^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway." From tcmay at netcom.com Thu Mar 3 16:32:11 1994 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 3 Mar 94 16:32:11 PST Subject: Having Meetings is the Most Important Issue Message-ID: <199403040032.QAA07000@mail.netcom.com> (I sent this off several hours ago and it still hasn't appeared at my site, so I'm sending it again.) From wcs at anchor.ho.att.com Thu Mar 3 16:40:56 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Thu, 3 Mar 94 16:40:56 PST Subject: Standard for Stenography? Message-ID: <9403040039.AA14605@anchor.ho.att.com> Hal Finney writes: > Bill Stewart, Norm Hardy, and other list members who have more experience > and who have discussed these issues in the past will I think agree that the > correct approach is to separate the function of the steganography program > to be a simple and clean insertion, and to have other components be > responsible for assuring that what is inserted is statistically indistin- > guishable from what is replaced. It's somewhat of a tradeoff, though, since you really *do* need to have the system be convenient enough to use and standardized enough that everybody will use it. My own programming approaches tend to solve this through reasonably clean programs connected by shell scripts or C frontends grossly infected with Creeping Featurism; the faults of this widely-used approach are well-known (:-). The important decisions, in my opinion, are whether to have an explicit stego program or something that appears to be more general-purpose, and whether to make sure the cyphertext you're hiding looks random. If you're going to have an a program that admits to doing stego, the main risks in having it do a fancy job are detectability and portability, and it sounds like Jef's handling that well. And Xenon's ranting has helped encourage someone to release Stealth-PGP:-) so that's good. Carl Ellison's "tran" program takes an interesting approach for data scrambling - it takes a simple checksum of the first N bytes of the data, which is order-invariant (I think it was a byte-wise XOR?) and uses it as a random-number seed for scrambling blocks of data; it's easy to reverse because the checksum is the same after scrambling. (I forget if the scrambling is also a self-inverse or not, which lets you use one program for both directions; wouldn't be too hard to do.) That might be a clean approach if you're still looking for a satisfactory scrambling method, though you could also do bitwise things instead of bytesized, since you have to split the text out into bits for stego anyway. Bill From wcs at anchor.ho.att.com Thu Mar 3 16:50:48 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Thu, 3 Mar 94 16:50:48 PST Subject: Need info on Encyption book Message-ID: <9403040050.AA14673@anchor.ho.att.com> > >Has anyone heard of this book [_Top_Secret_ - Data Encryption Techniques] and > >is it with the $19.95 that they want for it? > > Only if you have a pressing and immediate need for a doorstop, or need > special help solving the "Cryptoquotes" in your local paper. If I'm not mixing it up with a similar book I saw in the store, I wouldn't be *quite* that negative; I'll comment on the two together. They're not academic books, and if you're using PGP there's not much you'll gain from them. The big weaknesses I saw were: - not mentioning that the techniques discussed are way outdated and easily broken by professionals (they tend to say this for the simpler methods, just not for the more complex ones.) - not discussing the *existence* of mathematical crypto techniques; it's ok not to go into details, depending on the scope of the book, but there should at least be pointers to the topics. One interesting feature of the books I looked at was that one of them came with a floppy disk with code on it. I didn't notice anything on the first few pages about "Not for export" or a mention that the government treats crypto as munitions that need special permits to export - I assume the authors are unaware of this, or that the NSA doesn't really care about this level of crypto any more than they care about rot-13 being exported :-) - but you'd think the publishers would notice.... Bill From smb at research.att.com Thu Mar 3 17:00:14 1994 From: smb at research.att.com (smb at research.att.com) Date: Thu, 3 Mar 94 17:00:14 PST Subject: Standard for Stenography? Message-ID: <9403040100.AA21896@toad.com> I welcome any and all of Bill Stewart's comments on this issue. I have, since the beginning, noticed a distinct dislike of "security-through-obscurity" among the senior members of this and other similar lists/newsgroups. Many people preach this dislike. Most don't seem to understand its foundations fully; neverthelless, they consider it a closed issue and usually don't bother to explain why. Obscurity is certainly a help. Attacking an unknown system is very much harder than attacking a known one. And everyone in the business knows that. However -- in the real world, as opposed to an academic exercise, you cannot keep an algorithm secret forever. Partners will betray you, spies will steal copies, enemies will capture them. Do you trust everyone on cypherpunks? Should you? If your algorithm is not strong enough to withstand an attack by an enemy who has captured it, you're in trouble. And although you can replace the algorithm, it's a lot harder than changing keys -- good cryptoalgorithms take a *lot* of work, and the details often matter a lot. Besides, your old traffic will then be readable. Security through obscurity is more than a buzzword. It's a necessity in this business. --Steve Bellovin From wcs at anchor.ho.att.com Thu Mar 3 17:10:21 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Thu, 3 Mar 94 17:10:21 PST Subject: Standard for Steganography Message-ID: <9403040109.AA14831@anchor.ho.att.com> Jef Poskanzer writes: > The problem is the length field - you've got to have it, and it's > recognizeable because it begins with a run of 0s. [several hiding approaches.] Actually, you don't really need it, at least for PGP. PGP messages keep track of how much real stuff the message has, and ought to be able to do the right thing if there's extra stuff at the end; I'd guess that Stealth-PGP can do the same. I realize PGP isn't the only thing people will want to hide, but most things need hiding have enough structure to them thatpadding wiht garbage at the end is no problem. On the other hand, if you do have a length field, you do have to do something reasonable with it, and just putting it at the beginning makes it difficult to do other stuff with the stego program, like inserting text bitplanes into a picture.... Bill From ebrandt at jarthur.cs.hmc.edu Thu Mar 3 17:18:22 1994 From: ebrandt at jarthur.cs.hmc.edu (Eli Brandt) Date: Thu, 3 Mar 94 17:18:22 PST Subject: Standard for Stenography? In-Reply-To: <9403031710.AA14345@hot.ee.lbl.gov>; from "Jef Poskanzer" at Mar 3, 94 9:10 am Message-ID: <9403040118.AA22060@toad.com> Jef said: > My solution is to store the file's bits in a specified > pseudorandom permutation of the image's available bit positions. > It's kind of like the frequency hopping of spread spectrum radio. > This hides the length field very thoroughly. It also happens to > hide anything else recognizable about the original file. What you're doing can be written as steg(permute(pkey, )) Note that the permutation is really a second layer of encryption, a bit transposition cipher. The obscurity-only approach of "#define PERMUTE_KEY 0xdeadbeef" would be pretty weak. If an opponent is to be unable to detect images with embedded steganography (stegnant images?) by looking for the length field, the permutation needs to be strong: large keyspace, strong PRNG, etc. Granted, it doesn't need to be as strong as the message cipher, because the plaintext is lousy (mostly encrypted), the payoff to the opponent on breaking it is less, and the target pool is much larger. But you do have the hassles of a second cipher -- at the very least, you need to distribute keys. Probably *private* keys, with their attendant distribution explosion. I think the Right Thing to Do is to require that the length indication or eof marker be inside the strong encryption (Stealth PGP or what have you). Now, we may not want to do that. First, we may have good reasons to preserve modularity by doing the length in the stegger. If the encryption is stealthy, we can get away with *only re-encrypting the length information*. Big win speedwise. If the encryption is not stealthy, it seems to me that we need a PGP headerstripper, not a permuter. The bulk of the file, after all, *is* stealthy. Tangentially, why choose bit permutation for your second-level encryption? There are plenty of schemes that will be a lot faster than doing all that bitmangling. Eli ebrandt at jarthur.claremont.edu From cfrye at ciis.mitre.org Thu Mar 3 14:21:12 1994 From: cfrye at ciis.mitre.org (Curtis D. Frye) Date: Thu, 3 Mar 94 17:21:12 EST Subject: spooks Message-ID: <9403032221.AA15217@ciis.mitre.org> >If there are any spooks on this list aren't they required by law to say that >they are if somoeon asked if anyone on on th list was employed by CIA, DOD, FBI >or NSA? Hardly. The intel folks don't have to say diddley and might be prohibited by law from saying anything, the FBI probably doesn't need to since there's no criminal investigation under way (or is there?), and why in hell would DOD employees need to reveal their presence? We encourage open, anonymous From wcs at anchor.ho.att.com Thu Mar 3 17:34:46 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Thu, 3 Mar 94 17:34:46 PST Subject: Standard for Stenography? Message-ID: <9403040134.AA15184@anchor.ho.att.com> Sergey writes: > I have often heard it said that one should always assume that one's > opponent knows everything except one's secret key. To me, this makes no > sense! If your opponent is good enough and determined enough to get by > all the layers of obscurity you may have put up, than its just one more > step to getting your secret key. If your cryptography methods are good enough to withstand an opponent who has full documentation of your algorithms and methods, lots of funds, and everything except your keys, then you don't need to waste your time with all the other stuff. And if you can't protect a couple of keys, it doesn't really matter how much other security you have. On the other hand, steganography is almost by definition an obscurity technique, and while security-by-obscurity is a naive waste of time, obscurity-by-obscurity is hard to argue against real clearly :-) On the other hand, if your cyphertext looks like random bits anyway, it doesn't take a lot to make them invisible. The real need is to make your data look like Somebody Else's Problem.... Bill From jef at ee.lbl.gov Thu Mar 3 17:54:14 1994 From: jef at ee.lbl.gov (Jef Poskanzer) Date: Thu, 3 Mar 94 17:54:14 PST Subject: Standard for Stenography? Message-ID: <9403040154.AA16047@hot.ee.lbl.gov> Eli makes a reasonable case for leaving out the length field altogether. The desteg program would produce a file of width*height bits, and it would be up to the next layer to produce text from that. However, I'm not sure it's a *compelling* case. If adding the length doesn't actually hurt security, I'm inclined to keep it. >Tangentially, why choose bit permutation for your second-level >encryption? There are plenty of schemes that will be a lot faster >than doing all that bitmangling. Slowness is not necessarily bad - it also makes it harder for attackers to search through large numbers of images for ones with hidden data. But the main thing that the permutation gives you is that it spreads out the data bits among unmodified bits, making statistical tests harder. For a 1000 byte message in a 640x480 image, only 2% of the bits will be changed. If that 2% was all jammed into the first 80000 pixels of the file, it might be detectable; if it's spread evenly throughout the file, it's probably safer. --- Jef From sergey at delbruck.pharm.sunysb.edu Thu Mar 3 18:25:03 1994 From: sergey at delbruck.pharm.sunysb.edu (Sergey Goldgaber) Date: Thu, 3 Mar 94 18:25:03 PST Subject: Newbies on the List In-Reply-To: <199403040025.QAA03656@mail.netcom.com> Message-ID: On Thu, 3 Mar 1994, Timothy C. May wrote: > The "problem," to the extent theere is one, is that newcomers frequently > have a bunch of things they really want to say (which is good), but > lack the context to see how their points fit in with what's possible > to do, what's already been done, and what is naive (which is bad). And > after a while, having said what they wanted to say their posts taper > off. > Flaming is no solution to this "problem". In fact, this "problem" can, with proper guidance, lead to an enriching growing experience (forgive me for sounding camp). Most very "naive" newbies usually get responses that are anything but helpfull; unless their queries are phrased in a submissive, almost servile tone. At the very least, a certain humility is expected. This pattern is by no means limited to this list, or even the whole Internet. It is the "presumptuous" _and_ "naive" newbies that get flamed the most. They are the safest targets. It may be wise to realize that even the _most_ presumptuous and _most_ naive newbie has potential for enriching the group tremendously. In these cases, flaming usually turns out to be even more naive than whatever it was the newbie has/hasn't done to deserve the flame. The senior, as many have pointed out, should know better. > Gary sent me some e-mail inquiring about the archive of past > postings--regrettably, my current understanding is that the toad.com > archives are not (yet?) available for browsing and retrieval of past > posts. Maybe someday. > A great pity. I suspect that some the contents of the archive may be far more educational than even the fabled "Applied Cryptography". :) > Chronological age has little to do with being an "old-timer" or a > "newcomer." Thank you for pointing that out. However, it was not my intention to imply age differences with the terms "newbie", "elder", or "senior". Nor was it my intention to put anyone on the defensive. > For example, Sameer Parekh is but a freshman at Berkeley, > but he is surely and old-timer. Stick around for several months on the > list, and you'll be an old-timer. > > 1. Immediately run out and buy a copy of Bruce Schneier's "Applied > Cryptography." Do this before doing anything else. It covers so many > of the areas we deal with that to not have it handy is a waste of your > and our time. The book is pricey, at $45, but go out and mow some > lawns or donate some blood if you can't afford it. You can't afford to > be on this list without it (or some equivalent texts). > For some, actual "live" conversations hold more in the way of being educational than any textbook, no matter how well written. Your suggestion is well taken, nonetheless. > 2. Read the various articles on crypto that are mentioned here fairly > often (and which will be in the FAQ). > 3. Speaking of FAQs, some good ones already exist in sci.crypt. The > "Crypt Cabal" puts out a good one every month or so. Others exist. > Read them. > 4. In general, read sci.crypt and talk.politics.crypto. And > comp.org.eff.talk. And maybe the Clipper and PGP groups. > 5. Speaking of PGP, some good stuff in the documentation for PGP. > 6. Finally, hold off on posting for at least a few weeks after joining > the list. Too many folks "shoot their wad" by hyperenthusiastically > expounding on a basically flawed idea too early in their history on > the list. It would be ideal if every "newbie" had the time/energy to do all these before posting. It may minimize the chances of "reinventing the wheel". Luckily, I believe the "cypherpunks" list is a fine way to learn a little about cryptography. Not only by reading, but by participating as well. It may not be as effective as actually managing to read and understand a 400+ page reference book on cryptography. Nor would I urge any prospective cryptographers to to take this as their only route of study. But it may be a good (dare I say "fun"?) introduction. > The problem is that about 700-800 people are on this list--though I > find this hard to believe... That is a problem. There aren't enough! 700 dabbling cypherbabies and maybe a dozen serious cypherpunks are less than a handfull. Perhaps the list needs to be subdivided (or renamed to something more boring :) But I don't think we need to worry about there being too many of us. > and certainly many of them must be > deleting nearly everything unread. If each "Has anyone ever heard of > foo?" post was carefully replied to.... I do not seriously expect a constructive, intelligent reply to every post. I was meerly listing it as another ideal. Constructive replys need not be public, BTW. Especially if the topic(s) has been thoroughly covered previously. > I think the response Gary got were actually quite polite, especially > the ones that stated the fact that his views were likely wrong and > should not, by silent assent, be taken as the consensus of the list. > No one called him names or told him to get off the list. Even my > comments on "stenography" were not all that harsh, in my opinion. Yes. And, names would be comparatively mild to trashing his account (something which many readers are very capable if not willing to do). And that would be mild compared to sending him a mail bomb. In any case, the responses he recieved were mostly less than helpfull. I certainly expected more from certain senior members of this list. > I don't think any of us want to see newbies "nipped in the bud." But > we certainly all want to see newbies brought up to speed. Flaming them(us) does not usually "get them up to speed". > Many newcomers to crypto have become serious contributors in short > order. Likewise, many old-timers (like David Sternlight) have never > reached the point of being a "contributor," so draw your own > conclusions. I hope I'll have the time to become a serious contributor (seriously :). I certainly have the intrest. > --Tim May Sergey From exabyte!smtplink!mikej at uunet.UU.NET Thu Mar 3 18:44:04 1994 From: exabyte!smtplink!mikej at uunet.UU.NET (exabyte!smtplink!mikej at uunet.UU.NET) Date: Thu, 3 Mar 94 18:44:04 PST Subject: Mail server for crypto files on csn.org? Message-ID: <9402037627.AA762722747@smtplink.exabyte.com> -----BEGIN PGP SIGNED MESSAGE----- Problem: the time-varying directory name changes too fast for reliable mail server access to the crypto software on csn.org:/mpj/ for those who don't have live ftp access, but are legally qualified to get that software under the ITAR. It IS possible, but you have to get README.MPJ then request the software right away (before I log in to csn.org to check my mail the next time -- usually one to three times a day whenever I feel like it). Proposed solution #1: change the ITAR. Unfortunately, I can't do this unilaterally. Write your Congressional Representative about changing the ITAR. Proposed solution #2: set up a "secure" mail server on csn.org itself. My idea is to have a filter program scan incoming mail for requests for crypto programs. The request would have to contain a statement that the requestor won't break the law, as well as the names of the files requested. If the mail scanning program is able to detect a valid destination for crypto software, it could then mail uuencoded or radix-64 encoded copies of the software requested in the message. Here is where I confess some ignorance and ask for help: How do I do this? Could someone send me source code for any automatic mail handling programs they have written for a Sun host, or perhaps point me at some good documentation? I could probably muddle through this in time, but I'm not to proud to accept a head start. ___________________________________________________________ |\ /| | | | | \/ |o| | Michael Paul Johnson Colorado Catacombs BBS 303-938-9654 | | | | / _ | mpj at csn.org ftp csn.org \mpj\README.MPJ for access info.| | |||/ /_\ | aka mpjohnso at nyx.cs.du.edu mikej at exabyte.com | | |||\ ( | m.p.johnson at ieee.org CIS 71331,2332 VPGP key by finger | | ||| \ \_/ |___________________________________________________________| -----BEGIN PGP SIGNATURE----- Version: 2.4 iQCVAgUBLXYgQj9nBjyFM+vFAQFccQQAo/zjyDzpsH0Ik1pGI6D+0ST8M7I84TYe /O9rqZRc4HpX5N4htPML9dm6+RrJoNzm9vXvxqhdptAB1nxzkRJgnVpTtH9nhFAM 6hX5k52H2t4Htq5diuAtk31CQG8t0GzA7iJ1qVhqwMG/pgoddRoX+cyVd5rdzX9j TN5+NZYugbU= =nSyZ -----END PGP SIGNATURE----- From sergey at delbruck.pharm.sunysb.edu Thu Mar 3 19:01:22 1994 From: sergey at delbruck.pharm.sunysb.edu (Sergey Goldgaber) Date: Thu, 3 Mar 94 19:01:22 PST Subject: Standard for Stenography? In-Reply-To: <9403040134.AA15184@anchor.ho.att.com> Message-ID: On Thu, 3 Mar 1994 wcs at anchor.ho.att.com wrote: > Sergey writes: > > I have often heard it said that one should always assume that one's > > opponent knows everything except one's secret key. To me, this makes no > > sense! If your opponent is good enough and determined enough to get by > > all the layers of obscurity you may have put up, than its just one more > > step to getting your secret key. > > If your cryptography methods are good enough to withstand an > opponent who has full documentation of your algorithms and methods, > lots of funds, and everything except your keys, then you don't > need to waste your time with all the other stuff. And if you can't > protect a couple of keys, it doesn't really matter how much other > security you have. I have never heard a serious, reputable claim about the unbreakablity of an algorithm. Any newbie that dares to pretend otherwise is promptly referred to the example of the NSA. The biggest single purchaser of computer hardware, and employer of mathematicians. Dozens of years ahead of public research and all classified. The point is, that in the real world, we'll never know if our algorithms are "good enough to withstand an opponent who has full documentation of your algorithms and methods lots of funds, and everything except your keys." This opponent need not be the NSA, per se, BTW. With "lots of funds" they may have access to at least some of the NSA's findings. And, who knows, the NSA may regularly hire its services out to the highest bidder. You may trust your encryption alone, but if it ever comes to that, I'll hide any sensitive information I may have every way I can. > security-by-obscurity is a naive waste of time, I still don't see why. > obscurity-by-obscurity is hard to argue against real clearly :-) > On the other hand, if your cyphertext looks like random bits anyway, > it doesn't take a lot to make them invisible. It certainly lookss like it takes a lot! The Mimic function seems, to me, to be the only effective practical steganography application. Most of the rest of the informed members of this group seem to be debating the relative visibility/invisibility of their respective systems. > The real need is to make your data look like Somebody Else's Problem.... Here's to somebody elese's problems! > Bill > Sergey From sergey at delbruck.pharm.sunysb.edu Thu Mar 3 19:14:29 1994 From: sergey at delbruck.pharm.sunysb.edu (Sergey Goldgaber) Date: Thu, 3 Mar 94 19:14:29 PST Subject: Standard for Steganography In-Reply-To: <9403040109.AA14831@anchor.ho.att.com> Message-ID: On Thu, 3 Mar 1994 wcs at anchor.ho.att.com wrote: > Jef Poskanzer writes: > > The problem is the length field - you've got to have it, and it's > > recognizeable because it begins with a run of 0s. [several hiding > > approaches.] > Actually, you don't really need it, at least for PGP. PGP messages keep > track of how much real stuff the message has, and ought to be able to > do the right thing if there's extra stuff at the end; I'd guess that > Stealth-PGP can do the same. I realize PGP isn't the only thing people > will want to hide, but most things need hiding have enough structure > to them thatpadding wiht garbage at the end is no problem. > > On the other hand, if you do have a length field, you do have to > do something reasonable with it, and just putting it at the beginning > makes it difficult to do other stuff with the stego program, > like inserting text bitplanes into a picture.... > > Bill > Sorry to have to bring this up, but... As some of the newbies have pointed out, in previous messages on this thread: The length field, or any standard-length header scattered (standardly :) through the beginning of the file will cost one no loss in security if it is encrypted. The encryption could easily be standardized via a public-key based algorithm like PGP. The stego-program could be kept simple by meerly having it call PGP to do the header-encryption work. Sergey From rishab at dxm.ernet.in Thu Mar 3 21:55:47 1994 From: rishab at dxm.ernet.in (rishab at dxm.ernet.in) Date: Thu, 3 Mar 94 21:55:47 PST Subject: Right to vote Message-ID: There has been some discussion over the last week about what is a 'right', and whether the right to vote is a right or not, as the basis is a ruling by the Supreme Court. However there seems to be strong support for the right to vote in several amendments. Apart from the lenthy 12th amendment describing the process of electing Presidents and Vice-Presidents, there are: Amendment XV (1870) Section 1. THE RIGHT OF CITIZENS OF THE UNITED STATES TO VOTE shall not be denied or abridged by the United States or by any state on account of race, color, or previous condition of servitude. Amendment XIX (1920) THE RIGHT OF CITIZENS OF THE UNITED STATES TO VOTE shall not be denied or abridged by the United States or by any state on account of sex. Amendment XXIV (1964) Section 1. THE RIGHT OF CITIZENS OF THE UNITED STATES TO VOTE in any primary or other election for President or Vice President, for electors for President or Vice President, or for Senator or Representative in Congress, shall not be denied or abridged by the United States or any state by reason of failure to pay any poll tax or other tax. Amendment XXVI (1971) Section 1. THE RIGHT OF CITIZENS OF THE UNITED STATES, who are 18 years of age or older, TO VOTE, shall not be denied or abridged by the United States or any state on account of age. Note: ele tronic versions of the US and other constitutions are available through gopher, or ftp at wiretap.spies.com, Gov/World. Many international treaties and other UN and government documents are under the Gov/ directory. ----------------------------------------------------------------------- Rishab Aiyer Ghosh "What is civilisation rishab at doe.ernet.in, rishab at dxm.ernet.in but a ribonucleic Voicemail +91 11 3760335; Vox/Fax/Data 6853410 hangover?" H-34C Saket New Delhi 110017 INDIA ----------------------------------------------------------------------- From rarachel at prism.poly.edu Thu Mar 3 22:28:45 1994 From: rarachel at prism.poly.edu (Arsen Ray Arachelian) Date: Thu, 3 Mar 94 22:28:45 PST Subject: PC Expo, Mac World, Comdex, etc.. In-Reply-To: <9403040535.AA21606@ nextsrv.cas.muohio.EDU > Message-ID: <9403040616.AA00778@prism.poly.edu> Absolutely. A Mac version would be great. (My main machine is a Mac but keep in mind that unless we target Mac World Expo, 99% of the atendees will be PC folks.) Actually if you do your stack any time soon, please send it my way so I can "port" it to the PC somehow. (Probably, just by grabbing pictures and stuff...) BTW: Speaking of vapor ware, I'm making some progress with the SecureDrive like thing for the Mac.... I feel like I'm walking through molasses when reading about the extents file in Inside Mac, but I'll eventually have it sink in my brain and get something to work. (Incase you aren't familiar with SecureDrive, it's a device driver that automatically encrypts a whole partition.) The driver I'm working on will use a file to store the encrypted volume on. Once the drive is mounted anything stored on it is secured. I'm going to leave the crypto code open. I'll probably provide a module for DES and IDEA, and leave some open specs so others can write their own modules and stuff. I'd encourage others to use these modules in other software that they'll write... They're basically stand alone code. I haven't decided if the crypt modules will be just code resources or INITs with Gestalt selectors installed. Depends on how feasable the stuff is with drivers... Anyhow, enough on vaporware. Two things to add to the Mac version of this disk: Curve Crypt, and Mac PGP. If you know of any other Mac stuff to throw in, please do so. I strongly sugggest we use 1.44Mb disk since Apple is braindamagedly trying to push new drives that won't support the old 800K GCR disks. :-( HELP REQUEST: If anyone knows how to read a file off a Mac HFS volume using sector reads/writes or knows of sample code (C, Pascal, Basic,68000, etc.) please send it my way. Basically I need to figure out where a file lives in terms of sectors and blocks. Hint: you can't call FSRead/FSWrite from a disk device driver because the file read/write routines are non-reentrant. From rarachel at prism.poly.edu Thu Mar 3 22:37:27 1994 From: rarachel at prism.poly.edu (Arsen Ray Arachelian) Date: Thu, 3 Mar 94 22:37:27 PST Subject: PC Expo, Mac World, Comdex, etc... (fwd) Message-ID: <9403040625.AA14688@prism.poly.edu> Forwarded message: From mpjohnso at nyx10.cs.du.edu Thu Mar 3 22:41:04 1994 From: mpjohnso at nyx10.cs.du.edu (Michael Johnson) Date: Thu, 3 Mar 94 22:41:04 PST Subject: Export of "Top Secret Data Encryption Techniques" Message-ID: <9403040639.AA28140@nyx10.cs.du.edu> > >Has anyone heard of this book [_Top_Secret_ - Data Encryption Techniques] and ... > One interesting feature of the books I looked at was that one of them > came with a floppy disk with code on it. I didn't notice anything > on the first few pages about "Not for export" or a mention that > the government treats crypto as munitions that need special permits > to export - I assume the authors are unaware of this, or that the > NSA doesn't really care about this level of crypto any more than > they care about rot-13 being exported :-) - but you'd think the > publishers would notice.... I was curious about that, too, but found out that the NSA declared it to be exportable. Note that there is no requirement that exportable crypto be marked as such. I've looked at the stuff in the book, and determined that I could probably crack most of it if I cared enough and had a fast computer. I also found that the author made a mistake in implementation that could cause some messages to not decrypt even if you have the right key, if you have a different brand of math coprocessor than the sender had. ___________________________________________________________ |\ /| | | | | \/ |o| | Michael Paul Johnson Colorado Catacombs BBS 303-938-9654 | | | | / _ | mpj at csn.org ftp csn.org \mpj\README.MPJ for access info.| | |||/ /_\ | aka mpjohnso at nyx.cs.du.edu mikej at exabyte.com | | |||\ ( | m.p.johnson at ieee.org CIS 71331,2332 VPGP key by finger | | ||| \ \_/ |___________________________________________________________| From hfinney at shell.portal.com Thu Mar 3 22:56:55 1994 From: hfinney at shell.portal.com (Hal) Date: Thu, 3 Mar 94 22:56:55 PST Subject: Security through Obscurity Message-ID: <199403040657.WAA02068@jobe.shell.portal.com> Security through Obscurity Here's my view of the problems with the security through obscurity approach. First I'll discuss encryption, then steganography. I use StO to mean "Security through Obscurity". It's true that obscurity can't hurt and might help. If you can not only keep your key secret, but your algorithm as well, then the attacker will have a much harder time breaking your encryption. And traditionally this has been done. I understand that much of the work in breaking the codes during WWII was involved in finding out the algorithm; once that was done then finding the keys was a considerably smaller problem. I think the the "No StO" maxim refers to a design methodology for the creation of cryptographic algorithms. In this technique, you divide the algorithm into those parts which must be kept secret, and those which don't have to be. The parts you keep secret you call the key, and you accept that you will have to take extreme measures to protect those secrets. The other parts are less protected. In other words, you conceptually draw a line between those parts which have to be protected at all costs, and those which don't. You then analyze the algorithm's strength on the assumption that the secret parts are kept secret. You also carry out the analysis on the assumption that the non-secret parts fall into enemy hands. In the end, an algorithm is judged on this basis. In the context of this design technique, StO would refer to the hope that the non-secret parts are also kept from enemy hands. While this may be desirable and beneficial, it breaks the rules of the method. The advantage of this method is that it allows you to do a clean cost versus benefit analysis. You calculate the cost in terms of what it takes to keep the keys secret, and you calculate the benefits in terms of how much security you gain if you keep the keys, and only the keys, secret. To also give credit for the additional security of keeping the non-key portions secret, you would also need to calculate the costs of keeping those parts secret. Since historically it has been very difficult to keep all parts of a cryptographic method secret, one has to consider these costs to be very high. Avoiding StO means avoiding falling into the trap of counting the benefits of keeping the non-key parts secret without counting the costs. In this light, there is no inherent violation of the NoStO principle in a cryptographic system which keeps the algorithm secret. It simply means that the algorithm has to be considered as secret as the key, and protected just as securely as the key is protected. In many circumstances this would be excessively costly but in some limited situations it may be practical. As long as you fully recognize that this line between the secret and the non-secret portions is drawn to put the algorithm on the "secret" side, you are properly avoiding StO. In the context of commercial or public-domain cryptographic algorithms, it is basically impossible to keep algorithms secret. That is why any cryptosystem of this nature which relies on a secret algorithm is scorned as violating the NoStO principle. It is generally not practical to expect to keep a secret which is made widely available. To sum up, obscurity is not bad. What is bad is to confuse obscurity with security. Now, in the context of steganography, we should make clear what problem we are trying to solve. There are several components to this problem, but I will focus just on the last step: hiding one bit pattern in another. Generally we do this by replacing some of the bits in the target data with bits from the data we are hiding. In encryption, the opponent's desire is to find out the original message. What is the opponent's desire in steganography? I feel it is to be able to prove or determine with some degree of certaintly that there is a hidden message. We use steganography in a context where sending such a message openly is for some reason undesirable. Hence our goal is to prevent the opponent from knowing that a message exists. A test, then, for the success of a steganographic technique is this: given some sampling of data items, half of which have embedded hidden messages, can the opponent guess which ones have such messages with better than 50% accuracy? If not, the steganography is fully successful. If he can do slightly better than 50%, it may still be useful depending on the situation. If he can guess with 100% accuracy, the steganography has failed and is totally worthless. Now, how does the NoStO maxim guide our attempts to evaluate steganographic algorithms? Again, the basic principle would be a need to separate that which would be kept secret from that which would be publicly known. Any system which relies on keeping secret some information which must be widely disseminated is not correctly accounting for costs when it touts its benefits. In the systems we have been discussing for a layered approach to stega- nography, the actual embedding step has no secret component. Rather, the message is first encrypted and possibly transformed in such a way that it is statistically identical to the bits which it is replacing. The actual steganographic step simply does the replacement. In this layered approach, there is no provision for key information to be used in steganography. Rather, the receiver of the message has only publicly available data. This means that when we "draw our line" we exclude nothing from the knowledge of our opponent. In counting the benefits of the steganographic algorithm we assume that the opponent will use exactly the same technique to de-steganize the message as our intended recipient will. Therefore, we are forced to assume that the opponent can successfully extract the hidden message. Now, the question that he must still answer is, is this in fact a message or is it just random noise? In order to meet the goal above of making such a guess impossible with better than 50-50 chances, it follows that the message must appear identical to random noise. Any pattern in the message, such as a plaintext header, will make the steganography useless. This is also why proposals to scramble or permute the bits as they go into the data, or to use a special offset instead of the beginning of the data (then wrapping the bits around when we come to the end) do not fundamentally help the situation. By the basic premise above, we assume that the opponent will be able to undo such artifices just as the intended recipient will. This way, again, we count our costs and benefits on fair grounds. Now, it is true that this is assuming that there is no "key" information used in the steganography. The NoStO principle would lead us to investigate keyed steganography, where the receiver has specific secret information which the opponent would not have. But if we are going to do this, we have to accept the costs. That key must be kept just as secret as the keys in an encryption system. We can't just let it be something obscure like a checksum based on a public key, information which the opponent will have as well. It has to be *secret*. That is what NoStO tells us. If we want the benefit of a key, we have to pay the cost. It's not clear whether keyed steganography has any benefits over the unkeyed system discussed above which is used as part of a chain which includes (presumably keyed!) encryption. It would seem that the stego would still have to match the statistics of the bits being replaced, and if you can do that then the unkeyed approach would work. But perhaps there are useful solutions along these lines. The important point, again, is that if you want a secret, you have to keep it secret. Looking at the advantages of a system which benefits if some information is withheld from the opponent without calculating the costs of actually keeping that information secret is the foolhardy behavior which the NoStO principle warns against. Hal Finney hfinney at shell.portal.com From rishab at dxm.ernet.in Thu Mar 3 23:12:53 1994 From: rishab at dxm.ernet.in (Rishab Aiyer Ghosh) Date: Thu, 3 Mar 94 23:12:53 PST Subject: Insecurity of public key crypto #1 (reply to Mandl) In-Reply-To: <9403020433.AA16707@prism.poly.edu> Message-ID: rarachel at prism.poly.edu (Arsen Ray Arachelian) writes: > Perhaps having a usenet news group for encoded mail might be better. > Something where everyone can occasionally either send a PGP'ed message > with the subject being an encoded version of the receipient's name, > or with just random junk that's PGP'ed... This would create enough > traffic to be able to hide messages in. Have you looked at alt.anonymous? I haven't, but the description on one list says it's on encrypted messages to unknown recipients. Like the blind mailing list thing - everyone gets everything, and only what was intended for you will decrypt with your key. ----------------------------------------------------------------------- Rishab Aiyer Ghosh "What is civilisation rishab at doe.ernet.in, rishab at dxm.ernet.in but a ribonucleic Voicemail +91 11 3760335; Vox/Fax/Data 6853410 hangover?" H-34C Saket New Delhi 110017 INDIA ----------------------------------------------------------------------- From karn at qualcomm.com Thu Mar 3 23:33:27 1994 From: karn at qualcomm.com (Phil Karn) Date: Thu, 3 Mar 94 23:33:27 PST Subject: Export of "Top Secret Data Encryption Techniques" In-Reply-To: <9403040639.AA28140@nyx10.cs.du.edu> Message-ID: <199403040733.XAA02834@servo.qualcomm.com> Speaking of the exportability of cryptography textbooks, I've filed a 15-day Commodity Jurisdiction Request with the State Dept for Bruce Schneier's book "Applied Cryptography". No official response yet, though I did get a phone call from an amused Commerce Dept engineer who wanted me to know how much they enjoyed my filing (I did have fun with some of the sections). Phil From rarachel at prism.poly.edu Thu Mar 3 23:46:07 1994 From: rarachel at prism.poly.edu (Arsen Ray Arachelian) Date: Thu, 3 Mar 94 23:46:07 PST Subject: Insecurity of public key crypto #1 (reply to Mandl) In-Reply-To: Message-ID: <9403040731.AA02331@prism.poly.edu> > Have you looked at alt.anonymous? > I haven't, but the description on one list says it's on encrypted messages to > unknown recipients. Like the blind mailing list thing - everyone gets > everything, and only what was intended for you will decrypt with your key. I haven't either. :-) I don't like the idea of a blind mailing list as it is hard to filter it. I already have enough problems just with reading cypherpunks, and the way I've solved it is via two accounts. One for cypherpunks mail and the other for normal private email. Addinmg any sort of extra noise would make things much harder. It would be nice if I could use a new mailer that automated the filtering process and presented several folders (personal, cypherpunks, blind-mail) and knew how to filter blind mail to pick up only mail intended for me, and automatically be able to handle message signing, posting to the blind list, etc. Message signing/verifying isn't a simple issue when you're dialing up a unix box and using its mail program. Unfortunatly, SLIP access is not given so I can't use a mailer on my own end to help automate this a bit. Storing a private key in my unix account is a bad idea. There have been plenty of break ins to the machines I use, luckily I haven't had my accounts screwed with (or if they're compromised, nobody fucked with my mail...) :-) But actually having a news group and a few automated junk mailers post to that to foil traffic analysys is needed... From phantom at u.washington.edu Fri Mar 4 00:07:41 1994 From: phantom at u.washington.edu (Matt Thomlinson) Date: Fri, 4 Mar 94 00:07:41 PST Subject: Big Brother Inside pays off Message-ID: I got a call this afternoon from Paul Andrews at the Seattle Times, wanting to ask me a few questions. After playing phone tag for an hour or so, we got connected. We discussed cypherpunks, steganography, and clipper. He seemed to have a good handle on how scary the clipper (and tessera) recommendations were. I was able to supply him with a little more information (contact #s) and answer some questions he had. His article will be in this sundays' Seattle Times, but it sounds like he may be gearing up to write another. In any case, I'm going to keep in touch. It looks like someone in the downtown area had the big brother inside logo on their windows desktop screen and _that_ is what caught his attention. I'm glad it served the purpose it was meant for -- catching people's attention and making them think. mt Matt Thomlinson Say no to the Wiretap Chip! University of Washington, Seattle, Washington. Internet: phantom at u.washington.edu phone: (206) 548-9804 PGP 2.2 key available via email or finger phantom at hardy.u.washington.edu From ian at geography.leeds.ac.uk Fri Mar 4 01:42:17 1994 From: ian at geography.leeds.ac.uk (Ian Turton) Date: Fri, 4 Mar 94 01:42:17 PST Subject: UK wants to end right to silence Message-ID: <12660.9403040943@geography.leeds.ac.uk> > > I just saw some very disturbing news in a programme (Reportage) on BBC > World Service TV. Apparently there are moves by the Government in Britain > to REPEAL THE RIGHT TO SILENCE. So far, as in the US (5th amend.) if arrested > in Britain you have the right to remain silent but if you wish to say anything > it may be used as evidence against you. Well close - note UK != Britain and even Britain doesn't have an all encompassing legal system. 1) The right to silence has already gone in Northern Ireland (part of the UK) along with jury trial (for terorist trails). The Govt plans to include this provision in the latest Criminal Justice Bill which is certainly for England and Wales but might not affect Scotland (I'm not sure, most of Scots law is different). 2) The right to silence at present means I don't have to say anything when arrested and the prosecution can not mention this to the court even if I come up with some plausible alibi when the case comes to trial. 3) The planned change is to allow the prosecution to mention this silence to the court and allow the jury to draw their own inferences, so the defence that I didn't trust the police not to frame me if I said anything may still be valid (more so if I have an Irish accent). It will still be impossible (well really hard) to convict someone simply because they stayed silent. > > The Government want to repeal the right to silence, obliging those arrested to > give an account AT THE 'SCENE OF CRIME'. A refusal to speak will be taken > as an indication of guilt. not quite - there is some doubt that any jury will believe that the questions where asked at the scene of the crime rather than in the police station infront of a double tape recorder. It is at present an arrestable offence to refuse to give police officers certain information when they ask this includes at least your name and address (there may be more but that was enough for them last time I didn't talk to the police). But in general I doubt that this will work. > > The defendent will also have to give witness in court, even if attorneys > believe that the witness or manner of giving it may be detrimental to the > defendents case. Even the judiciary are upset at this proposal and it is unlikely to make it through to law, especially considering the way the House of Lords have taken the Police and Magistrates Bill (a related bill) to pieces this month. The judges are upset since they will have to ask the defendant questions and are not at alll sure what they can do if he refuses to answer. > > Of course, libertarians are strongly against this, etc. But that it could > come about at all in Britain, is an indication of the powerful backlash of > the Right, whether with "Back to basics," "Family values," capital punishment > (in the US), or other reactions to crime that are nothing short of extremist, > however widespread "social decay" may be perceived to be by a generation that > can't understand the society to come. Ah well they say we must get tough on terrorists (and remember that unlike the US we have terrorists in the UK) and while we're at it we will catch more criminals, which is the best way to measure police efficiency, and any way if you're inoccent you've nothing to fear. > ----------------------------------------------------------------------- > Rishab Aiyer Ghosh "What is civilisation > rishab at doe.ernet.in, rishab at dxm.ernet.in but a ribonucleic > Voicemail +91 11 3760335; Vox/Fax/Data 6853410 hangover?" > H-34C Saket New Delhi 110017 INDIA > ----------------------------------------------------------------------- > all in all its bad but the general public love the idea and they have the votes :-( Ian Turton - School of Geography, Leeds University 0532 -333309 From sergey at delbruck.pharm.sunysb.edu Fri Mar 4 01:48:29 1994 From: sergey at delbruck.pharm.sunysb.edu (Sergey Goldgaber) Date: Fri, 4 Mar 94 01:48:29 PST Subject: Security through Obscurity In-Reply-To: <199403040657.WAA02068@jobe.shell.portal.com> Message-ID: On Thu, 3 Mar 1994, Hal wrote: > Security through Obscurity > Thank you for a very enlightening post, Hal. Just a couple of comments: > To sum up, obscurity is not bad. What is bad is to confuse obscurity > with security. If I have understood you correctly, there is nothing wrong with equating obscurity with a practical, albeit temporary, increase in security. Equating obscurity with ultimate security is a mistake. As is equating a "strong" algorithm with ultimate security. > In encryption, the opponent's desire is to find out the original message. > What is the opponent's desire in steganography? I feel it is to be able > to prove or determine with some degree of certaintly that there is a > hidden message. We use steganography in a context where sending such a > message openly is for some reason undesirable. Hence our goal is to > prevent the opponent from knowing that a message exists. I would like to propose that there is a goal, in addition to those you have revealed, for the opponent as well as the legitimate user of steganography. The opponent would, ideally, wish to not only determine that there is a message within the data; in addition, he would prefer to be able to extract that message for analysis. Therefore, I believe that it would be to the advantage of the stego-user to not only hide the existence of his message, but to do so in such a way that the cost of successfully extracting that message, by his opponent, is maximized. > A test, then, for the success of a steganographic technique is this: > given some sampling of data items, half of which have embedded hidden > messages, can the opponent guess which ones have such messages with > better than 50% accuracy? If not, the steganography is fully successful. > If he can do slightly better than 50%, it may still be useful depending > on the situation. If he can guess with 100% accuracy, the steganography > has failed and is totally worthless. If one accepts the additional goal proposed above, the value of an extra test is obvious. This test may consist of an attempt at message extraction, as per your guidelines. > Now, it is true that this is assuming that there is no "key" information > used in the steganography. The NoStO principle would lead us to > investigate keyed steganography, where the receiver has specific secret > information which the opponent would not have. But if we are going to > do this, we have to accept the costs. That key must be kept just as > secret as the keys in an encryption system. We can't just let it be > something obscure like a checksum based on a public key, information which > the opponent will have as well. It has to be *secret*. That is what > NoStO tells us. If we want the benefit of a key, we have to pay the cost. I have to take exception with the assertions made in this paragraph. Using the principles of public-key systems, the steganography key itself does not have to be kept secret. The sender, reciever, and indeed the opponent would all have access to this key without compromising the security of the system. The challenge, for the opponent, lies in figuring out which public-key the sender has used. I have no statistics on exactly how difficult this challenge would prove; but, considering the number of public-keys currently availiable and projecting several years into the future, the challenge may be a very significant one. The benefits of using offsets, in general, are clear (assuming one accepts the additional (and essential, I believe) function of steganagraphy programs, outlined above). The method I proposed for calculating the default offset from the checksum-value of the reciever's public-key was intended to provide a practical increase in security over defaulting to no offset (or a constant offset). For maximum security, a completely non-standard offset is called for. > Hal Finney > hfinney at shell.portal.com Thanks for your input yet again, Hal. Sergey From jeremy at crl.com Fri Mar 4 02:01:47 1994 From: jeremy at crl.com (Jeremy Cooper) Date: Fri, 4 Mar 94 02:01:47 PST Subject: Stegonography In-Reply-To: <9403020432.AA11900@bsu-cs.bsu.edu> Message-ID: On Tue, 1 Mar 1994, Anonymous wrote: > There's been a lot of discussion lately about trying to make stego files > not have any identifying marks, so that usage of stego would be > indistinguishiable from noise. A more effective option might be to > insert obvious (or somewhat obvious) stego messages in lots of graphics. > Take every graphic file you own and hide something in it with a stego > program. Put PGP messages in them (even including the obvious ---- > BEGIN PGP MESSAGE ---- headers). Or a BBS ad. Or just cute little > messages. Then distribute the files that way. Hopefully, people will > take these images and pass them on without ever knowing there was stuff > in them. If enuff people do this, graphics will become so "polluted" > with stego messages that your truly secret PGP messages will be hidden > in plain sight along with all the other graphic files full of stuff, and > won't stand out. Plus, you could plausably deny having put it there, > claiming that it must have been that way when you got it, and that you > didn't know it was there. > This goes along one of the more cute ways of annoying any snooper on your lines. If you periodically send noise over a suspicious line, you will give the people who are trying to monitor you a great headache. This is one of the tactics that you can use to foil any attempts to crack your communications. Then again, wouldn't it be weird if the noise you sent over actually decrypted into something intelligible? This says something about 'noise'. I know that it takes an incredible amount of mathematics to prove, but there must be a way to separate what is truly random noise, from that which appears to be. The calculations to crack this are probably more expensive than the information it contains, so it is hence uneconomical. But still, it makes me wonder. _ . _ ___ _ . _ ===-|)/\\/|V|/\/\ (_)/_\|_|\_/(_)/_\|_| Stop by for an excursion into the-=== ===-|)||| | |\/\/ mud.crl.com 8888 (_) Virtual Bay Area! -=== From cpsr at access.digex.net Fri Mar 4 02:05:34 1994 From: cpsr at access.digex.net (Dave Banisar) Date: Fri, 4 Mar 94 02:05:34 PST Subject: Guardian Article on Clipper Message-ID: <9403040509.AA13710@Hacker2.cpsr.digex.net> The Guardian (UK) March 3, 1994, Page 17 Are These Men A Threat To Free Speech? US law enforcement agencies want to decode 'secret' electronic mail, prompting a furious row about citizens' rights by Mike Holderness With modern communications systems you can send letters, orders and memos around the world in minutes. But you don't want your competitors, or their governments, siphoning the details of your bid for that dam contract in the Far East out of the Internet. So what do you do? And when you receive an electronic message announcing you've won the deal, how do you know it's genuine? It's possible to fake electronic mail: you must worry about the possibilities for creative industrial espionage this opens up. Then again, you might be a Cabinet minister, setting up a meeting with your boyfriend on the mobile phone. Wouldn't it be good to know that no one could tap the message? The answer to all these problems lies in encryption technology. The solution the US government proposed earlier this month, however, has generated a furious row in the on-line world about government interference in citizens' right to communicate in private. The disturbing implications for people outside the US have gone largely unremarked. Computer programs that can do practically unbreakable encryption are available to the public in the US and elsewhere. One, named PGP for Pretty Good Privacy, is increasingly used to authenticate electronic messages (Computer Guardian, November 25, 1993). It can encrypt the whole message, or send the main text "in clear", followed by an encrypted block containing a mathematical "fingerprint" of the message and the sender's name and address. The program can thus verify whether a signature belongs to the purported sender and whether the message arrives as it left. This worries law-enforcement agencies. What if drug dealers and terrorists start using unbreakable encryption? The US government's Key Escrow Encryption system - commonly known by its working title, Clipper - is its answer. Clipper uses an encryption chip suitable for building into a mobile phone or a modem. Its method of encryption, developed by the US National Security Agency (NSA), depends on "keys" - codes used mathematically to mangle the text or speech. The recipient can only get the original back if they have the key and can use it to un-mangle - decrypt - the message. PGP depends on a "public-key" system. Users sending signed messages encrypt the signature with keys known only to them. They also issue public keys, which are mathematically derived from the private key, and allow anyone to verify the signature. If someone sends them a message encrypted with their public key, only the private key will extract it. By contrast, each Clipper chip will have an encryption key built in. When the chip is manufactured, two parts of the key will be lodged with two separate US government agencies. (In legal jargon, this is like "holding the keys in escrow".) A secret "super-key" allows law enforcement agencies to retrieve the serial number of the chip used on the link they're tapping. Under US guidelines released last month, if a law enforcement agency wants to eavesdrop on encrypted communications it should send details of a search warrant to the agencies holding the key components. This is a red rag to the inhabitants of Internet discussion forums, the world's largest functioning anarchy. There, discussions of the right (under the First Amendment to the Constitution) to unrestricted free speech can and do slip effortlessly into the belief that, as one participant put it, "The people must be allowed to discuss anything, including revolution." According to Brian Yoder, president of California company Networxx, "The US Constitution doesn't grant the government the power to maintain this kind of surveillance capability over the population. Period. The assumption is that anything that enhances the ability of the police to catch criminals is OK, but that is not what the Constitution says, and that's not the kind of country I want to live in." Cryptology specialist Dr Dorothy Denning at Georgetown University was part of a team reviewing the NSA's design process. She points out that Clipper "will not make it any easier to tap phones, let alone computer networks. All it will do is make it possible to decrypt communications that are encrypted with the standard, assuming the communications are not super-encrypted with something else. Law enforcers still need to get a court order." But who trusts the NSA? The Clipper design is secret. Many assume the Agency has built in a "trap-door" allowing it to break encryption without the keys. No one has proposed making non-Clipper encryption illegal, but the US government clearly hopes to establish it as an industry standard. For example, while it's usually illegal to export any form of encryption technology from the US, it will be legal to export Clipper. However, non-US companies using it to protect their communications will have to live with the uneasy knowledge that the NSA could be listening in - and the NSA, like its UK sibling organisation GCHQ in Cheltenham, has a long history of intercepting foreign commercial messages for the benefit of home companies. (GCHQ declined to say whether it had been involved in any discussions over Clipper.) The protests have started. A petition organised by Computer Professionals for Social Responsibility against Clipper, and in favour of a Bill to permit export of competing encryption systems, gathered more than 20,000 electronic signatures in its first two weeks. Wired magazine has proclaimed, "This is a pivotal moment in history", accusing "the Clinton-Gore administration" of "attempting a stealth strike on our rights". It has asked readers to sign the CPSR petition and "call or write your Congressional representatives and let them know how you feel." Encryption and authentication are important for much more than the privacy of the frequently obscure or banal discussions on the Internet. Medical and financial records are now commonly held on computers, and a growing proportion of business transactions take place on-line. Cyberspace is where your money is. For private communications, Emma Nicholson MP takes a relaxed view: "In communicating, we should start from a belief that everyone listens to everything. Gossip is what makes the world go round. I have very few secrets. I would be deeply concerned if a device were marketed that could stop interception - I would support the FBI completely." Computer-law barrister Alistair Kelman, however, believes any attempt to enforce the Clipper chip as a worldwide standard would meet stiff opposition. The European Commission could be expected to object that it fell foul of Treaty of Rome provisions against misuse of a dominant position. "If you want to have a world standard for encryption, fine," Kelman said, but the EC could respond, "Let's get together and settle on something that meets our requirements as well." From jpp at markv.com Fri Mar 4 02:13:16 1994 From: jpp at markv.com (jpp at markv.com) Date: Fri, 4 Mar 94 02:13:16 PST Subject: reply-to feeds an anon pool, jpp=pr0duct=cypher Message-ID: <9403040212.aa01433@hermix.markv.com> I have built an 'easy anonymous reply' program. You can now use reply-to addresses of the form jpp=0x123456 at markv.com, where 0x123456 is a public key id. The obvious advantages are 'easy' reply-to's, no stored return address of any kind, and automatic encryption. The obvious disadvantages are the need to scan through alt.test for messages, that I have a list of all the 'bad' folks out there who want anonymous addresses (though it is not clear how terible it is for me to have a list of their public keys), and that I keep logs of the mail messages. My logs will be kept until I am sure the stuff works, and then I will junk'em. So encrypt, and use remailers if you need to -- I won't try to stop a government search of my disk. As a 'prop' to Pr0duct Cypher, I have a special hack that will send mail addressed to jpp=pr0duct=cypher at markv.com to alt.test encrypted with that famous CypherPunk's public key. (And as a courtesy to you all, I allow you to spell the address in any case, and with the letter oh instead of the digit 0 if you want.) I might sell similar addresses for digicash -- send me mail with a bid if you are interested. Below is the help file you would get if you mailed to jpp=poolhelp at markv.com. Try it out... Jay Prime Positive's mail pool service. If you send mail to jpp=0x123456 at markv.com, my program will look up the key matching 0x123456 on my 'pool' key ring. If it finds a matching key, it will encrypt the whole message (including headers) with that key. Then it will post the result to alt.test with a subject line matching 'Ignore 0x123456 blah blah blah' where blah blah blah is the key's 'identifier.' My mail program will be run for any address which begins jpp=0x, so you can only use PGP keyid's. As a result, my program won't let you use a key if the key id is already in use. See below. To add a key to the 'pool' key ring, send mail to jpp=poolnew, the body of the message should contain the public key in pgp format. If the key has a 0x123456 key id which is the same as a key already on the keyring, my program will send a message by reply mail, and post a message to alt.test, which has a subject 'Ignore jpp=poolnew key already in use', and a body mentioning the key clash. It will also post using the clashed with key, the same thing, encrypted for the 'legitamite' user of that key with all your mail information, so that they can talk to you about the problem. I will reward you if you can show me that you have managed to 'steal' a 0x123456 key id -- if you can get yours added to my 'pool' keyring, even though there is already one there. I will reward you more highly if you tell me how to fix the problem. To remove your key from the keyring, send a signed message (in simple english, spanish, or esperanto) asking me to remove your key. Send the mail to jpp=poolmaster at markv.com. For any other request, send mail to jpp=poolmaster at markv.com (in english, or very simple spanish or esperanto). If you want to improve this help message, send a copy to jpp=poolmaster at markv.com, and I will (probably) replace this message with yours. For now, and untill I am sure this code is debuged, I will keep comprehensive logs of the running of my code. Use remailers, and encryption as you think apropriate. All bets are off until I announce this service as operational -- all service you get before that date is accidental (on my part). j' -- O I am Jay Prime Positive jpp at markv.com 1250 bit fingerprint B06229 = B8 95 E0 AF 9A A2 CD A5 89 C9 F0 FE B4 3A 2C 3F 524 bit fingerprint 2A915D = 8A 7C B9 F2 D5 46 4D ED 66 23 F1 71 DE FF 51 48 Public keys via `finger jpp at markv.com', or via email to pgp-public-keys at io.com Your feedback is welcome directly or via my symbol JPP on hex at sea.east.sun.com Resist the Clipper Chip, write "I oppose Clipper" to Clipper.petition at cpsr.org From gtoal at an-teallach.com Fri Mar 4 03:33:29 1994 From: gtoal at an-teallach.com (Graham Toal) Date: Fri, 4 Mar 94 03:33:29 PST Subject: How to do encrypted telnet without being root (tutorial, includes src) Message-ID: <199403041131.LAA06991@an-teallach.com> People have been talking about encrypted telnets for ages, but I still haven't seen one I can easily use. And most suggestions would actually require a sysadmin to install a special telnet daemon. Here's a suggestion for how to do encrypted telnet sessions *without* any system code. It's quite simple - there's a process called 'remote' which sits between your keyboard/screen and the actual machine you're using. Very much like the way the 'script' program works, or perhaps 'screen' (though the latter is much much more complex than script). 'remote' encrypts all screen output. Next, there's a program called 'local'; you run local on your directly- connected local host. Normally local is transparent, and works again pretty much like 'script' (except of course there's no logging :-) ); however when local sees a certain magic string has been printed, it then assumes the data following will be encrypted, and it decrypts everything that's sent to your screen. (This 'in band' data is a little unclean, but it's what makes the whole scheme possible in user-level code) Actually it's *slightly* more complicated than this; when local sees the magic string, it starts up a conversation with whatever it's running on top of, and does some sort of key exchange to use with the encryption. (This conversation works by looking at the data that would otherwise be sent to the screen, and replying by simulating data as if it had been typed) I took two hours last night to actually hack up a version of these programs - the hack uses rot13 as its encryption method, and the key exchange is completely bogus. But it does show the method in action, and it wouldn't take much to adapt this to use a real encryption function. Left as the proverbial exercise for the reader. So, in summary... % local % telnet remotehost # (one that lets you log in with a 1-time password?) % remote Here's an actual log of such a session. I run the remote program first just to show you that the encryption does something - the process is so transparent that you might not follow it otherwise :-) Anyway, the point of this mechanism is that - like pgp - it is *user* code that you can take with you anywhere; you don't need the co-operation of the sys admins at each pair of sites you use. If anyone wants to take this ball and run with it to produce something that's a little more secure than rot13, be my guest. The only copyright here is the Berkeley one attached to the original 'script' source. Once you've got the idea, you might consider rewriting that bit from scratch too. G Script started on Fri Mar 4 10:44:32 1994 suilven% cd src/utel suilven% ./remote | Start encrypted session REMOTE: Asking local to start an encrypted session | [%MAGIC-PGP-START-SESSION%] | Expects a typed actually this stuff doesnt matter | key-exchange [%I-REPLY%] | wibble-wobble/actually this stuff doesnt matter | - this is clearly [%WHAT-DO-YOU-SAY?%] | a dummy exchange nothing really | [%FAIR-ENOUGH-ANYTHING-ELSE?%] | this is a dummy key exchange | [%THANK-YOU%] | fhvyira% cjq | % pwd /hfe/ubzr/tgbny/fep/hgry | fhvyira% | ^D [%ZNTVP-CTC-RAQ-FRFFVBA%] | 'end of session' message suilven% suilven% ./local LOCAL: I'll switch to encrypted mode when someone talks to me! suilven% telnet localhost Trying 127.0.0.1... Connected to localhost.an-teallach.com. Escape character is '^]'. BSDI BSD/386 1.0 (suilven.an-teallach.com) (ttyp8) | We're now running | over a telnet link login: gtoal Password: BSDI BSD/386 1.0 Kernel #6: Wed Oct 6 11:42:35 GMT 1993 pgp password: suilven% cd src/utel suilven% ./remote | start encryptor, do REMOTE: Asking local to start an encrypted session | key exchange (hidden) [%MAGIC-PGP-START-SESSION%] | local notices this rune suilven% echo Not obvious, but this is an encrypted telnet... Not obvious, but this is an encrypted telnet... suilven% | ^D, end encryption [%MAGIC-PGP-END-SESSION%] | local spots this magic suilven% logout | string and stops decrypt Connection closed by foreign host. | now a ^D to end local suilven% LOCAL: Done. (I won't be looking for encrypted output any more...) suilven% Script done on Fri Mar 4 10:46:24 1994 And for your edification, here's the code. (bsd systems only - tested on BSDI and 386BSD) *BIG NOTE*... there are (ahem) one or two rather hacky bits in here. As I said, it was a two-hour hack just to prove the point that code like this can be written easily and it doesn't take a systems manager to install it. (Also, being code you compile yourself, you might trust it a little more). Noticably the rot13 encryption neatly allows me to avoid problems sending binary data. Doing this for real, your output to screen/read from output stream code should encode each encrypted byte as two hexascii bytes for portability; also a few newlines here and there to keep the buffers flushed wouldn't hurt. And there's a *filthy* piece of code to do keyboard stuffing in here. This is *not* how you'd do it in a production program. A security hole a mile wide. I couldn't be bothered learning how to do internal pipes for this quick proof-of-concept hack, so I used a file in /tmp to communicate through... *BIG NOTE #2* This only does screen output; keyboard input is also left as a trivial exercise to the reader... # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # Makefile # local.c # remote.c # echo x - Makefile sed 's/^X//' >Makefile << 'END-of-Makefile' Xall: remote local X echo All up to date X Xremote: remote.c X cc -o remote remote.c X Xlocal: local.c X cc -o local local.c END-of-Makefile echo x - local.c sed 's/^X//' >local.c << 'END-of-local.c' X/* X This is a trivial (2 hour) hack to the 'script' command X to show the general principle involved in hacking up a user-level X encrypted telnet equivalent. This particular hack uses 'rot13' X as its 'encryption'; feel free to make it (ahem) more robust. X */ X X/* X X X +---------+ +----------+ +-------------------+ Xkeyboard---->| |----->| |----->|-\ | X | local | | remote | | | remote process | X vdu<----| |<-----| |<-----|-/ | X +---------+ ^ +----------+ +-------------------+ X | X | X This line may include a telnet session... X X*/ X X/* X * Copyright (c) 1980 Regents of the University of California. X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by the University of X * California, Berkeley and its contributors. X * 4. Neither the name of the University nor the names of its contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * X * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X */ X X#ifndef lint Xchar copyright[] = X"@(#) Copyright (c) 1980 Regents of the University of California.\n\ X All rights reserved.\n"; X#endif /* not lint */ X X#ifndef lint Xstatic char sccsid[] = "@(#)script.c 5.13 (Berkeley) 3/5/91"; X#endif /* not lint */ X X/* X * script X */ X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X Xchar *shell; Xint master; Xint slave; Xint child; Xint subchild; Xchar *fname; X Xstruct termios tt; Xstruct winsize win; Xint lb; Xint l; Xchar line[] = "/dev/ptyXX"; Xint aflg; X X Xstatic int debug = 0; X X#define NULLFILE "/dev/null" X#define LOGFILE "utel.log" X Xstatic int suppress_debug = (0!=0); X Xstatic void debugf(char *s, ...) { Xstatic int checked = 0; Xint string_length; XFILE *nullfile; XFILE *errfile; Xstatic char buff[256]; Xva_list ap; X if (checked == 0) { checked = 1; X /* Only want to log if logfile exists already... */ X errfile = fopen(LOGFILE, "r"); X suppress_debug = (errfile == NULL); X if (errfile != NULL) fclose(errfile); X } X X nullfile = fopen(NULLFILE, "w"); X if (nullfile == NULL) { X errfile = fopen(LOGFILE, "a"); X if (errfile != NULL) { X fprintf(errfile, "Major error - cannot open %s\n", NULLFILE); X fflush(errfile); X fclose(errfile); X } X exit(1); X } X X va_start(ap, s); X string_length = vfprintf(nullfile, s, ap); X if (string_length < 126) { X vsprintf(buff, s, ap); X } else { X sprintf(buff, "[%d char debugf string excised]\n", string_length); X } X va_end(ap); X X fclose(nullfile); X X if (suppress_debug) return; X errfile = fopen(LOGFILE, "a"); X if (errfile != NULL) { X fprintf(errfile, "%s", buff); X fflush(errfile); X fclose(errfile); X } X} X X X Xint session_started = (0!=0); X X#define STATE_SIZE 128 Xtypedef struct cypherstate { X char whatever[STATE_SIZE]; X long int byteno; X /* Add useful stuff here as need be... */ X} CYPHER_STATE; X Xvoid new_cypher(CYPHER_STATE *s) X{ X int i; X /* Random mockup code as a placeholder... */ X for (i = 0; i < STATE_SIZE; i++) { X s->whatever[i] = 0; X } X s->byteno = 0L; X} X X#define MAX_KEYLINELEN 4096 X/* Need to hack this to allow for errors... */ X Xstatic void getline(int masterfd, char *answer) X{ Xchar *s; Xint i; Xint rc; Xchar c; X i = 0; X s = answer; X for (;;) { X rc = read(masterfd, &c, 1); X if (rc != 1) continue; X if (c == '\r') continue; X if (c == '\n') break; X i += 1; X if (i == MAX_KEYLINELEN) { X fprintf(stderr, "Protocol failure - line too long\n"); X break; X } X *s++ = c; X } X *s = '\0'; X} X Xvoid expect(int masterfd, char *line) X{ Xstatic char answer[MAX_KEYLINELEN]; X answer[0] = '\0'; X getline(masterfd, answer); X debugf("Expect: Want '%s', Got '%s'\n", line, answer); X if (strcmp(line, answer) != 0) { X /*fprintf(stderr, "\r\nProtocol failure - wanted '%s' - got '%s'\r\n", X line, answer); X fflush(stderr);*/ X return; X } X /*fflush(stderr);*/ X} X Xvoid faketype(char *s) X{ X /* Ask out other half to send this text as if it had been typed. */ X FILE *hack; X debugf("faketype: sending '%s'\n", s); X hack = fopen("/tmp/typeme", "r"); X if (hack != NULL) { X char *ptr; X char tmp[128]; X fgets(tmp, 127, hack); X ptr = strchr(tmp, '\n'); X if (ptr != NULL) *ptr = '\n'; X fprintf(stderr, "Oops - last line (%s) not sent yet!\n", tmp); X fclose(hack); X return; X } X hack = fopen("/tmp/typeme.tmp", "w"); X if (hack == NULL) { X fprintf(stderr, "Can't faketype to /tmp/typeme\n"); X return; X } X fprintf(hack, "%s\n", s); X fclose(hack); X rename("/tmp/typeme.tmp", "/tmp/typeme"); X} X X/* This procedure is invoked at a random time in the middle X of a session of 'local' when the MAGIC-PGP-START-SESSION X string is recognised as just having been printed... */ Xvoid NEGOTIATE_SESSION_KEYS( X int masterfd, FILE *out, X CYPHER_STATE *outkey, CYPHER_STATE *inkey) X{ Xstatic char keyline[MAX_KEYLINELEN]; Xchar *ptr; X X new_cypher(outkey); X new_cypher(inkey); X /* Engage in a conversation with the program at the other X side to negotiate a session key. How you do this is X up to you. */ X faketype("Hello big boy!"); expect(masterfd, "Hello big boy!"); X /* At this point, the other half *must* poll the file and X send the data or we're in trouble */ X expect(masterfd, "[%I-REPLY%]"); X getline(masterfd, keyline); X expect(masterfd, "[%WHAT-DO-YOU-SAY?%]"); X faketype("Nice weather..."); expect(masterfd, "Nice weather..."); X expect(masterfd, "[%FAIR-ENOUGH-ANYTHING-ELSE?%]"); X faketype("Thank you for calling "); X expect(masterfd, "Thank you for calling "); X expect(masterfd, "[%THANK-YOU%]"); X session_started = (0==0); X} X XCYPHER_STATE outstate, instate; X Xchar rot13(char c) X{ Xreturn(isalpha(c) ? ((c > (islower(c) ? 'z' : 'Z')-13) ? c - 13 : c + 13) : c); X} X Xchar decrypt_stream_cypher(CYPHER_STATE *s, char byte) X{ X return(rot13(byte)); /* bwahahahaha! */ X} X Xvoid ENCRYPT_KEYBOARD_INPUT(char *buff, int count) X{ X /* First iteration - keyboard input in clear, X only screen output to be encrypted */ X} X Xvoid DECRYPT_SCREEN_OUTPUT(char *buff, int count) X{ X int i; X if (session_started) { X for (i = 0; i < count; i++) { X buff[i] = decrypt_stream_cypher(&outstate, buff[i]); X } X } X} X Xint scanfor_start(int masterfd, char c) X{ X#define MAGIC "[%MAGIC-PGP-START-SESSION%]" X#define MAGICLEN strlen(MAGIC) Xstatic char *buffer = NULL; Xstatic int nextfree = 0; X c &= 127; X if (c == 13) return(0!=0); X /* An expensive hack, but who cares... */ X if (buffer == NULL) { X buffer = malloc(MAGICLEN+1); X memset(buffer, ' ', MAGICLEN-1); X buffer[MAGICLEN] = '\0'; X } X if (c == '\n') { X if (memcmp(buffer, MAGIC, MAGICLEN) == 0) { X NEGOTIATE_SESSION_KEYS(masterfd, stdout, &outstate, &instate); X /*printf("LOCAL: starting session\r\n");*/ X return(0==0); X } X } X memmove(buffer, buffer+1, MAGICLEN-1); X buffer[MAGICLEN-1] = c; X#undef MAGIC X#undef MAGICLEN X return(0!=0); X} X Xvoid scanfor_end(int masterfd, char c) X{ X#define MAGIC "[%MAGIC-PGP-END-SESSION%]" X#define MAGICLEN strlen(MAGIC) Xstatic char *buffer = NULL; Xstatic int nextfree = 0; X c &= 127; X if (c == 13) return; X /* An expensive hack, but who cares... */ X if (buffer == NULL) { X buffer = malloc(MAGICLEN+1); X memset(buffer, ' ', MAGICLEN-1); X buffer[MAGICLEN] = '\0'; X } X if (c == '\n') { X if (memcmp(buffer, MAGIC, MAGICLEN) == 0) { X /*printf("LOCAL: starting session\r\n");*/ X session_started = (0!=0); X /* Go quiescent again. Maybe it would be better X to exit the local program entirely??? */ X } X } X memmove(buffer, buffer+1, MAGICLEN-1); X buffer[MAGICLEN-1] = c; X#undef MAGICLEN X#undef MAGIC X} X Xint filter_incoming_text(int masterfd, char *s, int len) X{ Xint i; Xint rc; X /* Watch the incoming stream for the magic string that X denotes the start of a key exchange; when it's detected, X do a key exchange, and enable decryption of the session */ X rc = (0!=0); X for (i = 0; i < len; i++) { X if (scanfor_start(masterfd, s[i])) { X rc = (0==0); X } X } X return(rc); X} Xvoid filter_outgoing_text(int masterfd, char *s, int len) X{ Xint i; X /* Watch the incoming stream for the magic string that X denotes the start of a key exchange; when it's detected, X do a key exchange, and enable decryption of the session */ X for (i = 0; i < len; i++) { X scanfor_end(masterfd, s[i]); X } X} X X X Xmain(argc, argv) X int argc; X char *argv[]; X{ X extern char *optarg; X extern int optind; X int ch; X void finish(); X char *getenv(); X X while ((ch = getopt(argc, argv, "a")) != EOF) X switch((char)ch) { X case 'a': X aflg++; X break; X case '?': X default: X fprintf(stderr, "usage: script [-a] [file]\n"); X exit(1); X } X argc -= optind; X argv += optind; X X shell = getenv("SHELL"); X if (shell == NULL) X shell = _PATH_BSHELL; X X getmaster(); X printf("LOCAL: I'll switch to encrypted mode when someone talks to me!\n"); X X fixtty(); X X (void) signal(SIGCHLD, finish); X child = fork(); X if (child < 0) { X perror("fork"); X fail(); X } X if (child == 0) { X subchild = child = fork(); X if (child < 0) { X perror("fork"); X fail(); X } X if (child) X dooutput(); X else X doshell(); X } X doinput(); X} X Xdoinput() X{ X register int cc; X char ibuf[BUFSIZ]; X X char fakeline[MAX_KEYLINELEN]; X FILE *hack; X char *ptr; X X fd_set fds; X struct timeval t; X X for (;;) { X timerclear(&t); X t.tv_sec = 1; /* No more than 1 sec without polling faketype */ X FD_ZERO(&fds); X FD_SET(0, &fds); X X cc = select(1, &fds, NULL, NULL, &t); X if (cc == -1) { X /* select error */ X } X if (cc == 0) { X /* timeout */ X } X if (cc > 0) { X cc = read(0, ibuf, BUFSIZ); X /* cc should be > 0 */ X if (cc > 0) { X ENCRYPT_KEYBOARD_INPUT(ibuf, cc); X (void) write(master, ibuf, cc); X } X } X hack = fopen("/tmp/typeme", "r"); X if (hack != NULL) { X ptr = fgets(fakeline, MAX_KEYLINELEN, hack); X (void)write(master, fakeline, strlen(fakeline)); X fclose(hack); X remove("/tmp/typeme"); X } X } X done(); X} X X#include X Xvoid Xfinish() X{ X union wait status; X register int pid; X register int die = 0; X X while ((pid = wait3((int *)&status, WNOHANG, 0)) > 0) X if (pid == child) X die = 1; X X if (die) X done(); X} X Xdooutput() X{ X time_t tvec, time(); X char obuf[BUFSIZ], *ctime(); X int cc; X int rc; X X (void) close(0); X tvec = time((time_t *)NULL); X X for (;;) { X cc = read(master, obuf, sizeof (obuf)); X if (cc <= 0) break; X rc = filter_incoming_text(master, obuf, cc); X if (!rc) DECRYPT_SCREEN_OUTPUT(obuf, cc); X (void) write(1, obuf, cc); X filter_outgoing_text(master, obuf, cc); X } X done(); X} X Xdoshell() X{ X int t; X X /*** X t = open(_PATH_TTY, O_RDWR); X if (t >= 0) { X (void) ioctl(t, TIOCNOTTY, (char *)0); X (void) close(t); X } X ***/ X getslave(); X (void) close(master); X (void) dup2(slave, 0); X (void) dup2(slave, 1); X (void) dup2(slave, 2); X (void) close(slave); X execl(shell, "sh", "-i", 0); X perror(shell); X fail(); X} X Xfixtty() X{ X struct termios rtt; X X rtt = tt; X cfmakeraw(&rtt); X rtt.c_lflag &= ~ECHO; X (void) tcsetattr(0, TCSAFLUSH, &rtt); X} X Xfail() X{ X X (void) kill(0, SIGTERM); X done(); X} X Xdone() X{ X time_t tvec, time(); X char *ctime(); X X if (subchild) { X tvec = time((time_t *)NULL); X (void) close(master); X } else { X (void) tcsetattr(0, TCSAFLUSH, &tt); X printf("LOCAL: Done. (I won't be looking for encrypted output any more...)\n"); X } X exit(0); X} X Xgetmaster() X{ X char *pty, *bank, *cp; X struct stat stb; X X pty = &line[strlen("/dev/ptyp")]; X for (bank = "pqrs"; *bank; bank++) { X line[strlen("/dev/pty")] = *bank; X *pty = '0'; X if (stat(line, &stb) < 0) X break; X for (cp = "0123456789abcdef"; *cp; cp++) { X *pty = *cp; X master = open(line, O_RDWR); X if (master >= 0) { X char *tp = &line[strlen("/dev/")]; X int ok; X X /* verify slave side is usable */ X *tp = 't'; X ok = access(line, R_OK|W_OK) == 0; X *tp = 'p'; X if (ok) { X (void) tcgetattr(0, &tt); X (void) ioctl(0, TIOCGWINSZ, X (char *)&win); X return; X } X (void) close(master); X } X } X } X fprintf(stderr, "Out of pty's\n"); X fail(); X} X Xgetslave() X{ X X line[strlen("/dev/")] = 't'; X slave = open(line, O_RDWR); X if (slave < 0) { X perror(line); X fail(); X } X (void) tcsetattr(slave, TCSAFLUSH, &tt); X (void) ioctl(slave, TIOCSWINSZ, (char *)&win); X (void) setsid(); X (void) ioctl(slave, TIOCSCTTY, 0); X} END-of-local.c echo x - remote.c sed 's/^X//' >remote.c << 'END-of-remote.c' X/* X This is a trivial (2 hour) hack to the 'script' command X to show the general principle involved in hacking up a user-level X encrypted telnet equivalent. This particular hack uses 'rot13' X as its 'encryption'; feel free to make it (ahem) more robust. X */ X X/* X * Copyright (c) 1980 Regents of the University of California. X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by the University of X * California, Berkeley and its contributors. X * 4. Neither the name of the University nor the names of its contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * X * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X */ X X#ifndef lint Xchar copyright[] = X"@(#) Copyright (c) 1980 Regents of the University of California.\n\ X All rights reserved.\n"; X#endif /* not lint */ X X#ifndef lint Xstatic char sccsid[] = "@(#)script.c 5.13 (Berkeley) 3/5/91"; X#endif /* not lint */ X X/* X * script X */ X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X X#define MAX_KEYLINELEN 4096 X Xchar *shell; Xint master; Xint slave; Xint child; Xint subchild; Xchar *fname; X Xstruct termios tt; Xstruct winsize win; Xint lb; Xint l; Xchar line[] = "/dev/ptyXX"; Xint aflg; X X X#define STATE_SIZE 128 Xtypedef struct cypherstate { X char whatever[STATE_SIZE]; X long int byteno; X /* Add useful stuff here as need be... */ X} CYPHER_STATE; X Xvoid new_cypher(CYPHER_STATE *s) X{ X int i; X /* Random mockup code as a placeholder... */ X for (i = 0; i < STATE_SIZE; i++) { X s->whatever[i] = 0; X } X s->byteno = 0L; X} X Xstatic void getline(FILE *in, char *answer) X{ Xchar *s; Xint i; Xint rc; Xchar c; X i = 0; X s = answer; X for (;;) { X c = fgetc(in); X if (c == '\r') continue; X if (c == '\n') break; X i += 1; X if (i == MAX_KEYLINELEN) { X fprintf(stderr, "Protocol failure - line too long\n"); X break; X } X *s++ = c; X } X *s = '\0'; X} X X Xvoid NEGOTIATE_SESSION_KEYS( X FILE *in, FILE *out, X CYPHER_STATE *outkey, CYPHER_STATE *inkey) X{ Xstatic char keyline[MAX_KEYLINELEN]; Xchar *ptr; X X new_cypher(outkey); X new_cypher(inkey); X /* Engage in a conversation with the program at the other X side to negotiate a session key. How you do this is X up to you. */ X fprintf(out, "REMOTE: Asking local to start an encrypted session\n"); X fprintf(out, "[%%MAGIC-PGP-START-SESSION%%]\n"); /* Detected by finite-state mc */ X /* (what I don't understand is why the line above comes out on X the user's display, encrypted) */ X /* The fgets below comes from data that 'local' fakes as if it had X been typed at the keyboard. */ X strcpy(keyline, "AAA"); X getline(in, keyline); X ptr = strchr(keyline, '\n'); if (ptr != NULL) *ptr = '\0'; X fprintf(out, "[%%I-REPLY%%]\n"); X fprintf(out, "wibble-wobble/%s\n", keyline); X fprintf(out, "[%%WHAT-DO-YOU-SAY?%%]\n"); X strcpy(keyline, "BBB"); X getline(in, keyline); X fprintf(out, "[%%FAIR-ENOUGH-ANYTHING-ELSE?%%]\n"); X strcpy(keyline, "CCC"); X getline(in, keyline); X fprintf(out, "[%%THANK-YOU%%]\n"); X} X XCYPHER_STATE outstate, instate; X Xchar rot13(char c) X{ Xreturn(isalpha(c) ? ((c > (islower(c) ? 'z' : 'Z')-13) ? c - 13 : c + 13) : c); X} X Xchar stream_cypher(CYPHER_STATE *s, char byte) X{ X return(rot13(byte)); /* bwahahahaha! */ X} X Xvoid DECRYPT_KEYBOARD_INPUT(char *buff, int count) X{ X /* First iteration - keyboard input in clear, X only screen output to be encrypted */ X} X Xvoid ENCRYPT_SCREEN_OUTPUT(char *buff, int count) X{ X int i; X for (i = 0; i < count; i++) { X buff[i] = stream_cypher(&outstate, buff[i]); X } X} X Xmain(argc, argv) X int argc; X char *argv[]; X{ X extern char *optarg; X extern int optind; X int ch; X void finish(); X char *getenv(); X X while ((ch = getopt(argc, argv, "a")) != EOF) X switch((char)ch) { X case 'a': X aflg++; X break; X case '?': X default: X fprintf(stderr, "usage: script [-a] [file]\n"); X exit(1); X } X argc -= optind; X argv += optind; X X shell = getenv("SHELL"); X if (shell == NULL) X shell = _PATH_BSHELL; X X getmaster(); X /* This session is negotiated before we do the complicated X stuff with the two processes... Anything we send to the X screen can be trapped by 'local', and local's replies X will appear to be typed at the keyboard... */ X NEGOTIATE_SESSION_KEYS(stdin, stdout, &outstate, &instate); X fixtty(); X X (void) signal(SIGCHLD, finish); X child = fork(); X if (child < 0) { X perror("fork"); X fail(); X } X if (child == 0) { X subchild = child = fork(); X if (child < 0) { X perror("fork"); X fail(); X } X if (child) X dooutput(); X else X doshell(); X } X doinput(); X} X Xdoinput() X{ X register int cc; X char ibuf[BUFSIZ]; X X while ((cc = read(0, ibuf, BUFSIZ)) > 0) { X DECRYPT_KEYBOARD_INPUT(ibuf, cc); X (void) write(master, ibuf, cc); X } X done(); X} X X#include X Xvoid Xfinish() X{ X union wait status; X register int pid; X register int die = 0; X X while ((pid = wait3((int *)&status, WNOHANG, 0)) > 0) X if (pid == child) X die = 1; X X if (die) X done(); X} X Xdooutput() X{ X register int cc; X time_t tvec, time(); X char obuf[BUFSIZ], *ctime(); X X (void) close(0); X tvec = time((time_t *)NULL); X X for (;;) { X cc = read(master, obuf, sizeof (obuf)); X if (cc <= 0) X break; X ENCRYPT_SCREEN_OUTPUT(obuf, cc); X (void) write(1, obuf, cc); X } X done(); X} X Xdoshell() X{ X int t; X X /*** X t = open(_PATH_TTY, O_RDWR); X if (t >= 0) { X (void) ioctl(t, TIOCNOTTY, (char *)0); X (void) close(t); X } X ***/ X getslave(); X (void) close(master); X (void) dup2(slave, 0); X (void) dup2(slave, 1); X (void) dup2(slave, 2); X (void) close(slave); X execl(shell, "sh", "-i", 0); X perror(shell); X fail(); X} X Xfixtty() X{ X struct termios rtt; X X rtt = tt; X cfmakeraw(&rtt); X rtt.c_lflag &= ~ECHO; X (void) tcsetattr(0, TCSAFLUSH, &rtt); X} X Xfail() X{ X X (void) kill(0, SIGTERM); X done(); X} X Xdone() X{ X time_t tvec, time(); X char *ctime(); X X if (subchild) { X tvec = time((time_t *)NULL); X (void) close(master); X } else { X char tmp[128]; X (void) tcsetattr(0, TCSAFLUSH, &tt); X /* This too has to be hacked when we do a real encryptor */ X /* This text should be sent and checked encrypted */ X strcpy(tmp, "\n[%MAGIC-PGP-END-SESSION%]\n"); X ENCRYPT_SCREEN_OUTPUT(tmp, strlen(tmp)); X printf("%s", tmp); fflush(stdout); X /* Need a 'sleep' here to flush that damn buffer properly */ X sleep(2); X } X exit(0); X} X Xgetmaster() X{ X char *pty, *bank, *cp; X struct stat stb; X X pty = &line[strlen("/dev/ptyp")]; X for (bank = "pqrs"; *bank; bank++) { X line[strlen("/dev/pty")] = *bank; X *pty = '0'; X if (stat(line, &stb) < 0) X break; X for (cp = "0123456789abcdef"; *cp; cp++) { X *pty = *cp; X master = open(line, O_RDWR); X if (master >= 0) { X char *tp = &line[strlen("/dev/")]; X int ok; X X /* verify slave side is usable */ X *tp = 't'; X ok = access(line, R_OK|W_OK) == 0; X *tp = 'p'; X if (ok) { X (void) tcgetattr(0, &tt); X (void) ioctl(0, TIOCGWINSZ, X (char *)&win); X return; X } X (void) close(master); X } X } X } X fprintf(stderr, "Out of pty's\n"); X fail(); X} X Xgetslave() X{ X X line[strlen("/dev/")] = 't'; X slave = open(line, O_RDWR); X if (slave < 0) { X perror(line); X fail(); X } X (void) tcsetattr(slave, TCSAFLUSH, &tt); X (void) ioctl(slave, TIOCSWINSZ, (char *)&win); X (void) setsid(); X (void) ioctl(slave, TIOCSCTTY, 0); X} END-of-remote.c exit From michael.shiplett at umich.edu Fri Mar 4 03:57:01 1994 From: michael.shiplett at umich.edu (michael shiplett) Date: Fri, 4 Mar 94 03:57:01 PST Subject: Anonymous Encrypted Remailer Interface for Emacs Message-ID: <199403041156.GAA19523@totalrecall.rs.itd.umich.edu> Hello, I finally wrote some code. This interface automates the wrapping of messages for use with the encrypted anonymous remailers--provided you're willing to enter into Emacs for the wrapping. I've sent & received several messages using it. Please let me know if you find any problems. enjoy, michael =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ;;; anon-remail.el v1.0, anonymous remailer interface ;;; written by michael shiplett ;;; Any comments or suggestions welcomed. ;;; License ;;; No implied or expressed warranty nor any other guarantee. ;;; Do what you want with this. ;;; Anonymous Encrypted Remailer Interface ;;; Usage: ;;; You must set ar-remailer-list to a list of anonymous ;;; remailer addresses. These must be in a valid mail ``To:'' ;;; format. The initial recipients address must also be in a valid ;;; ``To:'' format; addresses depending on alias files will not ;;; work because your mail program (MH, Elm, mail, etc.) will ;;; not get a chance to process them before the message is wrapped. ;;; After writing your message, invoke ar-wrap-message. If you ;;; wish to sign the message, you should only sign the first ;;; wrapping. ;;; After the message has been wrapped, a list will appear in ;;; the minibuffer--this is the route the message will take. ;;; This package requires that you have mailcrypt configured ;;; for use with pgp (unless you send to ripem remailers). ;;; To Do: ;;; Modify mc-encrypt to take a boolean argument for ;;; signing the message. ;;; Allow for different remailer lists based on whether ;;; the transit delay one wants, e.g., fast, normal, or slow. (require 'mailcrypt) ;; User Variables (defvar ar-remailer-list nil "*List of remailers from which to choose.") (defvar ar-hops 3 "*Number of remailers among which to pass message.") ;; Hooks (defvar ar-start-hook nil) ;; Functions (defun ar-wrap-message (&optional hops) "*Wrap the current message for a person and then wrap it for HOPS remailers. If HOPS is nil, use the value of `ar-hops'." (interactive "P") (run-hooks 'ar-start-hook) (let ((remailer-path (list (mail-fetch-field "to" nil t)))) (ar-wrap-message-for-individual) (if (not hops) (setq hops ar-hops)) (while (< 0 hops) (let ((remailer (ar-choose-remailer))) ;; `remailer-path' is to prevent us ;; from sending to the same remailer twice ;; in a row. ;; It gives the path the message will take ;; beginning with `(car remailer-path)' (while (string= remailer (car remailer-path)) (setq remailer (ar-choose-remailer))) (setq remailer-path (cons remailer remailer-path)) (ar-wrap-for-remailer remailer) (setq hops (1- hops)))) (message "%s" remailer-path))) (defun ar-choose-remailer () "*Select a random remailer from `ar-remailer-list'." (let (number-of-remailers remailer) ;; Choose a remailer (setq number-of-remailers (length ar-remailer-list)) (or number-of-remailers (error "No remailers!")) (nth (random number-of-remailers) ar-remailer-list))) (defun ar-wrap-for-remailer (remailer) "*Wrap the current mail buffer for mailing to a specified remailer." (let (recipient) ;; Keep track of whom should receive the resent message (setq recipient (mail-fetch-field "to" nil t)) ;; Add the magic redirection words (goto-char (point-min)) (search-forward (concat "\n" mail-header-separator "\n")) (setq start (point)) (insert "::\nRequest-Remailing-To: " recipient "\n\n") ;; Wrap the message for the remailer (mc-encrypt-message remailer nil) ;; Add in the final magic remailer incantation (goto-char start) (insert "::\nEncrypted: PGP\n\n") ;; Set the message to be sent to the remailer (ar-set-recipient remailer) )) (defun ar-wrap-message-for-individual () "*Does the initial wrap for a message not intended for a remailer" ;; Figure out to whom the message is currently intended (let (recipient) (setq recipient (mail-fetch-field "to" nil t)) (mc-encrypt-message recipient nil) )) (defun ar-set-recipient (recipient) "*Set the ``To:'' field of a message. This will not work on a multi-line ``To:''." (or recipient (error "No recipient!")) (goto-char (point-min)) (search-forward "To:") (let ((beg (point))) (end-of-line) (delete-region beg (point))) (insert " " recipient)) (provide 'anon-remail) From bart at netcom.com Fri Mar 4 04:21:13 1994 From: bart at netcom.com (Harry Bartholomew) Date: Fri, 4 Mar 94 04:21:13 PST Subject: New fast cryptocomputer chip Message-ID: <199403041222.EAA14965@mail.netcom.com> On page 20 of EE Times, Feb. 14, 1994, Roger Woolnough wrote: "By linking up with an Israeli company specializing in cryptographic technology, SGS-Thompson Microelectronics has developed a family of monolithic cryptocomputers aimed at high-security smart-card applications. The new devices combine SGS-Thompson's ST16XYZ secure smart-card architecture with cryptographic enhancements developed by Fortress U&T Ltd." Summarizing the remainder - The approach is based on public key encryption, speed is enhanced by a modular arithmatic coprocessor developed by Fortress for very fast execution of modular exponentiation operations. "A typical 512-bit signature calculation can be performed 10 times faster than with the best performing smart-card cryptoprocessor currently on the market. The ST16CF54 will be followed by further devices, such as the ST16KF74, capable of full-speed X.25 communications." From jim at Tadpole.COM Fri Mar 4 05:43:48 1994 From: jim at Tadpole.COM (Jim Thompson) Date: Fri, 4 Mar 94 05:43:48 PST Subject: Information Highway Beautification Fund Message-ID: <9403041343.AA06056@chiba.tadpole.com> Date: Fri, 4 Mar 1994 04:01:33 -0500 From: "Carl Malamud" To: "Announcements" Org: Internet Multicasting Service Channel: Internet Town Hall Subject: Information Highway Beautification Fund The Information Highway Beautification Fund Abstract: A Proposal To Turn on the Lights on the Information Superhighway This document outlines some of the background on the Clipper proposals and shows how Clipper is just one example of the underlying public key technology. We argue that in the Clipper debate has concentrated on national security and individual privacy and we may have lost sight of other fundamental constitutional issues, the need to promote commerce and establish a safe and secure information highway. Businesses will not open their doors to cyberspace until we provide clean, well-lit streets in the global village. This document proposes a royalty-free licensing pool for the technology, obtaining public use of the public key patents through the use of eminent domain or other mechanisms. The document then proposes a license for users of the public key technology, the proceeds of which would be placed in an Information Highway Beautification Fund. The license allows an individual or corporation (presumably with different fees structures for each type of user) the right to use the basic public key technology. The proceeds from the license fee would be used to pay back the original patent holders and to fund public works projects on our National Information Infrastructure. A crucial aspect of this proposal is that the license plates be on a per-person basis, not on a per-certificate basis. People must be able to change their certificates on a frequent basis: the license is a right to use the technology not a fee for a single certificate. This is not an invitation to have a single government certification hierarchy or to register the certificates. The license is a right to use the technology, not an invitation to form a universal ID system or a rigid, inflexible certification bureaucracy. In fact, it is possible (and often desirable) to use the basic public key technology without using a certificate at all. Background: The Clipper Controversy The current debate on cryptography and computer security centers around two often-conflicting government functions embodied in our constitution: maintaining our national security and preserving the rights to personal privacy. The public debate on the Clipper issue has revolved around the question of whether government should have a "back door" into a cryptographic chip. Should the government be able, under appropriate court orders, to decode a conversation? Should criminals be able to hide themselves behind a mask of strong cryptography? The Clipper proposal requires government users to purchase a chip that has a special key that is kept in the custody of two government agencies, a concept known as "key escrow." Under appropriate conditions, the government can decode a conversation that was encoded using the Clipper chip. The Clipper proposals use the theory that government, by purchasing large numbers of these chips, will encourage private users to adopt the same scheme, thus leading to lower prices from higher volumes and also leading to a standard for the use of cryptography on the information highway. While the national security and law enforcement goals are clear, there are strong reasons why this proposal may not work. The efficacy of a key escrow scheme and the ability of the government to keep these crucial secrets hidden has been questioned by computer and legal experts. Civil liberties experts have questions the constitutional propriety of a back door. Leaving aside the basic constitutional issues, the idea that the government will lead through its purchasing power has been shown to be flawed in a number of other situations. In the area of the Government OSI Profiles (GOSIP), for example, NIST and other agencies attempted to lead the market through purchases but ended up far behind the technology curve as government and business alike flocked to solutions that were more practical and cost effective. Just because the government purchases lots of $600 hammers doesn't mean that corporate users will necessarily follow suit. The real problem with the Clipper debate, however, is that we have neglected some much more fundamental issues: the question of how we deal with public key cryptography. Public key cryptography, the underlying technology behind the Clipper chip, does much more than simply encrypt data, it is a building block for our information highway. The Importance of Public Key Cryptography Public key cryptography is a fundamental technology that provides a basic security fabric for the national information infrastructure. The most important function it provides is authentication, the ability to know who another person or computer or program is in cyberspace. Public key cryptography is the basic stuff from which we make streetlights for the information highway. Authentication and privacy of data are two functions of a security infrastructure, but there are others. For example, public key cryptography allows us to append a digital signature to a document, a method that allows us to verify the integrity of the document and assure the recipient that the document was not changed since it was originally generated. Public key cryptography also allows us to provide services such as non-repudiation, a way of verifying that a document was actually received (analogous to a delivery receipt from a registered letter). Public key cryptography thus provides a bundle of extremely fundamental services: authentication, privacy, message integrity, and non-repudiation, among others. This technology is so basic that it must be embodied throughout our computer networks in a way as fundamental as the deployment of steel in a building. Public key cryptography is one of the basic building blocks for computer networks. Many people feel that they need to decide how this technology should be applied. The Clipper proponents, for example, feel that public key cryptography is to be used to encrypt bits on the wire. Another community is advocating a particular style of electronic mail, known as Privacy Enhanced Mail (PEM). A building block as fundamental as public key cryptography must be deployed throughout the infrastructure. No one person or group will know in advance everywhere we need to use something so basic. Take PEM for example. Even if PEM is your messaging solution, there are a host of other applications ranging from remote login to file transfer to listening to radio or making a telephone call. The important point is that we don't know now all the ways that we use a general-purpose infrastructure. We will only know as we deploy it and we can't deploy the technology until we get the basic tools to make it secure. We cannot make security a special service. We cannot make security a government program or the responsibility of a particular group. We must build security into the very framework of the NII or the streets of the global village will remain unpopulated. Without a fundamental security infrastructure, businesses will not conduct commerce on the NII, but will have to build special-purpose networks for each function. Sharing an infrastructure is essential if we are to realize the cost savings of an information highway and even more essential if we are to provide the framework that will encourage small, mom-and-pop digital delis open their doors for business. The current policy debate ignores the fundamental economic importance of services such as authentication. We cannot open our doors for business until we can see who is knocking at the door. We can't sell a fax for two cents or a movie on demand for a dollar or do any of the fundamental transactions of an economy without this basic technology. Commerce in the real world requires a multitude of different models and methods. Cash, barter, purchase orders, credit cards, and checks are just a few of the methods. There is no reason to think that we can avoid the same real-world motley technology in cyberspace. We need to build the fundamental technologies of public key cryptography into the very fabric of our infrastructure, applying security throughout the NII at all layers. How Public Key Works To understand why public key is so fundamental, it helps to have a basic idea of how it works. The public key technology is based on two related keys: a private key and a public key. You keep your private key secret and let people know your public key. A piece of data encoded with the private key can be only decoded with the public key and vice versa. The most obvious application of this technology is privacy. I take your public key and encode a message. You have your private key and can decode the message. Alternatively, I take my own private key and encode the message. You have my public key and can decode the message. In reality, public key cryptography is a very slow way of encoding and decoding an entire message. Instead, we use public key cryptography to exchange a shared secret: a symmetric key that we both know about and use to do encoding and decoding. For example, a common encryption algorithm is the Data Encryption Standard (DES). DES is very fast, but requires both parties to know the same DES key. In a typical scheme, we would use the public key method to exchange the DES key and then use the DES key to encode the message. For example, I could generate an arbitrary DES key and hide it by encoding it with your public key. You would then "unwrap" the package with your private key and use the resulting shared secret to quickly and efficiently decode my message to you. The fundamental benefit that public key gives us is authentication: knowing who we are talking to. If I know your public key, you can use your private key to send me a "certificate." I know that only you could have generated this certificate, since I am able to decode it successfully using your public key. Certificates ultimately only work if public keys are widely deployed and well-known. The scheme proposed by many is to define a standard certificate, containing a public key and information about the certificate holder, such as the name or institutional affiliation. Validation of certificates is done using a certificate hierarchy. If there are a few very well known public key, say for the federal government or for MIT, that key combination can be used to certify other public keys. I know that your public key is really yours because MIT certifies that it is and everybody knows the MIT key. There are thus two aspects to a security infrastructure. First, there must a wide deployment of public-key based certificates. Second, there must be many different kinds of programs throughout the computer network that understand what a certificate is and how to use it. One program might use the keys as the basis for encrypting data on the wire or in an electronic mail message. Another set of services might use keys as the basis for allowing access to telecommunications service or for deciding the type of access to libraries a person should get. The Current Status of Public Key Cryptography Public key cryptography has its roots in research conducted at Stanford by Diffie and Hellman and at MIT by Rivest, Shamir, and Adleman. In both cases, the academic research efforts spun off commercial companies. In the case of Stanford, the company Cylink was formed and in the case of MIT a company called RSA Data Security, Inc. was formed. The basic patents that govern public key cryptography are thus owned by four entities: MIT, Stanford, Cylink, and RSA. Because the basic technology is so intertwined, one cannot really do effective work in the field without using pieces of several different patents. To resolve licensing problems, the four entities formed Public Key Partners, which handles licensing of the technology. A commercial entity that wants to use public key technology needs a license from Public Key Partners. Because the basic technology was developed with federal dollars, the federal government has the right to use the technology. In addition, in many international jurisdictions the technology is widely available, to the extent that the basic algorithms can be downloaded anonymously from a variety of locations. To address the question of non-commercial use, RSA has worked with the Internet Engineering Task Force on the PEM proposals. In the case of PEM, there are versions of the software that are available for federal and academic institutions. It should be noted that the reference implementation that RSA provides for non-commercial users is specifically restricted to PEM- like mail systems and does not apply to general-purpose uses of the technology. Commercial users, of course, must use a licensed version from a software developer or negotiate a license directly with Public Key Partners. Commercial entities in the United States, groups that include software developers, computer hardware companies, and telecommunications companies, must secure a license from Public Key Partners. Public Key Partners has pursued a strategy that has resulted in a number of large corporations licensing the technology, including DEC, Lotus, and many others. However, commercial deployment has been limited because of the lack of the ability to build the technology into multi-vendor standards and because of the lack of a certificate system. More importantly, small businesses have often avoided the technology because of fears of high licensing costs. To complicate matters, the National Institute of Standards and Technology (NIST) has proposed a public key standard that is related to the RSA algorithms. In order to get around potential patent conflict problems, the commercial rights to this technology go to Public Key Partners. Public Key Partners thus has an exclusive grasp on this basic technology in the commercial realm. The current patent situation is very much like the situation earlier this century for vacuum tubes and for Frequency Modulation (FM). In both those cases, the fundamental patents were so intertwined that no progress was made in the field. In both cases, the federal government stepped in to help lead us towards a solution. A Proposal: The Information Highway Beautification Fund The main problem with the current situation is that it requires every developer to obtain a license. Licenses are priced high enough that small, ad hoc developers can be easily discouraged. More importantly, it leaves the decision on how to use the technology in the hands of a few entities, such as NIST or Public Key Partners. The decision on who gets a license is an appropriate one for some technologies, but not for one as basic as public key. We need the engineers building our NII to be able to use fundamental tools without asking each time they come up with a new application. Public key cryptography is a classic public good. If we can universally deploy certificates, there is a tremendous public benefit, benefits that are not reflected in a system based on commercial licensing of monopoly patents. Public key-based certificates are the license plates for the information highway, the light that lets us know who we are talking to. While Public Key Partners may derive some benefit from selling the technology to a few large corporations, society (and under our proposal, Public Key Partners) will benefit even more from universal deployment. If we recognize the fundamental importance of this technology, there are some policy options that easily come to mind. The first policy outcome, the one essential to conducting electronic commerce on the Internet, is to make public key technology widely available. We propose here a royalty-free license pool for the public key patents. It is essential that the pool allow use of the technology without prior approval: no one bureaucracy or regulation can determine in advance how this technology can be used. Such a pool could be established by negotiation between the federal government and Public Key Partners, or could be established by more assertive techniques such as the use of eminent domain. The use of eminent domain recognizes that the patents are valuable property. Eminent domain says that your property is very nice, but unfortunately we need to build a freeway through it. Eminent domain recognizes the taking and requires the government to compensate the property owners. Eminent domain is an extreme way of reaching the goal of making the technology widely available, and there are other, less drastic solutions available. However, the key point is that the technology must become widely available to allow us to build it into the infrastructure of our information highway. Once the technology is available, we suggest that the government establish a license, a fee which is levied upon a user or corporation. We beg the question here of the format of the certificate (and feel strongly that a single certificate hierarchy or certificate format would be a grave technical and constitutional mistake). We suggest instead that the government resolve the more fundamental issue of placing the technology in an open pool and levying a per-user license fee. Once the basic principle is in place, the government can convene a set of hearings to flesh out details such as which agency collects the license fee and the fee structure. Presumably, the user fee would be a one-time fee of $100 or less and corporations would pay on a sliding scale that would encourage small enterprises. A crucial aspect of this proposal is that the license fee be on a per user basis, not on a per certificate basis. We cannot have a government hierarchy of certificates, or a requirement to keep certificates in some standard format, or to keep certificates around to allow an audit or to control how the certificate is used, In fact, there are many instances where public key technology would not use a certificate. The fee pays for a license to use the technology not a way to audit how the technology gets used. The revenues from the proposed license fee would be placed in the Information Highway Beautification Fund. Part of the proceeds of this fund would go to pay back Public Key Partners for the taking under eminent domain, and the remainder would go towards paying for public works projects on the NII. The public works part of the fund would be available to pay for things like information interstates, publicly funded information sources, and establishing equal access to the information highway from our inner cities, our hospitals, our libraries, and our schools. Making payment to Public Key Partners a function of individual and corporate fees could easily lead to a windfall for the current patent holders. We feel this is perfectly appropriate: universal deployment of public key technology will benefit society to the tune of billions of dollars. It is an enabling technology and even a few hundred million dollars going to those who established the technology is not unreasonable. While many maintain that the patents should not have been granted in the first place, we feel that this issue has already been decided and we look for creative solutions that move us beyond the current impasse. The choice we face now is a simple one. The NII is a general-purpose infrastructure, a set of streets and roads for the information superhighway. If we can't make those roads safe and secure, then business will never use them. Instead, our corporations will continue to build special-purpose infrastructures, dedicated networks for one community or another. The cost to society is orders of magnitude higher: a general-purpose infrastructure is what allows our corporations to increase their productivity and be competitive on a world market. More importantly, a general-purpose infrastructure allows new businesses to be quickly established. The information highway is crying for leadership. Our choices are policy choices, not technical ones. The Clinton/Gore administration and the current Congress have come down firmly in support of a National Information Infrastructure. Public key cryptography is an example of an area where our government can help lead us, providing the basic building blocks for an information economy. For More Information More information on the issue of public key cryptography and the Clipper issue is available from a variety of sources, including: WIRED Online Services Gopher: gopher.wired.com E-mail: infobot at wired.com ("send clipper/index" in the body) WWW: http://www.wired.com Electronic Freedom Frontier FTP: ftp.eff.org Gopher: gopher.eff.org WAIS: wais.eff.org National Institute of Standards and Technology Gopher: gopher-server.nist.gov From m5 at vail.tivoli.com Fri Mar 4 06:57:08 1994 From: m5 at vail.tivoli.com (Mike McNally) Date: Fri, 4 Mar 94 06:57:08 PST Subject: Standard for Stenography? In-Reply-To: <9403040134.AA15184@anchor.ho.att.com> Message-ID: <9403041456.AA02863@vail.tivoli.com> Sergey Goldgaber writes: > I have never heard a serious, reputable claim about the unbreakablity of > an algorithm. Maybe not, but if you've been paying atention you know of a great deal of theory that support the intractability of solving certain problems in realistic amounts of time. Most PK cryptosystems are based on relatively simple principles of mathematics. It stretches the imagination to think that the NSA somehow has solved the factoring problem; I concede it's possible, but unlikely. > The point is, that in the real world, we'll never know if our algorithms > are "good enough to withstand an opponent who has full documentation of > your algorithms and methods lots of funds, and everything except your keys." Depends on what you mean by "know", I guess. > > security-by-obscurity is a naive waste of time, > > I still don't see why. Well, you can't tell when you've been compromised, and you have no rigorous way of demonstrating the robustness of your obscurity. The real problem, however, is that you'll have a hard time convincing anybody else to participate. You can hide all your valuables in a really clever place and do all sorts of really clever secret things to protect them, and that may make you feel secure. However, you won't be able to convince me to entrust *my* valuables to you unless you explain to me the details of your techniques. -- | GOOD TIME FOR MOVIE - GOING ||| Mike McNally | | TAKE TWA TO CAIRO. ||| Tivoli Systems, Austin, TX: | | (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" | From hfinney at shell.portal.com Fri Mar 4 07:22:16 1994 From: hfinney at shell.portal.com (Hal) Date: Fri, 4 Mar 94 07:22:16 PST Subject: Security through Obscurity Message-ID: <199403041522.HAA24738@jobe.shell.portal.com> From: Sergey Goldgaber > > To sum up, obscurity is not bad. What is bad is to confuse obscurity > > with security. > > If I have understood you correctly, there is nothing wrong with equating > obscurity with a practical, albeit temporary, increase in security. > Equating obscurity with ultimate security is a mistake. As is equating a > "strong" algorithm with ultimate security. I would not put it like this. Rather, if you want a temporary increase in security, you need to calculate, or at least assume, how much extra time it will take for your opponent to defeat your temporarily-secret information. Just saying, "oh, well this complication ought to slow him down some, heh hey," doesn't cut it. Again, you need to be explicit about exactly what information you are keeping temporarily secret, and how long you expect it to be kept secret. > > In encryption, the opponent's desire is to find out the original message. > > What is the opponent's desire in steganography? I feel it is to be able > > to prove or determine with some degree of certaintly that there is a > > hidden message. We use steganography in a context where sending such a > > message openly is for some reason undesirable. Hence our goal is to > > prevent the opponent from knowing that a message exists. > > I would like to propose that there is a goal, in addition to those you have > revealed, for the opponent as well as the legitimate user of steganography. > The opponent would, ideally, wish to not only determine that there is a > message within the data; in addition, he would prefer to be able to extract > that message for analysis. Therefore, I believe that it would be to the > advantage of the stego-user to not only hide the existence of his message, > but to do so in such a way that the cost of successfully extracting that > message, by his opponent, is maximized. > I think this is a plausible, although less ambitious, goal. But what's this about "maximizing cost"? Where does that fit into the analysis? This does not tell you whether your "maximization" has actually helped or not. Instead, if you are going to adopt this goal, this means that the test of your steganography is whether the opponent can extract the message. It's not that your goal is to "maximize his difficulty". It's that your goal is to stop him. Again, NoStO emphasizes clear statements of your goals and costs. (The reason I say this is less ambitious is that if the opponent can determine there is a message, but not what it is, they may be able to bring penalties to bear on those communicating, depending on the circum- stances. For example, finding a stego'd file on someone's hard disk might represent probable cause that illegal encryption was used, in some hypothetical future.) > I have to take exception with the assertions made in this paragraph. > Using the principles of public-key systems, the steganography key itself > does not have to be kept secret. The sender, reciever, and indeed the > opponent would all have access to this key without compromising the > security of the system. The challenge, for the opponent, lies in figuring > out which public-key the sender has used. I have no statistics on > exactly how difficult this challenge would prove; but, considering the > number of public-keys currently availiable and projecting several years > into the future, the challenge may be a very significant one. What key are you talking about here? The public one? That is not secret. As you say, the opponent has access to it. Are you assuming that the opponent cannot guess which public key was used? How will you measure the accuracy of this assumption without statistics? I really don't think you have understood my essay. The point, again, of avoiding StO is to make it clear what you are keeping secret, and to count the costs of keeping it secret. If you are counting on keeping secret the recipient of the message then you have these costs: Any stego files found in the recipient's possession are broken. Stego files can be exhaustively searched against a list of public keys. If a particular group or person is targeted for surveillance his keys can be used against all widely-known stego channels. Further, your own test is so weak (inability to recover the actual message) you have not attempted to make it impossible to guess when you have recovered the message, even with the correct key information. So in each of the cases above the authorities know when they have the message in hand. Now if you are tempted to say that this isn't true, because we could arrange for the message ALSO to be unrecognizable even when successfully recovered (so that the opponents don't know when they have recovered it) then you have missed the whole point. You earlier rejected this test. If you had accepted it, you wouldn't have needed your keys at all. Hal From jef at ee.lbl.gov Fri Mar 4 07:22:43 1994 From: jef at ee.lbl.gov (Jef Poskanzer) Date: Fri, 4 Mar 94 07:22:43 PST Subject: How to do encrypted telnet without being root (tutorial, includes src) Message-ID: <9403041521.AA17537@hot.ee.lbl.gov> That's quite interesting, but it sure looks like it's unable to encrypt the only part of the session that I really want to encrypt: the password. --- Jef From hughes at ah.com Fri Mar 4 07:33:46 1994 From: hughes at ah.com (Eric Hughes) Date: Fri, 4 Mar 94 07:33:46 PST Subject: Mail server for crypto files on csn.org? In-Reply-To: <9402037627.AA762722747@smtplink.exabyte.com> Message-ID: <9403041524.AA03606@ah.com> >Could someone send me source code for >any automatic mail handling programs they have written for a Sun host, or >perhaps point me at some good documentation? The standard cypherpunks remailer code, availabe on soda, is already an automatic mail handling program. All the basic principles for setting up a mail server out of a user account are contained therein. Eric From hughes at ah.com Fri Mar 4 07:48:21 1994 From: hughes at ah.com (Eric Hughes) Date: Fri, 4 Mar 94 07:48:21 PST Subject: Standard for Stenography? In-Reply-To: <9403040154.AA16047@hot.ee.lbl.gov> Message-ID: <9403041538.AA03626@ah.com> >Eli makes a reasonable case for leaving out the length field >altogether. The desteg program would produce a file of width*height >bits, and it would be up to the next layer to produce text from that. >However, I'm not sure it's a *compelling* case. A steganography program that uses a shared permutation and bit selection schedule on each end is really a symmetric key cipher with data expansion. And because it is a cipher, it is subject to the ITAR. Adding noise intermixed with a signal is a perfectly good way of doing full scale cryptography, it's just that folks these days tend to prefer methods that don't have bandwidth explosion. In fact, bandwidth expansion is only of the few ciphers that has provable information theoretic properties, mostly because the method is simple enough for the basic results of information theory to apply. Hiding encrypted text, which already has high entropy over various word partitions, with an arbitrary embedding in random bits does provably increase the security of the cipher. I would urge Jef to write the code and then submit a Commodities Jurisdiction request to see if the code is exportable. Eric From mdbomber at w6yx.stanford.edu Fri Mar 4 07:56:18 1994 From: mdbomber at w6yx.stanford.edu (mdbomber at w6yx.stanford.edu) Date: Fri, 4 Mar 94 07:56:18 PST Subject: CA meeting Message-ID: <199403041556.AA09830@nebula.acs.uci.edu> Is the CA Cypherpunks meeting on Saturday, 12 March? I want to try to go to it. Internet: mdbomber at w6yx.stanford.edu Matt Bartley GPS: 33 49' xx'' 117 48' xx'' (xx due to SA :-) From russw at netcom.com Fri Mar 4 08:06:57 1994 From: russw at netcom.com (Russell Earl Whitaker) Date: Fri, 4 Mar 94 08:06:57 PST Subject: UK cypherpunks ready to meet at 2000 or 2200 on 12 March? Message-ID: <199403041607.IAA03098@mail.netcom.com> To the UK participants on the cypherpunks list, and particularly those in the southeast (London, Kent, Essex, etc): Are any of you interested in holding a meeting synchronous with the physical/teleconference meeting of 12 March in Mountain View, CA and other US locations? Regardless of the technical arrangements, I can guarantee a venue that day in London for you. If you decide to go the way of a brief telephone call-in from London, I will pay for the call. If interested, let me know immediately, and I'll make calls to those nearby who are not on the list, but who are interested and sympathetic. Cheers, Russell Russell Earl Whitaker russw at netcom.com Director, Extropy Institute 408-366-5435 ================================================================ From wln at tla.org Fri Mar 4 08:39:21 1994 From: wln at tla.org (W Lee Nussbaum) Date: Fri, 4 Mar 94 08:39:21 PST Subject: CFP roomshare... Message-ID: <9403041619.AA09505@nmi.tla.org> I know this is not quite appropriate to this list, but here goes: Is anyone going to Computers, Freedom, & Privacy 4 in Chicago later this month, and interested in splitting a room to keep costs down? Please mail me at wln at tla.org if you are interested. Thanks. - Lee From exabyte!smtplink!mikej at uunet.UU.NET Fri Mar 4 08:44:18 1994 From: exabyte!smtplink!mikej at uunet.UU.NET (exabyte!smtplink!mikej at uunet.UU.NET) Date: Fri, 4 Mar 94 08:44:18 PST Subject: How to clear sign messages with PGP (FAQ) Message-ID: <9402047628.AA762802615@smtplink.exabyte.com> -----BEGIN PGP SIGNED MESSAGE----- > How do you get those great signatures on your posts? > > I've been trying to do this with PGP, but I only get a signature file. This > file seems to be a binary file or just a signature. I'll use a command > like: pgp -s filename. > > Perhaps your using a shell? No, I just use this MS-DOS batch file called sign.bat: pgp -sta +clearsig=on %1 The %1 expands to the first argument on the command line. To sign a text file called toscott.txt, I just give the command sign toscott.txt When you get a message signed like that, you should be able to verify the signature by simply executing pgp on the file you get (provided you have my key -- it is on the key servers, available by finger mpj at csn.org or mpjohnso at nyx.cs.du.edu, ftp://csn.org/mpj/mpj4.asc, or on my BBS (303-938-9654): pgp frommpj.txt For more pgp tricks, see the FAQ ftp://netcom.com/gbe/ (echoed on ftp://csn.org/mpj/public/pgp/) or on the Colorado Catacombs BBS. ___________________________________________________________ |\ /| | | | | \/ |o| | Michael Paul Johnson Colorado Catacombs BBS 303-938-9654 | | | | / _ | mpj at csn.org ftp csn.org \mpj\README.MPJ for access info.| | |||/ /_\ | aka mpjohnso at nyx.cs.du.edu mikej at exabyte.com | | |||\ ( | m.p.johnson at ieee.org CIS 71331,2332 VPGP key by finger | | ||| \ \_/ |___________________________________________________________| -----BEGIN PGP SIGNATURE----- Version: 2.4 iQCVAgUBLXdfdj9nBjyFM+vFAQEkDAQA0sp3qwbXBcp9F4LhtHaLCtag0LKXR1XQ 6hlNsE+M5KIZzLBYcQirlMY0qQKeKwXg9SE3kPs/m/hBySsGbFMqVh0OBSVNjT8a 9QizZB2MZQg+oh91eyNq+Ys5SG04TeOCQtW5UtKdqD4Pe+Teb7UIJxbCq+gGaQ0O Ba1dF1DC8/4= =6W/G -----END PGP SIGNATURE----- From gtoal at an-teallach.com Fri Mar 4 08:57:41 1994 From: gtoal at an-teallach.com (Graham Toal) Date: Fri, 4 Mar 94 08:57:41 PST Subject: How to do encrypted telnet without being root (tutorial, includes src) Message-ID: <199403041657.QAA29092@an-teallach.com> That's quite interesting, but it sure looks like it's unable to encrypt the only part of the session that I really want to encrypt: the password. --- Jef True - that's why I suggested using one-time passwords before you get to that stage. I'm using s/key myself. If you can't install s/key checking in login, you can use an s/key shell as a user process (assuming you can change your shell that is). By the way, S/Key *doesn't* need an intelligent card - you can do what I do and print off 100 passwords small on a credit-card slip. I fetched it as soon as I discovered this. It's not a perfect system but it helps. G From CCGARY at MIZZOU1.missouri.edu Fri Mar 4 09:21:05 1994 From: CCGARY at MIZZOU1.missouri.edu (Gary Jeffers) Date: Fri, 4 Mar 94 09:21:05 PST Subject: Standards for Stenography/Steganography? Message-ID: <9403041720.AA04101@toad.com> Tim May says that the criticism I received was mild. It was not that mild. I am particularly incensed by Poskanzer's suggestion that I fetch the old information when, it turns out, that info was not available. That was bullshit! Anyway, hopefully, Poskanzer's technical skills are great & he will pull a giant rabbit out of the hat. In our defense, I would guess that Sergey had the same idea that I had: "Steganography! a hide in plain sight, travel casually in day- light, leave no footprints, safe long term storage, last-ditch, safe crypt. & , apparently, no one's working on IBM micro implementations! What an opportunity to make a contribution! If we don't write the code I'll bet we can provoke a really good programmer with crypt knowledge to do it." It would be difficult for us to know that this area was already discussed, tactics pretty much resolved, & had big old guns working on it without them telling us. Thank God the big old guns were there to disabuse us of our pipe dreams & illusions! I'm pretty irreverent, but I do have a lot of respect for the really smart guys who are sacrificing huge chunks of time in writing code & theory to free us as well as themselves. It takes me many hours per week to deal with cypherpunks mailing list. So, I can understand how the big old guns can get bothered by newbies farming old ground & taking up lots of bandwidth while mudding the water. With that said, & having a lot less to say that I thought I had, I shall go back to a higher LURK/BANDWIDTH ratio & stop annoying people. As Johnathan Winter's mother used to say: "If you can't be bright, be polite." also quiet? Yours Truly, Gary Jeffers From hughes Fri Mar 4 09:26:41 1994 From: hughes (Eric Hughes) Date: Fri, 4 Mar 94 09:26:41 PST Subject: No Subject Message-ID: <9403041726.AA04171@toad.com> Date: Wed, 2 Mar 1994 09:14:40 -0800 From: Hal Sender: hughes at toad.com Message-Id: <199403021714.JAA17114 at jobe.shell.portal.com> To: cypherpunks at toad.com Subject: Re: Insecurity of public key crypto #1 (reply to Mandl) [Maintainer's note: Sometimes the subscribe filter for majordomo works too well. This message came in a couple of days ago, got filtered, and I've finally figured out how to massage majordomo into getting it out into the list. Sorry about that, Hal.--EH] I run a simple script which will provide the Cypherpunks list in encrypted form. Send me your email address and a PGP public key and I will add you to the list. Once you have it working nicely you can then unsubscribe from the regular list (I can't unsubscribe you from the regular list). Interestingly enough, I have been doing this for about a year, and in that time about ten people have asked to sign up (I haven't publicized it heavily). All but two have asked to be removed within a week, saying that it was too much hassle to deal with that volume of incoming encrypted mail! Let me know if you want to try it. Hal Finney hfinney at shell.portal.com From CCGARY at MIZZOU1.missouri.edu Fri Mar 4 11:09:47 1994 From: CCGARY at MIZZOU1.missouri.edu (Gary Jeffers) Date: Fri, 4 Mar 94 11:09:47 PST Subject: Standards for Stenography? Message-ID: <9403041909.AA05455@toad.com> Tim May says that the criticism I received was mild. It was not that mild. I am particularly incensed by Poskanzer's suggestion that I fetch the old information when, it turns out, that info was not available. That was bullshit! Anyway, hopefully, Poskanzer's technical skills are great & he will pull a giant rabbit out of the hat. In our defense, I would guess that Sergey had the same idea that I had: "Steganography! a hide in plain sight, travel casually in day- light, leave no footprints, safe long term storage, last-ditch, safe crypt. & , apparently, no one's working on IBM micro implementations! What an opportunity to make a contribution! If we don't write the code I'll bet we can provoke a really good programmer with crypt knowledge to do it." It would be difficult for us to know that this area was already discussed, tactics pretty much resolved, & had big old guns working on it without them telling us. Thank God the big old guns were there to disabuse us of our pipe dreams & illusions! I'm pretty irreverent, but I do have a lot of respect for the really smart guys who are sacrificing huge chunks of time in writing code & theory to free us as well as themselves. It takes me many hours per week to deal with cypherpunks mailing list. So, I can understand how the big old guns can get bothered by newbies farming old ground & taking up lots of bandwidth while mudding the water. With that said, & having a lot less to say that I thought I had, I shall go back to a higher LURK/BANDWIDTH ratio & stop annoying people. As Johnathan Winter's mother used to say: "If you can't be bright, be polite." also quiet? Yours Truly, Gary Jeffers From koontzd at lrcs.loral.com Fri Mar 4 11:56:08 1994 From: koontzd at lrcs.loral.com (David Koontz ) Date: Fri, 4 Mar 94 11:56:08 PST Subject: Soundblaster for Secure Voice Message-ID: <9403041955.AA10311@io.lrcs.loral.com> Any number of persons had mentioned the use of a SoundBlaster board for use in a secure voice application for PCs. In the February 17, 1994 issue of EDN, there is an article entitled 'Speech-synthesis and -recognition chips personalize consumer products' by John Gallant, Tecnical Editor, starting on P. 27. There is a company mentioned, ESS Technology, Fremont CA, (510)226-1088, that produces two Sound Blaster register level compatible chips, the ESS488 (without music synthesis) and ESS1488 (with music synthesis). The ESS1488 will run on 3.3 or 5 volt Vdd, and appears to be intended for portable computer applications. Cost per ESS1488 is $18 (presumeably in quantity). From banisar at washofc.cpsr.org Fri Mar 4 12:05:43 1994 From: banisar at washofc.cpsr.org (Dave Banisar) Date: Fri, 4 Mar 94 12:05:43 PST Subject: FWD>CPSR Alert 3.05 Message-ID: <00541.2845637557.4226@washofc.cpsr.org> >From CPSR FWD>CPSR Alert 3.05 ============================================================== @@@@ @@@@ @@@ @@@@ @ @ @@@@ @@@@ @@@@@@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @@@ @ @@@ @@@@@ @ @@@ @@@ @ @ @ @ @ @ @ @ @ @ @ @ @ @@@@ @ @@@ @ @ @ @ @@@@ @@@@ @ @ @ ============================================================= Volume 3.05 March 3, 1994 ------------------------------------------------------------- Published by Computer Professionals for Social Responsibility Washington Office (Alert at washofc.cpsr.org) ------------------------------------------------------------- Contents [1] Welcome to the CPSR Alert [2] FBI Digital Telephony Bill Returns [3] Clipper Petition Passes 40,000 Signatures [4] Clipper and Cantwell [5] FCC and Electronic Mail [6] NTIA Privacy Inquiry [7] DIAC Conference Announcement [8] New Files at the CPSR Internet Library [9] Upcoming Conferences and Events ------------------------------------------------------------- [1] Welcome to the CPSR Alert We should take a moment to welcome the new readers of the CPSR Alert. In the last month, the number of subscribers has more than tripled. We'd like to thank you for your interest in CPSR and tell you about a few more services available. If you have FTP/Gopher/WAIS access you should explore the CPSR Internet Library at CPSR.ORG. There is a wide range of materials covering Clipper, civil liberties, information policy and the NII. Many of the Administration's materials are available from CPSR.ORG. We also provide archives for the Taxpayers Assets Projects, Privacy International, and the Cypherpunks mailing list. If you are interested in Clipper and other civil liberties issues, you should consider attending the Computers, Freedom & Privacy conference in Chicago, March 23-26. CPSR sponsored the first CFP in 1991. It is now a leading event for people interested in civil liberties and privacy. (see calendar for more information). In April, CPSR is sponsoring a two-day conference on the National Information Infrastructure at MIT. Featured speakers include Benjamin Barber, Herb Schiller and Tom Grudner. (see section 7 for more information). If you are interested in NII policy, you might want to get a copy of the CPSR NII report, "Serving the Community: A Public Interest Vision of the NII." The report is based on a series of principles developed by the Telecommunications Policy Roundtable and provides a very useful overview of the NII policy debate. The paper is available electronically by sending email to listserv at cpsr.org. In the message body write the command "GET CPSR NII_POLICY" (no quotes). The paper will automatically be mailed to you. You can also get the paper through ftp/wais/gopher at cpsr.org/nii/cpsr_nii_policy.txt. To request a paper copy (about 30 pages) send email to cpsr at cpsr.org. Welcome again to the CPSR Alert. ------------------------------------------------------------- [2] FBI Digital Telephony Bill Returns The Federal Bureau of Investigation has reintroduced its controversial 1992 proposal to require that communications service providers redesign their equipment to facilitate electronic surveillance. The Bureau has sent a draft to Congress but so far, no Senator or Congressperson has stepped forward to sponsor it. The draft bill, ironically named the Digital Telephony and Communications Privacy Improvement Act of 1994, mandates that common carriers (phone, cable and computer network companies) modify their switches and computers to ensure that surveillance can be conducted concurrently from a remote government facility. It requires that manufacturers and support companies assist carriers. In an addition to the 1992 bill, the 1994 bill also mandates that systems be designed to collect transactional information that users generate and make that information available to law enforcement agencies. This information includes data on calls made and received. Under the NII, future information collected may include all manner of transactions, including purchases, financial and medical information. Any company that fails to comply with the requirements of the bill would be fined $10,000/day and shut down. Companies would have three years from the date of enactment to comply. The Attorney General would have the authority to enact these penalties and would be encouraged to cooperate with the Federal Communication Commission. The FCC would issue rules to cover the cost of complying with the procedures. An internal FBI memo released to CPSR under a Freedom of Information Act lawsuit estimates the cost of compliance at $300 million. Communications Daily reports that other experts have estimated that the cost will be over one billion dollars. The bill also revises sections of the Electronic Communications Privacy Act to extend the legal protection of ECPA to cordless phones and clarifies ECPA to allow for monitoring of computer systems by system managers. The 1992 bill was never formally introduced due to lack of a sponsor after industry, civil liberties groups and the public criticized it. Copies of the 1994 and 1992 drafts are available from the CPSR Internet Library. (see below for details). Also available are educational materials about the Digital Telephony proposal. To obtain a video copy of the ABC Nightline special on the original FBI proposal, send $14.98 plus 3.98 s/h to MPI Home Video, 15825 Rob Roy Dr., Oak Forest, IL 60452 and request a copy of the 5/22/92 program "FBI Pushes for Wiretap Powers." The program features a debate between former FBI Director William Sessions and CPSR Washington Director Marc Rotenberg. Available from CPSR is a 450-page sourcebook of materials on privacy and cryptography, including the materials on the original digital telephony proposal with commentary. The CPSR Sourcebook is available for $50. Send a check to CPSR, 666 Pennsylvania Ave., SE, Suite 301, Washington, DC 20003 --------------------------------------------------------------- [3] Clipper Petition Passes 40,000 The CPSR Internet Petition to oppose the Clipper Proposal has now passed 40,000 signatures. The petition has been signed by users at over 2,600 sites, including 1,100 companies and 800 colleges. For specific sites, MIT has the highest single vote tally, with over 600 messages. Messages continue to arrive at a rate of over 1,000 per day. To sign on to the letter, send a message to: Clipper.petition at cpsr.org with the text "I oppose Clipper" (no quotes) You will receive a return message confirming your vote. To obtain a copy of the petition, email a blank message to petition-info at cpsr.org For more information on Clipper, email clipper-info at cpsr.org. You will receive a copy of the Clipper FAQ. Thanks for your help. --------------------------------------------------------------- [4] The Cantwell Bill and Clipper We've received several inquiries concerning H.R. 3627, Rep. Maria Cantwell's bill to liberalize export controls on encryption software. Some people have been given the impression that the Cantwell bill is a response to the Administration's Clipper initiative and that passage of the legislation would effectively put the Clipper issue to rest. Because of the confusion surrounding this proposed legislation, we think it's important to provide some clarifying information. Rep. Cantwell introduced H.R. 3627 on November 22, 1993. Her comments on the purpose of the legislation appeared in the Congressional Record on November 24, 1993, at Volume 139, Page 3110. According to Rep. Cantwell: The legislation I am introducing today is needed to ensure that American companies do not lose critical international markets to foreign competitors that operate without significant export restrictions. Without this legislation, American software companies, some of America's star economic performers, have estimated they stand to lose between $6 and $9 billion in revenue each year. American hardware companies are already losing hundreds of millions of dollars in lost computer system sales because increasingly sales are dependent on the ability of a U.S. firm to offer encryption as a feature of an integrated customer solution involving hardware, software, and services. * * * This legislation takes some important steps to resolve a serious problem facing some of our most dynamic industries. It would give the Secretary of Commerce exclusive authority over dual use information security programs and products, eliminates the requirement for export licenses for generally available software with encryption capabilities, and requires the Secretary to grant such validated licenses for exports of other software with encryption capabilities to any country to which we already approve exports for foreign financial institutions. * * * My legislation is straightforward. It would allow American companies to sell the commercial software they develop in the United States to their overseas customers including our European allies -- something that is very difficult if not impossible under present policies. Rep. Cantwell's remarks contained no reference to the Administration's Clipper initiative, which had first been announced some seven months earlier. Indeed, there is no provision in H.R. 3627 that would in any way rescind the Administration's recent decision to adopt key-escrow Clipper technology as the government encryption standard. The legislation would do precisely what Rep. Cantwell said it would do -- relax restrictions on the export of strong encryption products outside of the United States. Some have suggested that passage of the Cantwell bill would create an environment in which it is less likely that Clipper will become the de facto encryption standard within the United States. This view was expressed by the Electronic Frontier Foundation (EFF) and several large corporations in a letter to the President last December which expressed "tentative" support for Clipper on a "voluntary" basis. CPSR dissented from this position in a subsequent letter to the President and expressed its opposition to the Clipper proposal under any circumstances. While it is possible that the Cantwell legislation would make it less likely that Clipper will become the de facto privacy standard, such a result is by no means a certainty. It is, in fact, possible that passage of the legislation would provide better U.S. encryption products overseas than would be available within the United States -- particularly if, as many fear, Clipper eventually becomes a mandatory standard in this country. We believe that the Cantwell bill is a step in the right direction, as it would remove current disincentives to the development of strong encryption products by U.S. companies. But the proposed legislation is not a panacea -- it would not address the threat to privacy in the United States created by the Clipper initiative. Export controls on cryptography are a related issue, but they are not central to the Clipper controversy. The Administration's adoption of the key-escrow Clipper standard must be opposed and reversed. --------------------------------------------------------------- [5] FCC and Electronic Mail [Note: The Taxpayers Assets Project is circulating a letter to encourage public participation in FCC proceedings through the Internet. CPSR has endorsed the letter and encourages other organizations and individuals to support this effort. Please repond by March 15.] SIGNATURES NEEDED FOR LETTER ASKING THAT INTERNET BE USED TO BROADEN DEMOCRATIC DEBATE OVER FCC PROCEEDING The following is a letter that will be sent to Reed Hundt, the Chair of the FCC, asking that the FCC use the Internet to broaden democratic participation in FCC proceedings. Specifically, Hundt is asked to 1) set up listserves for discussions of FCC rulemakings and inquiries, 2) accept public comments by electronic mail, and 3) provide easier access to the new FCC.GOV internet node. If you are willing to sign the letter, send the following information to Michael Ward of the Taxpayer Assets Project at: Internet: TAP at ESSENTIAL.ORG Fax: 202/234-5176 Postal: P.O. Box 19367, Washington, DC 20036 Voice: 202/387-8030 Name: _________________________ Affiliation: _________________________ (Optional, will be listed as: for purposes of identification only) Postal Address:__________________________ __________________________ __________________________ Voice: __________________________ Internet: __________________________ -------------------------------------------- March 15, 1994 Honorable Reed Hundt Chairman, Federal Communications Commission 1919 M Street, Room 814 Washington, D.C. 20554 Dear Chairman Hundt: We are writing to ask that you use the Internet to broaden opportunities for democratic participation in FCC proceedings. We applaud the FCC for its recent announcement that it has established FCC.GOV as an Internet node, and that the FCC Daily Digest is now available for free by ftp from FCC.GOV. We were also pleased that you have asked the FCC staff to examine methods and procedures for accepting comments on FCC dockets electronically. The measures discussed below would build on your efforts, and are intended to make it easier and less costly for citizens to follow the FCC's work. 1. The FCC should provide Internet electronic mail discussion "lists" on all FCC rulemakings and inquiries. Citizens should be able to sign up for a proceeding by sending a message to the FCC.GOV listserve, with a simple message such as "subscribe pcs-auction-rules-93-253." These Internet discussion lists use today's technology to empower citizens, by enhancing their ability to follow important policy debates. In an Internet discussion list, a citizen can send a message to the FCC listserve, and that message will be echoed to every subscriber on the list. The persons receiving the message will have an opportunity to respond, and a real dialogue can take place. As discussions and debates on the Internet email lists unfold, citizens will have opportunities to gain a much deeper understanding of the issues raised in the proceedings, and how they will be affected by the FCC's actions. 2. In considering methods for accepting comments from the public in FCC dockets, the Commission should provide citizens the opportunity to file comments via electronic mail which is gatewayed through the Internet. These comments should be separate from the dialogue on the discussion lists, and reflect the commentors final views on the subject matter. Several federal agencies now provide opportunities to file comments by electronic mail. For example, OMB's Office of Information and Regulatory Affairs (OIRA), began accepting comments on its Circular A-130 by electronic mail in 1992. 3. As you have already indicated, it will be important that the FCC take steps to ensure that the use of electronic communications is consistent with the legal requirements that the public record be complete and accessible. We understand that the Commission will have to devise ways of ensuring that this broadened public dialogue becomes part of the public record and is in compliance with the Administrative Procedures Act. The Commission should make these comments available to the public both online and through the FCC's reading room. 4. Many citizens can access the Internet via electronic mail, but do not have access to ftp or gopher technologies. Thus, it would be very helpful if the FCC.GOV would provide an "email ftp" service for obtaining files from FCC.GOV, as well as an ability to subscribe to the Daily Digest through electronic mail. Of all the vaunted promises of the information superhighway, the most important is that new information technologies provide opportunities to enhance democratic processes. One of the most important and valuable aspects of the Internet has been its role in restoring civic discourse on a wide range of issues. By adopting these recommendations, the FCC will gain a deeper understanding of the opportunities for enhanced democratic discourse, and it will broaden citizen opportunities to participate in debates over FCC policies. Sincerely, James Love, Taxpayer Assets Project Jeff Chester, Center for Media Education Marc Rotenberg, Computer Professionals for Social Responsibility ---------------------------------------------------------------------- James Love, Taxpayer Assets Project; internet: love at essential.org P.O. Box 19367, Washington, DC 20036; v. 202/387-8030; f. 202/234-5176 12 Church Road, Ardmore, PA 19003; v. 215/658-0880; f. 215/649-4066 ---------------------------------------------------------------------- --------------------------------------------------------------- [6] NTIA Privacy Inquiry DEPARTMENT OF COMMERCE National Telecommunications and Information Administration [Docket No. 940104-4004] Inquiry on Privacy Issues Relating to Private Sector Use of Telecommunications-Related Personal Information AGENCY: National Telecommunications and Information Administration (NTIA), Commerce ACTION: Notice of Inquiry; Request for Comments SUMMARY: NTIA is conducting a comprehensive review of privacy issues relating to private sector use of telecommunications-related personal information associated with the National Information Infrastructure. Public comment is requested on issues relevant to such a review. After analyzing the comments, NTIA intends to issue a report, which may make recommendations to the Information Infrastructure Task Force and Congress in the area of telecommunications and information policy, as appropriate. DATES: Comments should be filed on or before March 30, 1994, to receive full consideration. ADDRESS: Comments (seven copies) should be sent to the Office of Policy Analysis and Development, NTIA, U.S. Department of Commerce, 14th St. and Constitution Ave., N.W., Room 4725, Washington, D.C. 20230. FOR FURTHER INFORMATION CONTACT: Carol Mattey or Lisa Leidig, Office of Policy Analysis and Development, 202-482- 1880. AUTHORITY: National Telecommunications and Information Administration Organization Act of 1992, Pub. L. No. 102- 538, 106 Stat. 3533 (1992) (to be codified at 47 U.S.C. s. 901 et seq.). A full copy of the notice is available at the CPSR Internet Library (see below for details). --------------------------------------------------------------- [7] DIAC Announcement "Developing an Equitable and Open Information Infrastructure" Directions and Implications of Advanced Computing (DIAC-94) Symposium Cambridge, MA, USA April 23 - 24, 1994 Benjamin Barber on Electronic Democracy Herbert Schiller on Media Control and Alternative Programming Tom Grundner on Grassroots Networking The National Information Infrastructure (NII) is being proposed as the next-generation "information superhighway" for the 90's and beyond. Academia, libraries, government agencies, as well as media and telecommunication companies are involved in the current development. Computer Professionals for Social Responsibility (CPSR) and other organizations believe that critical issues regarding the use of the NII deserve increased public visibility and participation and are using the DIAC Symposium to help address this concern. The DIAC-94 symposium is a two-day event and will consist of presentations on the first day and workshops on the second day. The DIAC Symposia are held biannually and DIAC-94 will be CPSR's fifth such conference. We encourage your participation both through attending and through conducting a workshop. Sponsored by Computer Professionals for Social Responsbility Co-sponsored by the Internet Society and the MIT Communications Forum. Other co-sponsors are being sought. Please contact us if your organization would like to help with this event. For more information on co-sponsorship or on general issues, contact conference chair, Coralee Whitcomb, cwhitcom at bentley.edu. ------------------------------------------------------------- [8] New Files at the CPSR Internet Library Dr. Dorothy Denning's paper presenting the law enforcement view of cryptography and privacy issues. /cpsr/privacy/crypto/ denning_crypto_law_enforcement_feb_94.txt NTIA Call for Comments on Privacy Issues related to Private Sector use of Telecommunications Related Information. /cpsr/privacy/misc_privacy/ntia_privacy_comments_notice_feb_94.txt The inaptly named FBI Digital Telephony and Communications Privacy Act of 1994, Feb 1994 draft. /cpsr/privacy/communications/wiretap/ fbi_wiretap_bill_draft_feb_94.txt The CPSR Internet Library is a free service available via FTP/WAIS/Gopher/listserv from cpsr.org:/cpsr. Materials from Privacy International, the Taxpayers Assets Project and the Cypherpunks are also archived. For more information, contact ftp-admin at cpsr.org. ---------------------------------------------------------------- [9] Upcoming Conferences and Events "Computers, Freedom and Privacy 94." Chicago, Il. March 23-26. Sponsored by ACM and The John Marshall Law School. Contact: George Trubow, 312-987-1445 (CFP94 at jmls.edu). Directions and Implications of Advanced Computing (DIAC)-94 "Developing an Equitable and Open Information Infrastructure" Cambridge, MA. April 23 - 24, 1994. Sponsored by CPSR. Contact: cwhitcomb at bentley.edu or doug.schuler at cpsr.org. Computer-Human Interaction 94. Boston, Mass. April 24-28. Sponsored by ACM. Contact: 214-590-8616 or 410-269-6801, chi94office.chi at xerox.com "Navigating the Networks." 1994 Mid-Year Meeting, American Society for Information Science. Portland, Oregon. May 22 - 25, 1994. Contact: rhill at cni.org Rural Datafication II: "Meeting the Challenge of Providing Ubiquitous Access to the Internet" Minneapolis, Minnesota. May 23-24, 1994. Sponsored by CICNet & NSF. Contact: ruraldata-info-request at cic.net. Send name, mailing address and e-mail address. "Information: Society, Superhighway or Gridlock?" Computing for the Social Sciences 1994 Conference (CSS94). University of Maryland at College Park. June 1-3, 1994. Contact: Dr. Charles Wellford 301-405-4699, fax 301-405-4733, e-mail: cwellford at bss2.umd.edu. Abstracts for papers due March 1. Contact William Sims Bainbridge (wbainbri at nsf.gov). Grace Hopper Celebration of Women in Computer Science. Washington, DC June 9-11. Contact: 415 617-3335, hopper-info at pa.dec.com DEF CON ][ ("underground" computer culture) "Load up your laptop muffy, we're heading to Vegas!" The Sahara Hotel, Las Vegas, NV. July 22-24, Contact: dtangent at defcon.org. Conference on Uncertainty in AI. Seattle, WA. July 29-31. Contact: 206-936-2662, heckerma at microsoft.com. Symposium: An Arts and Humanities Policy for the National Information Infrastructure. Boston, Mass. October 14-16, 1994. Sponsored by the Center for Art Research in Boston. Contact: Jay Jaroslav (jaroslav at artdata.win.net). Third Biannual Conference on Participatory Design, Chapel Hill, North Carolina, October 27-28, 1994. Sponsored by CPSR. Contact: trigg at parc.xerox.com. Submissions due April 15, 1994. (Send calendar submissions to Alert at washofc.cpsr.org) ======================================================================= To subscribe to the Alert, send the message: "subscribe cpsr-announce " (without quotes or brackets) to listserv at cpsr.org. Back issues of the Alert are available at the CPSR Internet Library FTP/WAIS/Gopher cpsr.org /cpsr/alert and on America Online in the Mac Telecomm folder. Computer Professionals for Social Responsibility is a national, non-partisan, public-interest organization dedicated to understanding and directing the impact of computers on society. Founded in 1981, CPSR has 2000 members from all over the world and 23 chapters across the country. Our National Advisory Board includes a Nobel laureate and three winners of the Turing Award, the highest honor in computer science. Membership is open to everyone. For more information, please contact: cpsr at cpsr.org or visit the CPSR discussion conferences on The Well (well.sf.ca.us) or Mindvox (phantom.com). ======================================================================= CPSR MEMBERSHIP FORM Name ___________________________________________________________ Address ___________________________________________________________ ___________________________________________________________ City/State/Zip _____________________________________________________ Home phone _____________________ Work phone ______________________ Company ___________________________________________________________ Type of work ______________________________________________________ E-mail address _____________________________________________________ CPSR Chapter __ Acadiana __ Austin __ Berkeley __ Boston __ Chicago __ Denver/Boulder __ Los Angeles __ Loyola/New Orleans __ Madison __ Maine __ Milwaukee __ Minnesota __ New Haven __ New York __ Palo Alto __ Philadelphia __ Pittsburgh __ Portland __ San Diego __ Santa Cruz __ Seattle __ Washington, DC __ No chapter in my area CPSR Membership Categories __ $ 75 REGULAR MEMBER __ $ 50 Basic member __ $ 200 Supporting member __ $ 500 Sponsoring member __ $1000 Lifetime member __ $ 20 Student/low income member __ $ 50 Foreign subscriber __ $ 50 Library/institutional subscriber (Corporate memberships also available) Additional tax-deductible contribution to support CPSR projects: __ $50 __ $75 __ $100 __ $250 __ $500 __ $1000 __ Other Total Enclosed: $ ________ Make check out to CPSR and mail to: CPSR P.O. Box 717 Palo Alto, CA 94301 ------------------------ END CPSR Alert 3.05 ----------------------- From jim at bilbo.suite.com Fri Mar 4 12:06:36 1994 From: jim at bilbo.suite.com (Jim Miller) Date: Fri, 4 Mar 94 12:06:36 PST Subject: more steganography talk Message-ID: <9403042001.AA02468@bilbo.suite.com> Stuff that Sergey Goldgaber, Hal, and others wrote induced the following ideas in my head: Goal - create a steganography system that hides cyphertext in such a way that only the true recipient of the message will be able to prove an encrypted message is hidden within a public message. Nobody else will be able to determine if the public message also contains an embedded encrypted message. In Hal's words: > A test, then, for the success of a steganographic > technique is this: given some sampling of data items, > half of which have embedded hidden messages, can the > opponent guess which ones have such messages with better > than 50% accuracy? If not, the steganography is fully > successful. If he can do slightly better than 50%, it may > still be useful depending on the situation. If he can > guess with 100% accuracy, the steganography has failed > and is totally worthless. > If the LSBs of most picture files were truly random, then good steganography would be trivial. Anyone could just plop an unremarkable encrypted message (Stealth-PGP) in the LSB's, starting at the beginning of the file. Since one sequence of truly random bits statistically looks like any other sequence of truly random bits, nobody would be able to prove the picture file contained a hidden encrypted message. Unfortunately, I doubt that most, or even many, picture files have truly random LSBs. It would be possible to write frame grabber or scanner software to purposely place random bits in the LSB of picture files to generate a source of useful picture files. When this software became widely used, good steganography would become trivial. Unfortunately, I don't have much confidence that this could be pulled off on a large enough scale. If it could be done, great, but I'm not holding my breath. Assuming the LSBs of most picture files are not truly random, and wont be any time soon, the next approach to good steganography would be to figure out how to transform a sequence of random bits (your encrypted message) into a sequence of bits that resemble the kinds of bit patterns you see in typical picture files. If you could do this, and do it without requiring more secret keys, then good steganography becomes trivial again. [Actually, you don't have to transform your random bits into a *sequence* of typical picture file LSB bits. The steganography algorithm could deposit the bits anywhere in the picture file, as long the process was reversible and the result was undetectable.] "Reversible, undetectable, without requiring additional keys." Sounds like a good set of requirements for a steganography system. I have an idea to help with the "reversible" part and the "no additional secret keys" part, and it suggests a direction for the "undetectable" part. The idea: Encrypt a widely known value with the recipient's public-key and use the result as an initialization vector for a clever transformation/steganography algorithm. The message recipient recovers the encrypted message by re-calculating the initialization vector using the same widely known value and his public-key and reversing the transformation/steganography step. The initialization vector will be different for each message recipient. The "widely known value" could be a large block of bytes. A large file of random bits could be shipped with the steganography executable. The intent is to make it more difficult and time consuming for the opponent to determine if a public message contains a hidden encrypted message. It's not fool-proof. The opponent could try to discover a hidden message by reversing the process using every known public-key. Worse, an opponent could narrow the search by only trying the public-keys of suspected recipients. However, I think it is an improvement over the techniques being used today. One significant property this technique does *not* possess is deniability. A perfect steganography system will produce results that will let a recipient claim that they did not know a message contained a hidden encrypted message (e.g. most picture files had truly random LSBs). If somebody sent you a hidden message using your public-key and the initialization vector technique, your claim of ignorance might not hold up. Anybody could use your public-key to recover the random bit sequence. They would not recover the contents of the hidden message, but they would be able to show that your file did contain what appears to be a hidden message. It might be enough to tip the scales of justice against you. In my mind, the perfect steganography system depends upon either an environment containing ubiquitous random bit sequences or a reversible algorithm that can transform non-random bit sequences into random bit sequences without using encryption (unlikely). However, I believe a less-than-perfect, but still useful steganography system could be created using the initialization vector technique described above. Jim_Miller at suite.com From hughes at ah.com Fri Mar 4 13:00:18 1994 From: hughes at ah.com (Eric Hughes) Date: Fri, 4 Mar 94 13:00:18 PST Subject: more steganography talk In-Reply-To: <9403042001.AA02468@bilbo.suite.com> Message-ID: <9403042051.AA04295@ah.com> >The idea: Encrypt a widely known value with the recipient's >public-key and use the result as an initialization vector for a >clever transformation/steganography algorithm. How many public keys are there can there be? Assume one hundred each for 10 billion persons. That's 2^40 keys, or an effective key length of 40 bits. Since there are not more than 2^16 public keys right now (a generous estimate) we can assume that this technique is insecure for public keys. Of course, if the public key is not actually public, but only in the possession of the sender, that's another matter, but just try keeping a public key under close distribution sometime. Both PGP and PEM fail to support protocols to restrict the distribution of 'public' keys. Public should mean that the key is held by someone other than the holder of the private key, not that the key is necessarily available to everyone. Eric From jeremy at crl.com Fri Mar 4 13:04:32 1994 From: jeremy at crl.com (Jeremy Cooper) Date: Fri, 4 Mar 94 13:04:32 PST Subject: Increasing the encrypted/unencrypted ratio (was Re: Insecurity of public key crypto #1 (reply to Mandl)) In-Reply-To: Message-ID: On Wed, 2 Mar 1994, Anthony D Ortenzi wrote: > > Well, I know that this might be a bit of a "crazy" idea, but would the > best way to distribute an encrypted mailing list be to have a PGP setup > where there is a public key to the mailing list, and all recipients are > given copies of the secret key? I know that it might be a bit stupid > from the security side, but if each person was using PGP, the secret key > would be PGP encrypted and sent with that person's public key, ensuring > that only subscribers would get it, and then using that secret key to > decrypt the messages as they are recieved? > > > Just wonderin'.... > Anthony > > I think you are probably not thinking about how Public key systems work. It doesn't matter which key you use, public or private, each one reverses the effect of the other. In this case what you are calling the secret key would really be the public key, and vice-versa. You are just asking that the public key be known only among the recipients of the list. _ . _ ___ _ . _ ===-|)/\\/|V|/\/\ (_)/_\|_|\_/(_)/_\|_| Stop by for an excursion into the-=== ===-|)||| | |\/\/ mud.crl.com 8888 (_) Virtual Bay Area! -=== From baum at newton.apple.com Fri Mar 4 13:17:12 1994 From: baum at newton.apple.com (Allen J. Baum) Date: Fri, 4 Mar 94 13:17:12 PST Subject: SF Chron comes out against Clipper Message-ID: <9403031823.AA08647@newton.apple.com> Well, not exactly the Chron, per say, but... this morning a new column debuted about computer networks, the internet, the information highway, and other extrememly trendy topics. The first column was all about Clipper, and why it was a bad idea. I didn't bring it with me today, so I'm not remember lots of details. The writer has an email address on the well (rbr at well.sf.ca.us??). ************************************************** * Allen J. Baum tel. (408)974-3385 * * Apple Computer, 20525 Mariani Ave, MS 305-3B * * Cupertino, CA 95014 baum at apple.com * ************************************************** From jim at bilbo.suite.com Fri Mar 4 13:41:46 1994 From: jim at bilbo.suite.com (Jim Miller) Date: Fri, 4 Mar 94 13:41:46 PST Subject: even more steganography talk Message-ID: <9403042136.AA03953@bilbo.suite.com> Another way to describe a successful steganography system... I am the opponent. I possess a collection of files that might contain hidden encrypted messages. My task is to determine if they do contain hidden encrypted message. A casual inspection of the files does not reveal any bit patterns that deviate significantly from patterns found is most examples of these kinds of files. However, I suspect these files contain hidden messages that were deposited using a steganography algorithm initialized from a public-key generated initialization vector. To test my hypothesis, I will reverse the steganography process using a large collection of public-keys and then examine the resulting bit sequences. -------- If the steganography algorithm is a good one, reversing the steg process will produce a sequence of bits that appears relatively random, even if there is *no* hidden message. What does "appears relatively random" really mean? How do you measure the randomness of a sequence of bits? I'm not an expert in this field, but I would guess you could measure the randomness by attempting to compress the bit sequence. If the bit sequence does not compress much, it is relatively random. How much is "not much"? In other words, what threshold compression percentage value should you use to declare one bit sequence random and another not random? I don't know. To generalize, an opponent will perform some kind of test to determine if the result of reversing the steg process produces a random bit sequence or a non-random bit sequence. The test will have some threshold value below which indicates a random sequence. If the output of the reverse steganography step always falls below the threshold, even if there is no hidden message, then the opponent will not be able to determine if a file contains a hidden message. Jim_Miller at suite.com From jeremy at crl.com Fri Mar 4 13:53:17 1994 From: jeremy at crl.com (Jeremy Cooper) Date: Fri, 4 Mar 94 13:53:17 PST Subject: Standard for Stenography? In-Reply-To: <9403030632.AA13653@hot.ee.lbl.gov> Message-ID: On Wed, 2 Mar 1994, Jef Poskanzer wrote: > > By the way, this discussion is an example of something I have labelled the > "silence is invisible" phenomenon. It goes like this: there's a discussion; > some of the participants work out an answer, and as far as they're concerned > the discussion is over. However, other participants don't understand the > answer, and keep on talking. In a physical meeting, the talkers would > notice the annoyed looks on the faces of everyone else; or if the meeting > had a good facilitator, he or she would catch on to the misunderstanding > and correct it; but in cyberspace, those feedback mechanisms don't happen. > --- > Jef > I agree that it does not happen in that way in cyberspace, but I disagree that it does not happen at all. Confused people in cyberspace tend to talk of topic instead of being silent. If you are a good moderator, you can almost read the minds of the people who are confused. I admit it takes more skill in cyberspace, but it is still quite possible. _ . _ ___ _ . _ ===-|)/\\/|V|/\/\ (_)/_\|_|\_/(_)/_\|_| Stop by for an excursion into the-=== ===-|)||| | |\/\/ mud.crl.com 8888 (_) Virtual Bay Area! -=== From mnemonic at eff.org Fri Mar 4 14:13:54 1994 From: mnemonic at eff.org (Mike Godwin) Date: Fri, 4 Mar 94 14:13:54 PST Subject: SF Chron comes out against Clipper In-Reply-To: <9403031823.AA08647@newton.apple.com> Message-ID: <199403042211.RAA22121@eff.org> Allen Baum writes: > this morning a new column debuted about computer networks, the internet, > the information highway, and other extrememly trendy topics. > > The first column was all about Clipper, and why it was a bad idea. > I didn't bring it with me today, so I'm not remember lots of details. > The writer has an email address on the well (rbr at well.sf.ca.us??). Can someone mail me a hard copy of this piece? We need it for our files. A photocopy would do. --Mike Godwin EFF 1001 G St. NW Suite 950 East Washington, DC 20001 From jim at bilbo.suite.com Fri Mar 4 15:18:38 1994 From: jim at bilbo.suite.com (Jim Miller) Date: Fri, 4 Mar 94 15:18:38 PST Subject: more steganography talk Message-ID: <9403042313.AA05531@bilbo.suite.com> Eric Hughes writes: > Assume one hundred each for 10 billion persons. That's > 2^40 keys, or an effective key length of 40 bits. Since > there are not more than 2^16 public keys right now (a > generous estimate) we can assume that this technique is > insecure for public keys. > I'm not really sure what you mean by "insecure for public keys". I'm not trying to achieve "security through obscurity". I'm trying to achieve "deniability through obscurity". If the reverse steg process makes it look like all, or even many, files contain hidden messages, even when they don't, then you can plausible deny knowledge of a suspicious bit pattern in any specific file. Jim_Miller at suite.com From mcb at net.bio.net Fri Mar 4 16:34:15 1994 From: mcb at net.bio.net (Michael C. Berch) Date: Fri, 4 Mar 94 16:34:15 PST Subject: New mailing list? Message-ID: <199403050033.QAA23619@net.bio.net> I was thinking about Alan's proposal for a moderated real-world-crypto list (which sounds good, by the way!), and it brought up my main problem with cypherpunks, which is sheer volume, volume, volume! It's not a "noise" problem -- since the end of the LD foolishness the greatest part of what has been posted here has been intelligent, thoughtful stuff. But since c'punks has grown to the size of a newsgroup in volume, simply getting through it is *difficult*. My proposal is pretty simple: splitting the list into cypherpunks-tech and cypherpunks-policy. (Cypherpunks-announce would be left alone of course.) I think a large number of readers would want to be on both lists, but a large number (like myself) would *not*, and if nothing else, it would cut down the mailer load on toad. In short, technical crypto articles, reviews of papers, steganography stuff, PGP-specific stuff, all source code, etc., would go to the cypherpunks-tech list; while policy articles, Clipper stuff, political discussions, anarcholibertarian/extropian material, social implications of digital cash, etc., would go to the cypherpunks-policy list. I *know* there are people out there who would rather that the political stuff not get in the way of their technical discussions, and then there are people like me who are more focused on the policy issues (and regardless of technical background, are never going to be code-level crypto hacks). Comments? -- Michael C. Berch mcb at net.bio.net / mcb at postmodern.com From mcb at net.bio.net Fri Mar 4 16:53:44 1994 From: mcb at net.bio.net (Michael C. Berch) Date: Fri, 4 Mar 94 16:53:44 PST Subject: Gun conversion info banned Message-ID: <199403050052.QAA24822@net.bio.net> Mike Godwin writes: > > "labeling for an unlawful medical device" -- the Orgone Accumulator. > > Likewise FDA seizures of Scientolgy literature in the '60s as "labeling > > for an unlawful medical device" -- E-meters. Then there are the moves > > against vitamin literature in recent FDA raids. I don't think the courts > > have ever faced the specific issue of regulatory censorship. > > These cases are pre-Brandenburg v. Ohio. In Brandenburg, the Supreme Court > held that mere advocacy of illegal conduct is Constitutionally protected. But the Court has upheld various police-power suppressions of advertising material, etc., even after Brandenburg (1969, right?) under the "commercial speech" exception, like Pittsburgh Press v Human Relations Comm. 413 U.S. 376 (1973). [Glommed from my 1979 Con Law textbook.] This is a doctrine that commercial expression is less Constitutionally protected than political and literary expression for historical and public policy reasons. I don't know what the present state of the commercial speech exception is, but it has definitely been a nasty stain on First Amendment jurisprudence since Valentine v Chrestensen in 1942. -- Michael C. Berch mcb at net.bio.net / mcb at postmodern.com From mech at eff.org Fri Mar 4 16:56:07 1994 From: mech at eff.org (Stanton McCandlish) Date: Fri, 4 Mar 94 16:56:07 PST Subject: CPSR "explains" why Cantwell bill doesn't matter much - a rebuttal Message-ID: <199403050053.TAA25315@eff.org> I'm finding myself, unfortunately, needing to respond to a widely distributed article of sorts from the 3.05 issue of CSPR Alert. The article was unsigned, so I can't address it to anyone by name. The article states: >Some people have been given the impression that the Cantwell bill is a >response to the Administration's Clipper initiative and that passage of >the legislation would effectively put the Clipper issue to rest. >Because of the confusion surrounding this proposed legislation, we >think it's important to provide some clarifying information. Avoiding the passive verb structures, this can better be rephrased as "Some people have assumed that..." People are not given impressions, they _form_ impressions themselves. It is indeed important to clarify information. However the attempt to do so that I see here does not in fact clarify. To wit: >Indeed, there is no provision in H.R. 3627 that would in any way >rescind the Administration's recent decision to adopt key-escrow >Clipper technology as the government encryption standard. The >legislation would do precisely what Rep. Cantwell said it would do -- >relax restrictions on the export of strong encryption products outside >of the United States. To my knowledge, no one in the know has suggested that the purpose of the Cantwell bill is to "recind" the Clipper EES. It is plain from a reading of EFF's material on the subject, Cantwell's own commentary on the bill, and, of course, the bill itself, that HR 3627 is not intended to directly challenge Clipper (unlike Senator Leahy's proposed hearings, also supported by EFF), but is intended to liberalize export restrictions, pulling an important rug out from under Clipper/Skipjack's metaphoric feet. If one cares to read the mass of Feb. 4 documents issued by the White House, Dept. of State, and other agencies, it is abundantly clear that clamping down export restrictions on all cryptographic products, except those supporting the Administration's EES, is a major part of the proposed Clipper deployment plan. It's been more than adequately debated over the last several months that the such a clampdown is necessary if Clipper is to be a so-called success. The measure is aimed at making it difficult for any non-EES crypto application to compete with Clipper, thereby establishing Clipper as a de facto standard. Given this, _any_ attempt to reduce export restrictions is a positive move for privacy-advocates to support, and serves as a strong, though indirect, countermeasure against Clipper. >Some have suggested that passage of the Cantwell bill would create an >environment in which it is less likely that Clipper will become the de >facto encryption standard within the United States. This view was >expressed by the Electronic Frontier Foundation (EFF) and several large >corporations in a letter to the President last December which expressed >"tentative" support for Clipper on a "voluntary" basis. The writer of the message I am replying to here is well aware that this entire matter has been thoroughly dealt with and fully explained. I've done this so many times, I am hesitant to do so again, but these recurring misinterpretations leave me little choice but to clarify one more time: >From EFF's Dec. 8 Cryptography and Policy Statement: >>[There] was a misunderstanding of what the DPSWG offered the >>administration in this proposal [the letter referred to above], leading to >>the belief that both the DPSWG (a coalition of over 50 computer, >>communications, and privacy organizations and associations) and it's >>principal coordinating organization, the Electronic Frontier Foundation, >>have offered to ease their opposition to Clipper. >> >>We see it as a pragmatic effort to get the government to wiggle on >>these issues: one step in the right direction, with many more to >>follow. This step is that we insist that use of Clipper and key >>escrow must be completely voluntary. It's not voluntary if users of >>the Skipjack algorithm are forced to use key escrow. It's not >>voluntary if users who do choose escrow are forced to use the >>government's choice of escrow agents. It's not voluntary if >>manufacturers such as AT&T are pressured into withdrawing competing >>products. It's not voluntary when competing products can't be sold in >>a worldwide market. It's not voluntary if the public can't see the >>algorithm they are "volunteering" to use. It's not voluntary if the >>government will require anyone to use Skipjack or escrow, even when >>communicating with the government. >>... >>But NSA is digging in, and a legislative fight looks more likely. >>If diplomacy fails, EFF must fight for our rights. Thus, we are >>going to need all the allies we can find, from IBM, Apple, Lotus, >>and Sun, to cryptographers, cypherpunks, and folks on the net. >> >>EFF wants the public and the Administration to know (as we have >>frequently stated to them face to face) that the Electronic Frontier >>Foundation would fight to the end any attempt by the Administration to >>do any more than let companies use Clipper if they want and to let people >>buy it if they want -- and only in a market which has other strong >>encryption schemes available because export controls have been lifted. If one actually reads this, one finds that our definition of "voluntary", which has been made _very_ clear to the Administration in repeated face-to-face meetings, stipulates: 1) no forced key escrow, and no forcing of governmental-only escrow for even those that _want_ key escrow 2) no governmental pressure on the marketplace 3) no export restrictions 4) no classified algorithm 5) no FIPS standard, and no forcing _anyone_, even govt. agencies, to use it. In other words, if the entire Clipper scheme were reworked such that Clipper was nothing more than the open, _truly_ voluntary, publicly examinable successor to DES - a quite innocuous govt. crypto standard - then and only then would EFF and the Digital Privacy and Security Working Group offer it's "tentative" support. Please keep in mind that, barring secret NSA backdoors, there is nothing inherently "bad" or "wrong" about the Clipper/Skipjack encryption. Only the methodology involved is reprehensible and unAmerican. >CPSR dissented from this position in a subsequent letter to the President >and expressed its opposition to the Clipper proposal under any >circumstances. Please note that EFF also signed this letter. Any opposition to CPSR being perceived here is 100% illusory. At any rate, I'd also like to point out that the DPSWG letter and the EFF '93 crypto-policy statement are at this point old history. They are no longer applicable (an example line: "It is December, the escrow system is still uncertain, and the Administration is still drafting a report which was due in July" - how timely does this sound?) Dragging such a dead horse out for another beating is quite unfathomable to me. I sincerely hope this will the very last time I have to clarify this matter, partly because I'm tired of repeating myself, but mostly because this sort of inter-organization baiting is counter-intuitive and counter-productive for all organizations and individuals involved, and could cost us (by which I mean those opposing Clipper, in general) a lot of credibility. To continue with the present matter, however: >While it is possible that the Cantwell legislation would make it less >likely that Clipper will become the de facto privacy standard, such a >result is by no means a certainty. It is, in fact, possible that >passage of the legislation would provide better U.S. encryption >products overseas than would be available within the United States -- >particularly if, as many fear, Clipper eventually becomes a mandatory >standard in this country. This is false on its face. Please support the notion that crypto which, somehow, becomes illegalized in this country would be allowed to be manufactured for export purposes only. That's absurd; it's like imagining a "gun control" law that banned using firearms in the US, but encouraged everyone to buy guns and ship them to other countries. At any rate, EFF intends to help see to it that Clipper does _not_ become mandatory, nor that non-Clipper crypto is outlawed [pretty much the same in effect]. No ifs, ands or buts about it. Even beyond this, this scenario is completely unrealistic, not least because the best crypto in the world is _already_ available outside the US. No amount of lawmaking is going to stop it, short of destroying every computer, phone line, fax machine and printing press in the country. Even this will not put the crypto genie back in the bottle anyway. Fact is, some of the best crypto in the world wasn't even made in the US in the first place. Ever heard of IDEA? >We believe that the Cantwell bill is a step in the right direction, as >it would remove current disincentives to the development of strong >encryption products by U.S. companies. On this much I think we can be in complete agreement. >But the proposed legislation is not a panacea -- Of course it isn't. Please quote anyone saying that it is. >it would not address the threat to privacy in the United States created by >the Clipper initiative. Export controls on cryptography are a related >issue, but they are not central to the Clipper controversy. The >Administration's adoption of the key-escrow Clipper standard must be >opposed and reversed. Export control reform is indeed central to the issue. Without export controls, the major market-leverage crutch of the entire Clipper scheme is ripped away, revealing the "poor lame beggar" act to be a scam. Law enforcement doesn't "need" the "protection from terrorists, drug dealers and child pornographers" supposedly to be provided by Clipper, any more than the American people need another hole in their privacy. But you know that. If all you mean to say is that the Cantwell bill is not the only way fight Clipper, and will not solve all of the problems, you'd be right. But why don't you just say so, instead of taking this as yet another opportunity for grandstanding? It's unbecoming of an organization on the same side as the rest of us. In closing, I'd just like to say that everyone realizes that Cantwell is not the be-all and end-all of pro-privacy, anti-Clipper action. You can bet I added my signature to _your_ petition, and I hope everyone does, whether it will work or not. Better to have tried and failed that never to have lifted a finger. With that, I must ask you, have _you_ sent in your letter of support for the Cantwell bill yet? If not, it's real easy: State your reasons for supporting the bill, and send them to cantwell at eff.org. The results, already numbering in the thousands, are regularly printed out and delivered to Rep. Cantwell personally. With high regard, but a fair amount of exasperation, S.McC. "We must all hang together, or assuredly we shall all hang separately." - Benjamin Franklin, at signing of Declaration of Independence; July 4 1776 -- Stanton McCandlish * mech at eff.org * Electronic Frontier Found. OnlineActivist F O R M O R E I N F O, E - M A I L T O: I N F O @ E F F . O R G O P E N P L A T F O R M O N L I N E R I G H T S V I R T U A L C U L T U R E C R Y P T O From fhalper at pilot.njin.net Fri Mar 4 18:10:59 1994 From: fhalper at pilot.njin.net (Frederic Halper) Date: Fri, 4 Mar 94 18:10:59 PST Subject: reply-to feeds an anon pool, jpp=pr0duct=cypher Message-ID: <9403050210.AA17485@pilot.njin.net> What is that "famous Cypherpunks public key?" Reuben Halper From jpp at markv.com Fri Mar 4 19:18:23 1994 From: jpp at markv.com (jpp at markv.com) Date: Fri, 4 Mar 94 19:18:23 PST Subject: reply-to feeds an anon pool, jpp=pr0duct=cypher In-Reply-To: <9403050210.AA17485@pilot.njin.net> Message-ID: <9403041908.aa18245@hermix.markv.com> I think this is Pr0duct Cypher's public key --- but I could be wrong. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQCNAi0xHTIAAAEEAKeIU9S010e1AxYy2R379ptHunqM0kRMgWnOwfCnVets8jTh r7B87pzFNVj6kBs8F9TKQdk62JR5Kiq2rVODFSLmN2JThnhfDu/tAYAz8fJsWkxG n5IhcjxkQpfb2LDs4EBJgWhI9HxIfCvhSkFdrFe9JBfm0KKB5sGoFIWXVYodAAUT tCFQcjBkdWN0IEN5cGhlciA8YWx0LnNlY3VyaXR5LnBncD4= =j/dW -----END PGP PUBLIC KEY BLOCK----- From wcs at anchor.ho.att.com Fri Mar 4 21:01:04 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Fri, 4 Mar 94 21:01:04 PST Subject: more steganography talk Message-ID: <9403050500.AA01957@anchor.ho.att.com> Eric Hugher, replying to somebody, writes: > > The idea: Encrypt a widely known value with the recipient's > > public-key and use the result as an initialization vector for a > > clever transformation/steganography algorithm. > > How many public keys are there can there be? > Assume one hundred each for 10 billion persons. That's 2^40 keys, or > an effective key length of 40 bits. Since there are not more than > 2^16 public keys right now (a generous estimate) we can assume that > this technique is insecure for public keys. If you're going to go to the trouble of using a public key, including handling generation, distribution and validation of public keys, you might as well use a "clever transformation/steganography algorithm" that's good enough that a brute-force search of all the public keys won't reverse it. A good candidate for such an algorithm would be IDEA - and if this sounds like I'm reinventing PGP, it's intentional :-) Essentially, you're proposing wrapping PGP in PGP, or in weakened-PGP. Better to just use Stealth-PGP to eliminate the distinctive markers that make PGP easy to find, maybe run the code through tran for extra scrambling if you're not running pnmstega, and then steganize. And make sure that if you write PGP, The Next Generation, you make it stealthy so people who don't have the right keys just see noise. Bill From sergey at delbruck.pharm.sunysb.edu Fri Mar 4 22:22:00 1994 From: sergey at delbruck.pharm.sunysb.edu (Sergey Goldgaber) Date: Fri, 4 Mar 94 22:22:00 PST Subject: Standard for Stenography? In-Reply-To: <9403041456.AA02863@vail.tivoli.com> Message-ID: On Fri, 4 Mar 1994, Mike McNally wrote: > Maybe not, but if you've been paying atention you know of a great deal > of theory that support the intractability of solving certain problems > in realistic amounts of time. Most PK cryptosystems are based on > relatively simple principles of mathematics. It stretches the > imagination to think that the NSA somehow has solved the factoring > problem; I concede it's possible, but unlikely. Granted. > > > The point is, that in the real world, we'll never know if our algorithms > > are "good enough to withstand an opponent who has full documentation of > > your algorithms and methods lots of funds, and everything except your keys." > > Depends on what you mean by "know", I guess. know = 100% objective certainty > > > > security-by-obscurity is a naive waste of time, > > > > I still don't see why. > > Well, you can't tell when you've been compromised, How can you tell that you've been compromised if you stick to non-security-by-obscurity methods? > and you have no > rigorous way of demonstrating the robustness of your obscurity. That would be difficult. But, lack of objective measures does not mean that security-through-obscurity is innefective. BTW, there may be some statistics on the effectiveness of StO, somewhere. (Anyone out there heard of any?) > The real problem, however, is that you'll have a hard time convincing > anybody else to participate. I am not trying to convince everyone hide their data in the same place I am hiding it. Simply consider hiding it, rather than leaving it out in the open! That's not too crazy a proposition, is it? > You can hide all your valuables in a really clever place and do all > sorts of really clever secret things to protect them, and that may > make you feel secure. However, you won't be able to convince me to > entrust *my* valuables to you unless you explain to me the details of > your techniques. Take your encrypted data. Stick it in a file, using a variable offset. That's all there is to it. Sergey From tcmay at netcom.com Fri Mar 4 23:06:07 1994 From: tcmay at netcom.com (Timothy C. May) Date: Fri, 4 Mar 94 23:06:07 PST Subject: French Govt Confirms Plans To Issue Smart Card ID Cards 03/04/94 Message-ID: <199403050706.XAA15145@mail.netcom.com> Someone sent me this message and suggested I forward it to the List. I'll just send it along via the normal channels. By the wa, this is just one of several indications that non-U.S. nations are just as far along as the U.S. is in moving toward a Surveillance State. I mentioned this a few weeks back, and some List members from Norway, Australia, and elsewhere contributed tidbits from their own countries. Germany, France, and the United Kingdom are very far along in such developments, and generally lack the same kind of civil liberties consciousness that the U.S. has (this is not a criticism of Europeans, but a statement of fact. Lacking robust constitutions--not that the U.S. document is looking particularly robust these days--the police have extensive powers of search and seizure, and of detention, and of surveillance, that even the American Security Apparatus can only envy. The Germans are on the verge of rescinding some constitutional provisions to allow for increased police surveilance. Ironically, the Bundesnachrichtendienst (BND) seeks these powers ostensibly to combat Neo-Nazism and nuclear terrorism, while Neo-Nazi murderers are slapped on the wrist. Read "The Economist" for details of events in Europe, or "Germany Alert," a newsletter out of New York written by German ex-pats to educate the world about the dangers of fascism in Germany and Europe today. The links to Clipper and the "family keys" being prepared for the French, Japanese, and other nations tell us that the key deals have already been cut. Here's the article, this one about France. Subject: French Govt Confirms Plans To Issue Smart Card ID Cards 03/04/94 (fwd) To: tcmay at netcom.com Date: Fri, 4 Mar 94 23:05:30 Tim, you might wanna forward this to cypherpunks under the information liberation front. I don't have a list of currently working remailers so I really can't forward it anonymously now. Its scary. > PARIS, FRANCE, 1994 MAR 4 (NB) -- The French government has > confirmed its plans to replace citizen's paper-based ID cards with > credit card-sized "smart card" ID cards. > > According to Charles Pasqua, the French Interior Minister, the smart > ID cards have already been trialled in several regions of France and > will be phased in across the whole of the country by the end of next > year. The new cards are distinctive, Newsbytes notes, owing to their > blue color. > > Initially, the cards can be read by anyone with a suitable card > reader and will include name, address and date of birth > information. Plans are in hand, however, to allow advanced card > readers to link to the French central database and automatically > update the card with new information, such as change of address > etc., as it becomes available. > > According to Pasqua, the main reason for the introduction of the > cards was one of national security, as he noted that, since the > cards began their trials in 1988, more than 500,000 had been issued > and not one forgery had turned up. In comparison, out of three > million paper ID cards issued in 1992, around 10,000 were forged. > > Visitors to France, Newsbytes understands, will shortly be > issued a computerized stamp, including a barcode readable tag > affixed to their passport. Visitors with "right to remain," (a > term applied to visitors staying longer than six months) will be > issued with the smart ID cards in due course. > > Smart cards are all the rage in France at the moment, Newsbytes > notes. Almost all Visa cards issued by French banks are smart cards, > with the electronics supplied by Thomson CSF and other French > technology companies. > > The cards contain details of recent transactions, as well as act > as an "electronic purse" for smaller value transactions using a > personal identification number (PIN) as authorization. "Purse > transactions" are usually separate from the card credit/debit > system, and, when the purse is empty, it can be reloaded from the > card at a suitable ATM or retailer terminal. > > (Steve Gold/19940304) > > > From hughes at ah.com Fri Mar 4 23:28:13 1994 From: hughes at ah.com (Eric Hughes) Date: Fri, 4 Mar 94 23:28:13 PST Subject: New mailing list? In-Reply-To: <199403050033.QAA23619@net.bio.net> Message-ID: <9403050719.AA06416@ah.com> No offense, Michael, but you've made a Frequently Offered Suggestion. I really should put the answer in a cron job. The mailing list won't be split. >My proposal is pretty simple: splitting the list into cypherpunks-tech >and cypherpunks-policy. This proposal has been put forward before. No doubt it will be put forward again. But it's not going to happen. I sound cranky, I know. Let's be explicit. The list is not going to be split because I don't want it to be split. By my fiat. It's not fair and it's not democratic and it's not going to change. Cypherpunks is where the politics meets the code. It is the interplay between software design and political desire which is where the all the good stuff happens. Policy separated from development lags the reality of deployment, and necessarily. There's already a newsgroup for this: talk.politics.crypto. Technicality separated from sociality is unaware and harbors deep-seated contradictions. There's already a newsgroup for this: sci.crypt. Programmers implement culture, and cypherpunks write code. I want each reader of these words to reflect on the phrase "implementing culture". If you do not realize the magnitude of this principle and have some respect for its enormity, I would sincerely suggest that your time would be better spent reading some political philosophy and some technological history and pondering over your desires, to make sure that you know them. Eric From sergey at delbruck.pharm.sunysb.edu Fri Mar 4 23:45:18 1994 From: sergey at delbruck.pharm.sunysb.edu (Sergey Goldgaber) Date: Fri, 4 Mar 94 23:45:18 PST Subject: Security through Obscurity In-Reply-To: <199403041522.HAA24738@jobe.shell.portal.com> Message-ID: On Fri, 4 Mar 1994, Hal wrote: > From: Sergey Goldgaber > > > > If I have understood you correctly, there is nothing wrong with equating > > obscurity with a practical, albeit temporary, increase in security. > > Equating obscurity with ultimate security is a mistake. As is equating a > > "strong" algorithm with ultimate security. > > I would not put it like this. Rather, if you want a temporary increase > in security, you need to calculate, or at least assume, how much extra time > it will take for your opponent to defeat your temporarily-secret information. > Just saying, "oh, well this complication ought to slow him down some, heh > hey," doesn't cut it. Again, you need to be explicit about exactly what > information you are keeping temporarily secret, and how long you expect it > to be kept secret. > I agree. Your cost assesments will, however, be different for each individual StO method. I was generalizing. > > I would like to propose that there is a goal, in addition to those you have > > revealed, for the opponent as well as the legitimate user of steganography. > > The opponent would, ideally, wish to not only determine that there is a > > message within the data; in addition, he would prefer to be able to extract > > that message for analysis. Therefore, I believe that it would be to the > > advantage of the stego-user to not only hide the existence of his message, > > but to do so in such a way that the cost of successfully extracting that > > message, by his opponent, is maximized. > > > > I think this is a plausible, although less ambitious, goal. But what's > this about "maximizing cost"? Where does that fit into the analysis? This > does not tell you whether your "maximization" has actually helped or not. Well, if we adopt the method of comparing the cost of implementing a given steganography method to the cost of breaking it as a valid measure of its effectiveness; then, it would make sense to "maximize" the cost of breaking it as a means of making the method more effective (ie. making the method more obscure would make it more effective). > Instead, if you are going to adopt this goal, this means that the test of > your steganography is whether the opponent can extract the message. It's > not that your goal is to "maximize his difficulty". It's that your goal is > to stop him. Again, NoStO emphasizes clear statements of your goals and > costs. The more difficult it is for one's opponent to extract the message, the more effective the method is. Thus, "maximizing his difficulty" is a valid goal. As I see it, this is a goal of most encryption systems. To make decryption as difficult as possible, if not impossible (ie. maximum difficulty). > > (The reason I say this is less ambitious is that if the opponent can > determine there is a message, but not what it is, they may be able to > bring penalties to bear on those communicating, depending on the circum- > stances. For example, finding a stego'd file on someone's hard disk > might represent probable cause that illegal encryption was used, in some > hypothetical future.) > I am well aware of this. I was not proposing the above goal as a substitute, but an addition to the one you pointed out. > > I have to take exception with the assertions made in this paragraph. > > Using the principles of public-key systems, the steganography key itself > > does not have to be kept secret. The sender, reciever, and indeed the > > opponent would all have access to this key without compromising the > > security of the system. The challenge, for the opponent, lies in figuring > > out which public-key the sender has used. I have no statistics on > > exactly how difficult this challenge would prove; but, considering the > > number of public-keys currently availiable and projecting several years > > into the future, the challenge may be a very significant one. > > What key are you talking about here? The public one? That is not > secret. As you say, the opponent has access to it. Are you assuming that > the opponent cannot guess which public key was used? How will you measure > the accuracy of this assumption without statistics? I am assuming that it will cost the opponent effort. I have no statistics to show exactly how much effort it would cost him; as I believe it would be different in every individual case. However, it is clear that the effort needed would increase. > I really don't think you have understood my essay. The point, again, of > avoiding StO is to make it clear what you are keeping secret, and to count > the costs of keeping it secret. If you are counting on keeping secret the > recipient of the message then you have these costs: > I do not think you have understood _my_ essay. My proposal was for a default, variable offset in certain steganography applications. The benefit of this is obvious: having no offset or a non-variable offset would make for generally poorer security; as, the effort required in figuring out where one's file is located is nonexistant. Effort increases when a variable offset is implemented. > Any stego files found in the recipient's possession are broken. This need only be the case if the recipient keeps his recieved files (which were sent using the _default_ settings) in their original format. Any compromise in security can be avoided if he resets the offset to a custom value. > > Stego files can be exhaustively searched against a list of public keys. > Regularly encrypted files can be searched against random secret keys. The effort involved in both is greater than not having to search at all. > If a particular group or person is targeted for surveillance his keys can > be used against all widely-known stego channels. If no offset, or a non-variable offset, is used than one's opponent wouldn't even have to try to recover the file! That is why I only proposed a default offset, while pointing out that maximum security can only be achieved through custom offsets! > Further, your own test is so weak (inability to recover the actual message) > you have not attempted to make it impossible to guess when you have > recovered the message, even with the correct key information. So in each > of the cases above the authorities know when they have the message in hand. In my original post I made it clear that my proposal was an addition to, not a subsitition for, the goal you set. Therefore, the ideal steganography program would make it impossible to guess that there is a message _as_well_as_ make it impossible to tell where the message is located. These functions are not mutually exclusive. > Now if you are tempted to say that this isn't true, because we could arrange > for the message ALSO to be unrecognizable even when successfully recovered > (so that the opponents don't know when they have recovered it) then you > have missed the whole point. You earlier rejected this test. If you had > accepted it, you wouldn't have needed your keys at all. > > Hal You proposed that a successful steganography program should hide the message in a file in such a way that one's opponent would have to guess about the existance of a message in that file. I do not dispute that goal. I simply offer an additional one. Let me give an example: Steganography Program A hides data at no offset, with a 49% probability of hostile recognition. This program would pass your proposed test. Because it offers no offset, successfull extraction of the data requires only X ammount of effort from one's opponent. Steganography Program B hides data at a variable offset, with a 49% probability of hostile recognition. This program would also pass your proposed test. Because it offers a variable offset, successfull extraction of the data requires X+Y ammount of effort from one's opponent. User C hides data in all 100 of his GIF files using Steganography Program A. User D hides data in all 100 of his GIF files using Steganography Program B. Opponent E searches through every GIF file of both user C and D. He guesses that there is data in 49 files belonging to user C, and 49 belonging to user D. He successfully extracts the data from all 49 of user C's files, expending X ammount of effort. Successfull extraction of user D's data, however, costs him X+Y effort. As this is a hypothetical example, we may subsitute $1 for X ammount of effort, and $1 for Y ammount. Successfull extraction of C's data would cost his opponent $1, while D's data would cost $2. More realistically, substiture $10,000 for both X and Y; or $100,000; or $1,000,000. Now, would you rather use? Program A or B? I, for one, would rather use B, realizing that both X and Y are unknown. Sergey From ebrandt at jarthur.cs.hmc.edu Fri Mar 4 23:51:28 1994 From: ebrandt at jarthur.cs.hmc.edu (Eli Brandt) Date: Fri, 4 Mar 94 23:51:28 PST Subject: Standard for SteGAnography In-Reply-To: Message-ID: <9403050751.AA13101@toad.com> > know = 100% objective certainty Well, OTP gives you this. Probabilistic encryption does too, I think (the original version -- not the practical version). Quantum cryptography is pretty close, depending on how much trust you place in the laws of physics. Granted, none of these are very useful. The question is, 100% objective certainty of *what*? If breaking a scheme were provably exponential-time, that'd be enough for me. > Sergey Eli ebrandt at hmc.edu From sergey at delbruck.pharm.sunysb.edu Sat Mar 5 00:03:32 1994 From: sergey at delbruck.pharm.sunysb.edu (Sergey Goldgaber) Date: Sat, 5 Mar 94 00:03:32 PST Subject: more steganography talk In-Reply-To: <9403042001.AA02468@bilbo.suite.com> Message-ID: On Fri, 4 Mar 1994, Jim Miller wrote: > In my mind, the perfect steganography system depends upon either an > environment containing ubiquitous random bit sequences or a > reversible algorithm that can transform non-random bit sequences into > random bit sequences without using encryption (unlikely). Such is the function of Mimic, available at ftp.cs.cornell.edu in /pub/wayner/Mimic It holds the most promise for steganography, in my oppinion. Unfortunately, it may be difficult to implement, initially. Sergey From sergey at delbruck.pharm.sunysb.edu Sat Mar 5 00:22:13 1994 From: sergey at delbruck.pharm.sunysb.edu (Sergey Goldgaber) Date: Sat, 5 Mar 94 00:22:13 PST Subject: Standard for SteGAnography In-Reply-To: <9403050751.AA13101@toad.com> Message-ID: On Fri, 4 Mar 1994, Eli Brandt wrote: > > know = 100% objective certainty > > Well, OTP gives you this. Probabilistic encryption does too, I > think (the original version -- not the practical version). Quantum > cryptography is pretty close, depending on how much trust you place > in the laws of physics. Granted, none of these are very useful. > Newbie questions: What is OTP? What about probabilistic encryption vs quantum cryptography? How do they give one 100% certainty that they can't be broken? > The question is, 100% objective certainty of *what*? If breaking a > scheme were provably exponential-time, that'd be enough for me. > 100% objective certainty of the scheme's invulnerability. > > Sergey > > Eli ebrandt at hmc.edu > > Sergey :) From hughes at ah.com Sat Mar 5 00:51:54 1994 From: hughes at ah.com (Eric Hughes) Date: Sat, 5 Mar 94 00:51:54 PST Subject: some technical steganography In-Reply-To: <9403042136.AA03953@bilbo.suite.com> Message-ID: <9403050842.AA06538@ah.com> >What does "appears relatively random" really mean? How do you >measure the randomness of a sequence of bits? Randomness is the wrong measure. Suppose I take 2^10 random bits and prepend 16 zeros. How random is this? Almost as random, and this can be made precise. How compressible is it? Almost incompressible. Now, what about 2^20 bit? 2^30? It is not randomness but recognizability which is at issue. Then the next issue arises. >If the reverse steg process makes it look like all, or even many, >files contain hidden messages, even when they don't, then you can >plausible deny knowledge of a suspicious bit pattern in any specific >file. The situation of one file is the wrong problem. Suppose you have a collection of files. What you want is deniability for the group of files as a whole. This is much trickier, and the obvious thing doesn't work. Suppose the files contain some bytes of an RSA encrypted session key concatenated to the bytes of a file encrypted with the session key. This is a reasonable scheme, and is basically how a stealth-PGP might work. Because the mode of representation is concatenation, the session key is represented as some arbitrary number X mod N, the public key modulus. Recall that N is public. Now let k be the length of N in bits, rounded up to the nearest multiple of eight. Since the encrypted key is represented as bytes, the bit length is a multiple of eight. Now the probability that a random number between 0 and 2^k will be less than N is N/2^k. Easy. If N is not chosen specifically with this purpose, the fraction N/2^k is on average about 1/4. The important thing is not that this number is small but that it is less than one, say p. Now take an arbitrary string of bits and apply the (public) extraction technique for a given public key, and from this extract a candidate for the encrypted session key. Now you can check the candidate against the modulus. If the candidate is greater than the modulus, then you can reject that public key as being a possible recipient of that message. The probability that a public key rejects none of a group of files grows exponentially small, therefore. Each time a file is not rejected as a possible message with respect to a particular recipient key, the probability lowers by p. You could even check all possible keys. You may not be able to identify the recipient, but in aggregate the opponent will be able to ascertain that messages are being sent. That is sufficient. Steganography not only seeks to hide individual messages, but also the fact that communication is taking place. There are some defenses. One can look for public keys which give high N/2^k ratios. Unfortunately, this almost assuredly makes factoring the modulus easier, if only by lowering the search space. One can make sure the collection of files contains some ringers, such that the ratio of ringers to real messages is 2^k-N:N. This is certainly possible if one is simply storing files, but if the collection of files were intercepted in transit, the sender would have to make sure to send files in the correct ratio. Yet this requires that the sender look out for you and your security! What is most broken here is the N/2^k ratio itself, that is, the artifact of the byte-oriented encoding. In other words, a random modular number is not random in the byte length representation. More to the point, one can't simply lop the front off a PGP message and get stealth-PGP. So one way to solve this is to introduce some indeterminism into the modular representation, so that the session key is evenly distributed in all of its relevant representations. This would mean that every session on the range [0..2^k) was valid, and was taken mod N to decrypt a session key. This yields non-random session keys mod N, which might be acceptable, since the entropy of the modular distribution doesn't drop all that much. Still, this requires the sender's software to be secure. Another way would be to use arithmetic coding to spread out the N/2^k ration throughout the whole file. For an exact solution, one would have to use rational cooefficients rather than 2-adic coefficients, but an approximate solution should be adequate. One needs for the approximate case, however, an estimate of the candidate acceptance rate p above to make sure that the approximation is good enough. This solution doesn't require the sender's software to be any more secure than is in the sender's interest. In steganography, like cryptography, the different layers of abstraction forcibly interfere with each other. The pun here was that an RSA key (represented by a modular integer) was being put into a different representation where it didn't work. These kinds of level-shifting behavior are all-too-common, and are the cause of much protocol failure. Eric From ebrandt at jarthur.cs.hmc.edu Sat Mar 5 00:59:38 1994 From: ebrandt at jarthur.cs.hmc.edu (Eli Brandt) Date: Sat, 5 Mar 94 00:59:38 PST Subject: Standard for SteGAnography In-Reply-To: Message-ID: <9403050859.AA13734@toad.com> > Newbie questions: What is OTP? What about probabilistic encryption > vs quantum cryptography? OTP is one-time pad. There was an article on quantum cryptography in the October '92 Scientific American. For probabilistic encryption, I think the sci.crypt FAQ has a reference. > How do they give one 100% certainty that they can't be broken? OTP and some flavors of probabilistic encryption are information- theoretically secure. For OTP, this is obvious if you think about it a bit. Quantum cryptography relies on the math of quantum mechanics, whose validity is ultimately empirical but rather well tested. > 100% objective certainty of the scheme's invulnerability. My point is, invulnerability to *what attack*? An attacker may know the algorithm, or not; may have known plaintext; may be able to choose plaintext; may be able to read a channel, or to garble it, or to change it; may have limited or unlimited space and time; might be able to factor in polynomial time -- there are a lot of parameters here. And it makes no sense at all to say, "Well, let's just consider the strongest possible attack." Eli From pcw at access.digex.net Sat Mar 5 05:30:58 1994 From: pcw at access.digex.net (Peter Wayner) Date: Sat, 5 Mar 94 05:30:58 PST Subject: more steganography talk Message-ID: <199403051330.AA13596@access2.digex.net> On Fri, 4 Mar 1994, Jim Miller wrote: > In my mind, the perfect steganography system depends upon either an > environment containing ubiquitous random bit sequences or a > reversible algorithm that can transform non-random bit sequences into > random bit sequences without using encryption (unlikely). Such is the function of Mimic, available at ftp.cs.cornell.edu in /pub/wayner/Mimic It holds the most promise for steganography, in my oppinion. Unfortunately, it may be difficult to implement, initially. Sergey ------------------------ Sorry to be so distracted. This is a very interesting topic for me, but I've been bogged down with more prosaic topics. I think the Mimic FUnction implementation that I did is a very general standard for steganography. On the current level, it just deals with text, but you can make it do bits by just using the alphabet of just plain {0,1}. Here are the important points about it: 1) If the grammars are made complex enough, they can simulate anything you can compute with a computer. I.e. You can encode data in a Turing-complete way. 2) Even if you limit yourself to plain old context-free grammars, you still have a class of encryption functions that can be as powerful as RSA. I.e. You can show that any general program that can infer the grammar used in a Mimic function can also break RSA. This proof is done by translating RSA encryption into a context-free grammar. 3) If you use Turing-complete grammars, then the result is technically "undecidable." I.e. it may be technically "unbreakable." I don't put much stock in this claim, but it is interesting to note that there is _no_ possible brute-force attack on these systems. I do believe, though, that there could be many practical "incomplete" attacks that worked in general cases. 4) It is still unclear how to generate RSA-level strength with Mimic Functions. The simplest way may be just to encrypt with RSA first. Understanding what makes grammars hard and easy to grok is a hard question. 5) That being said, I think that Mimic grammars are one of the most natural ways to specify steganography. There are many other forms that are Turing-complete, but I think that grammars are one of the most natural ways to specify what you want to happen. 6) The process is slightly difficult to implement, but I've got two running versions (as I've mentioned before on the list). One in C and the other in Pascal. Your choice if you live in the Continental US. It is not clear to me if the software is "exportable". I considered applying to the commerce department to get a free assessment of the cryptographic strength, but then I found out that they were denying licenses to systems that I could break. So they're not a great oracle for these questions. From julf at penet.fi Sat Mar 5 06:22:57 1994 From: julf at penet.fi (Johan Helsingius) Date: Sat, 5 Mar 94 06:22:57 PST Subject: Next Physical Gypherpunks meeting In-Reply-To: <9403032006.AA01702@ah.com> Message-ID: <199403051422.AA18947@lassie.eunet.fi> > If you have a T1, a sparc, a speaker/microphone, a meeting room, and > the desire to host a meeting, get in touch with me. We'll need some > coordination. Count me in! Finally got myself onto the MBONE... Julf From hfinney at shell.portal.com Sat Mar 5 07:32:51 1994 From: hfinney at shell.portal.com (Hal) Date: Sat, 5 Mar 94 07:32:51 PST Subject: Truly Stealthy PGP Message-ID: <199403051533.HAA07296@jobe.shell.portal.com> Eric points out the difficulty of making a "stealth PGP" which is 100% indistinguishable from a string of random bits. The problem is that we have to encode the RSA encrypted number, m, which is less than n, the RSA modulus. PGP first puts out two bytes of bit length, then m. This obviously won't do, since the bit length is generally much less than 2^16 and so these two bytes are a dead giveaway. However, we could leave these two bytes off and just output m as raw bits, padded to the length of n. The recipient knows n so he would be able to extract m. The problem here, as Eric points out, is that m is less than n, so the high bits of m will look non-random. If the high two bytes of n are, say, 0x0C12, then m's high two bytes will never be bigger than this. This will allow the opponent to do much better than 50% on guessing which files have embedded messages. This was discussed some time back on the pgp developers' list, and at that time the suggestion was made to add a multiple of n to m so that it covered a fuller range of values. The recipient would then just take the exponent mod n and try that. Mathematically, call L the next multiple of 256 above n. (0x10000... in the example above.) We want to choose k so that M = m + k*n is randomly distributed between 0 and L-1 if m is randomly distributed between 0 and n-1. This may not be possible in this form. Perhaps there is another deterministic and reversible transformation would accomplish it, though. In that case we would have M = f(m,n) such that f can be reversed given M and n (we can recover m). As a trivial example of this problem, given n=2 and L=3, try to come up with a way to turn a random 0/1 value into a random 0/1/2 value which is both reversible and produces each of 0/1/2 with 33% probability. Seems pretty tough! Hal From hfinney at shell.portal.com Sat Mar 5 08:02:06 1994 From: hfinney at shell.portal.com (Hal) Date: Sat, 5 Mar 94 08:02:06 PST Subject: Security through Obscurity Message-ID: <199403051602.IAA08056@jobe.shell.portal.com> From: Sergey Goldgaber > Well, if we adopt the method of comparing the cost of implementing a > given steganography method to the cost of breaking it as a valid measure of > its effectiveness; then, it would make sense to "maximize" the cost of > breaking it as a means of making the method more effective (ie. making > the method more obscure would make it more effective). I don't think this is a valid measure of steganography's effectiveness. I proposed my own measure, which I think is valid. I think the fundamental problem with your measure is that it counts a system which is easy to break but very easy to implement as effective. I would count such a system as ineffective. > > Instead, if you are going to adopt this goal, this means that the test of > > your steganography is whether the opponent can extract the message. It's > > not that your goal is to "maximize his difficulty". It's that your goal is > > to stop him. Again, NoStO emphasizes clear statements of your goals and > > costs. > > The more difficult it is for one's opponent to extract the message, the > more effective the method is. Thus, "maximizing his difficulty" is a > valid goal. As I see it, this is a goal of most encryption systems. To > make decryption as difficult as possible, if not impossible (ie. maximum > difficulty). I don't think this is right either. The problem is that "as difficult as possible" does not allow for a measure of success. Something which is "as difficult as possible" may nevertheless be useless. This whole notion of maximizing difficulty as a goal is completely misguided. The correct goal is to achieve secrecy. If you have not done that, then maximizing difficulty is pointless. Your goal in making a parachute is to create something that will land you safely. It isn't to "maximize slowness of fall". Suppose I made a parachute out of lead, designing it to maximize slowness among lead parachutes. Will you jump out of an airplane with it? I'd think not. The problem is that this is the wrong goal. > I do not think you have understood _my_ essay. My proposal was for a > default, variable offset in certain steganography applications. The > benefit of this is obvious: having no offset or a non-variable offset > would make for generally poorer security; as, the effort required in > figuring out where one's file is located is nonexistant. Effort > increases when a variable offset is implemented. OK, let me ask this: what is the harm done if the opponent guesses the right offset? How bad are things? Some of your security has been lost. How much? Suppose your stego method is not completely invisible and does give away its existence to some extent. Would you still use it if protected by your offsets, or would you refrain until you had an undetectable stego? How much would you trade off the protection provided by your offsets against the protection provided by undetectable stego? Suppose I am a naive user of your program asking these questions. When I receive a stego'd file and put it on my disk, should I re-format it to change the offset? How much security does this gain me? Is it worth it? Should I have more than one public key, so that the opponent would have more offsets to guess? How much does this help? How much should I worry if I think I may be targetted for surveillance, which would increase the chance of them trying my keys as the offsets? Should I avoid controversial issues, keep a low profile, so that I can prevent this from happening? How much should I trade off against the benefit of making my offset less likely to be tried? I think if you are seriously proposing that your offset scheme adds security, you need to be able to answer questions like these. If it really adds security, you must be willing to pay a cost to achieve that security (recall the NoStO principle: count your costs when you count your benefits!). If you can answer questions like these then you are not violating StO, in my opinion. Hal From xeryus at eskimo.com Sat Mar 5 09:08:29 1994 From: xeryus at eskimo.com (Ophir Ronen) Date: Sat, 5 Mar 94 09:08:29 PST Subject: Meeting in Seattle? Message-ID: Morning(or whatever fits your time zone) all, Is anyone in Seattle setting up a link for the meeting? If so, please let me know. Thanks, -Xeryus From hughes at ah.com Sat Mar 5 10:27:54 1994 From: hughes at ah.com (Eric Hughes) Date: Sat, 5 Mar 94 10:27:54 PST Subject: Truly Stealthy PGP In-Reply-To: <199403051533.HAA07296@jobe.shell.portal.com> Message-ID: <9403051818.AA07188@ah.com> >This was discussed some time back on the pgp developers' list, and at that >time the suggestion was made to add a multiple of n to m so that it covered >a fuller range of values. The recipient would then just take the exponent >mod n and try that. What I suggest is making the exponent (the encrypted session key) completely random over the length assigned to it, since that's visible, and just live with a slightly non-flat distribution of exponents mod n. It turns out that this can be made to work just fine. >Mathematically, call L the next multiple of 256 above n. n is the modulus. Divide L by n to get L = t * n + s, s in [0,n). Assume x is random in [0,L). The entropy of x mod n is E = - s (t+1)/L log (t+1)/L - (N-s) t/L log t/L Rearranging, we get: (get out some paper, do the algebra) E = log L/t - s(t+1)/L log( 1 + 1/t ) This makes sense, since if s is zero, E = log n, which is just the entropy of the random distribution of [0,n). What is the smallest value of E? In other words, what's the upper bound of the randomness we can lose? It happens when when t = 1 and when n = L/2+1. This maximize the expression in t and maximizes s at n-2. This minimum value of E is E_min = log L - ( ln 2 - 2/L ln 2 ) In other words, the most entropy we can lose is two bits. That's right, only two bits. Since the entropy of the session key is the length of the modulus, for a 1000 bit key the entropy loss is negligible. Therefore, my recommendation is that the session key representation be chosen randomly over [0,2^k) and to use as an actual session key this value mod n. The effective entropy loss is small enough not to worry about. Eric From hughes at ah.com Sat Mar 5 10:36:45 1994 From: hughes at ah.com (Eric Hughes) Date: Sat, 5 Mar 94 10:36:45 PST Subject: Truly Stealthy PGP In-Reply-To: <9403051818.AA07188@ah.com> Message-ID: <9403051827.AA07207@ah.com> Scratch that. I made an algebra error. I'll repost with the right answer. Eric From tcmay at netcom.com Sat Mar 5 10:58:41 1994 From: tcmay at netcom.com (Timothy C. May) Date: Sat, 5 Mar 94 10:58:41 PST Subject: Stego in Jazz?...The Miles Files Message-ID: <199403051859.KAA14089@mail.netcom.com> Straightahead jazz fans take note! More significant bits follow: * Critics who claim jazz = noise now will understand that jazz evolved in the 1940s as a stego method for communicating with agents in the field. * Hitler was right in suspecting "that Negro music." * Agent Parker developed method of putting signals in Bird calls, with great sax appeal. * Unveiling below of "crypto-jazz" movement. Cryptids are spreading the PGP word. Jazz raves to be the Next Big Thing. From: esharp at panix.com (Elliot Sharp) Newsgroups: rec.music.bluenote Subject: crypto-jazz Date: 3 Mar 1994 12:10:51 -0500 Organization: PANIX Public Access Internet and Unix, NYC Message-ID: <2l55mr$b5s at panix.com> Summary: a night of Keywords: Sharp,Ribot,Berne on Tuesday, March 15, the Cooler (416 W. 14, NYC) will present a night of crypto-jazz with: 10 pm Elliott Sharp's THE CRYPTIDS (Sharp-reeds, guitar w/ Reuben Radding-bass, David Gould-drums) 11 pm Marc Ribot - solo guitar 12 am Tim Berne's BLOODCOUNT (Berne-reeds with quartet) From gtoal at an-teallach.com Sat Mar 5 11:04:23 1994 From: gtoal at an-teallach.com (Graham Toal) Date: Sat, 5 Mar 94 11:04:23 PST Subject: Update on user-level hack to do telnet encryption posted recently Message-ID: <199403051903.TAA24567@an-teallach.com> OK folks, I've started tidying up that hack code I posted recently which outlined a method for rolling your own telnet-style encryption. In particular, I've done the hard bit of making it work with an arbitrary binary 1:1 stream cypher, rather than the original hack which *had* to encrypt printable text as printable text (to get it through 7 bit terminal links). [Note, anyone who didn't look at it too closely because they thought it was only for telnet - look again: it's useful for *any* local to remote connection, even kermit down a serial line, as long as you're calling between unixes.] Now, what I need are volunteers - preferably outside the US and any other country where any relevant patents are valid - to work on a suitable stream cypher. Note you don't have to use any patented technology, as long as whatever you come up with is sufficiently secure for your needs - this will eventually be issued as a modular system, with the default encryption module being rot13. If you don't really care much about the strength of encryption (assuming your only opponents are kids who sniff packets who won't have enough crypto experience to decode even an trivial cypher) then there's a lot to be said for everyone implementing their own variation... just for the amusement of tying up the time of all those more competant people who feel they have to know everything that's going on everywhere in the world. Machine cycles they can afford aplenty; man years are a different question... Anyway, back to the project: Currently there's a trivial interface that you can work to - I suggest for demo purposes just using a hard-coded known key at each end, and we'll do the key exchange stuff after we've got the stream cypher working. Here's the header file: /* Placeholder module for arbitrary stream encryption */ #define STATE_SIZE 128 typedef struct cypherstate { char *unique_tag; char whatever[STATE_SIZE]; long int byteno; /* Add useful stuff here as need be... */ } CYPHER_STATE; void new_cypher(CYPHER_STATE *s, char *unique_tag); char stream_cypher(CYPHER_STATE *s, char byte); Put any state you need in the struct, initialise it (with a known secret key for now) in new_cypher; and supply a function that does a 1:1 encoding of a byte in stream_cypher. Make the function stateless apart from the CYPHER_STATE parameter so that it can be used to encode multiple streams without interference. With a bit of help from you guys, this project shouldn't take more than a week to get a prototype running... When I have a feel for what sort of encryption methods people want, and how precisely they're implemented, I'll know better how to generically code the key-exchange part too. I don't think it's appropriate for me to post any more source over the net. Anyone who wants to discuss this in public rather than by mail, I suggest we stick to alt.sources.d Anyone wants the current sources, send mail to gtoal at an-teallach.com Thanks G PS The sources I have probably won't work anywhere except on BSD systems. If you want to make the framework bit work on other versions of unix, drop me a line about that too. Your programming will have to be up to the level of writing a clone of the unix 'script' command, which is all this program is really. PPS Americans: please don't get either you or me in trouble by mailing me unsolicited gifts of crypto code. I don't want it. The crypto part of this project is for those people in countries where there's no legal barrier to them participating. From phantom at u.washington.edu Sat Mar 5 11:15:28 1994 From: phantom at u.washington.edu (Matt Thomlinson) Date: Sat, 5 Mar 94 11:15:28 PST Subject: Seattle Times, 3/6/94 Message-ID: The Seattle Times' front page story (1984 + 10 years) leads into a few articles on pg 18 that deal with encryption/clipper/privacy. Paul Andrews seems to have a _few_ misconceptions about exactly what the clipper chip will do, but all in all it seems like a good wake-up call. This article is the first in a series in privacy, it says. I'm glad something like this made the front page. mt Matt Thomlinson Say no to the Wiretap Chip! University of Washington, Seattle, Washington. Internet: phantom at u.washington.edu phone: (206) 548-9804 PGP 2.2 key available via email or finger phantom at hardy.u.washington.edu From MINITERS at Citadel.edu Sat Mar 5 11:21:26 1994 From: MINITERS at Citadel.edu (Syl Miniter 803-768-3759) Date: Sat, 5 Mar 94 11:21:26 PST Subject: Looking for listserver Message-ID: <01H9M6T2CNC28WY1E2@citadel.edu> i am interested in setting up a listserver and I would appreciate it if someone can point at a source of some basics on the Internet thanks Syl From pmetzger at lehman.com Sat Mar 5 12:12:11 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sat, 5 Mar 94 12:12:11 PST Subject: Update on user-level hack to do telnet encryption posted recently In-Reply-To: <199403051903.TAA24567@an-teallach.com> Message-ID: <9403052010.AA10820@andria.lehman.com> Graham Toal says: > OK folks, I've started tidying up that hack code I posted recently which > outlined a method for rolling your own telnet-style encryption. I really think this project is a serious mistake. People should, if they insist, produce software compatible with the draft RFCs on telnet encryption and authentication -- although such code has already been written. The notion of putting in all this effort just to avoid having to deal with your system administrator, especially when he should be happy to install such code given the recent rash of internet breakins, seems misplaced to me. Perry From hughes at ah.com Sat Mar 5 12:13:51 1994 From: hughes at ah.com (Eric Hughes) Date: Sat, 5 Mar 94 12:13:51 PST Subject: Truly Stealthy PGP In-Reply-To: <9403051827.AA07207@ah.com> Message-ID: <9403052004.AA07317@ah.com> >Scratch that. I made an algebra error. I'll repost with the right >answer. Scratch the scratch. I thought I'd made an error in my entropy expression, but I hadn't. More confusion to follow, no doubt. I hope it just won't be mine. I kept thinking that the location of the minimum entropy was wrong. I worked out some examples with real numbers to prove to myself that my intuition about the location of the minimum entropy was incorrect. Intuition about entropy is difficult to develop, and I still don't completely have all of it. A word to the wise. Eric From mimir at illuminati.io.com Sat Mar 5 12:30:20 1994 From: mimir at illuminati.io.com (Al Billings) Date: Sat, 5 Mar 94 12:30:20 PST Subject: Meeting in Seattle? In-Reply-To: Message-ID: On Sat, 5 Mar 1994, Ophir Ronen wrote: > Is anyone in Seattle setting up a link for the meeting? If so, please let > me know. I'm in Seattle but my impression is that there aren't many people on the list here. -- (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*) | Al Billings aka Grendel Grettisson | "You are, each one, a priest, | | mimir at io.com | Just for yourself." | | Sysop of The Sacred Grove (206)322-5450 | | | Admin for Troth, The Asatru E-Mail List | -Noble Drew Ali- | (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*) From gtoal at an-teallach.com Sat Mar 5 13:10:03 1994 From: gtoal at an-teallach.com (Graham Toal) Date: Sat, 5 Mar 94 13:10:03 PST Subject: Update on user-level hack to do telnet encryption posted recently Message-ID: <199403052110.VAA27482@an-teallach.com> > OK folks, I've started tidying up that hack code I posted recently which > outlined a method for rolling your own telnet-style encryption. I really think this project is a serious mistake. People should, if they insist, produce software compatible with the draft RFCs on telnet encryption and authentication -- although such code has already been written. The notion of putting in all this effort just to avoid having to deal with your system administrator, especially when he should be happy to install such code given the recent rash of internet breakins, seems misplaced to me. Perry, I'm no longer interested in what you have to say. You've been a wet blanket and have pooh-poohed every practical suggestion I've ever seen anyone making - weren't you one of the first people to post to the netphone project telling us we were all wasting our time? Cypherpunks write code, except when asked not to by Perry Metzger. The point of this code, in case you missed it, is so that people can take responsibility for their own encryption and not have to trust software installed by someone else, just like we all use pgp rather than Clipper. Now, if you don't have anything useful to contribute, shut up and stop trying to discourage those who do. G From hfinney at shell.portal.com Sat Mar 5 13:20:23 1994 From: hfinney at shell.portal.com (Hal) Date: Sat, 5 Mar 94 13:20:23 PST Subject: Truly Stealthy PGP Message-ID: <199403052121.NAA19624@jobe.shell.portal.com> From: hughes at ah.com (Eric Hughes) > What I suggest is making the exponent (the encrypted session key) > completely random over the length assigned to it, since that's > visible, and just live with a slightly non-flat distribution of > exponents mod n. It turns out that this can be made to work just > fine. > > n is the modulus. Divide L by n to get L = t * n + s, s in [0,n). > Assume x is random in [0,L). The entropy of x mod n is > E = log L/t - s(t+1)/L log( 1 + 1/t ) > > What is the smallest value of E? In other words, what's the upper > bound of the randomness we can lose? It happens when when t = 1 and > when n = L/2+1. This maximize the expression in t and maximizes s at > n-2. This minimum value of E is > > E_min = log L - ( ln 2 - 2/L ln 2 ) > > In other words, the most entropy we can lose is two bits. That's > right, only two bits. Since the entropy of the session key is the > length of the modulus, for a 1000 bit key the entropy loss is > negligible. I'm not sure the point of this entropy calculation. For the case n = L/2+1, t=1, it seems to me that the RSA-encrypted session key (sk^e mod n) is never going to have the high bit set, so with K such messages it should be possible to tell that something is going on with probability 1 - 2^-K. > Therefore, my recommendation is that the session key representation be > chosen randomly over [0,2^k) and to use as an actual session key this > value mod n. The effective entropy loss is small enough not to worry > about. > > Eric > If the session key is chosen from [0,L), still the encrypted session key m = sd^e mod n will be uniform in [0,n). I don't quite follow here how exactly we go from something uniform in [0,n) to something uniform in [0,L), if that is what Eric is proposing. Hal From pmetzger at lehman.com Sat Mar 5 13:32:28 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sat, 5 Mar 94 13:32:28 PST Subject: Update on user-level hack to do telnet encryption posted recently In-Reply-To: <199403052110.VAA27482@an-teallach.com> Message-ID: <9403052131.AA10882@andria.lehman.com> Graham Toal says: > I really think this project is a serious mistake. People should, if > they insist, produce software compatible with the draft RFCs on telnet > encryption and authentication -- although such code has already been > written. The notion of putting in all this effort just to avoid having > to deal with your system administrator, especially when he should be > happy to install such code given the recent rash of internet breakins, > seems misplaced to me. > > Perry, I'm no longer interested in what you have to say. You've been > a wet blanket and have pooh-poohed every practical suggestion I've > ever seen anyone making - weren't you one of the first people to > post to the netphone project telling us we were all wasting our time? No I was not. As for this current "idea", with an implementation of an encrypted STANDARD telnet already written and likely available soon for anonymous FTP, I think I'm being sane, not "a wet blanket". You can already get a version of the Cray telnet that implements the authentication code and hack in a reimplementation of the encryption code if you wish. See below for that. However, producing silly non-standard telnet hacks makes little sense. > Cypherpunks write code, except when asked not to by Perry Metzger. > > The point of this code, in case you missed it, is so that people can > take responsibility for their own encryption and not have to trust > software installed by someone else, just like we all use pgp rather > than Clipper. You can't help trusting code installed by someone else. How many of us write our own operating systems from scratch? So long as you have the source code, and the source code to the telnet I am speaking of is widely available, what is the difference? The source code for the authenticating telnet is available from ftp.cray.com(128.162.15.3):src/telnet/telnet.94.02.07.NE.tar.Z Now, David Borman has not been very forthcoming with the encrypting version of this system (although all the hooks are already there) and if anyone wants to take a crack at adding in an implementation of the draft encryption standard (which should be quite quick) that would indeed be a useful effort. I will happily mail a copy of the draft RFC to anyone who doesn't have it and can't get it. Perry From pmetzger at lehman.com Sat Mar 5 13:39:43 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sat, 5 Mar 94 13:39:43 PST Subject: Update on user-level hack to do telnet encryption posted recently In-Reply-To: <9403052131.AA10882@andria.lehman.com> Message-ID: <9403052139.AA10905@andria.lehman.com> "Perry E. Metzger" says: > As for this current "idea", with an implementation of an encrypted > STANDARD telnet already written and likely available soon for > anonymous FTP, I think I'm being sane, not "a wet blanket". By the way, I forgot to mention, the 4.4 BSD domestic release already includes the encrypted telnet. In order to head off foolish reimplementation, perhaps someone would be willing to release the relevant patches to the NE release to turn it into a full encrypting telnet? The code is, after all, already under the Berkeley copyright and thus releasable. Perry From pmetzger at lehman.com Sat Mar 5 13:42:03 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sat, 5 Mar 94 13:42:03 PST Subject: Update on user-level hack to do telnet encryption posted recently In-Reply-To: <9403052131.AA10882@andria.lehman.com> Message-ID: <9403052141.AA10925@andria.lehman.com> "Perry E. Metzger" says: > The source code for the authenticating telnet is available from > > ftp.cray.com(128.162.15.3):src/telnet/telnet.94.02.07.NE.tar.Z > > Now, David Borman has not been very forthcoming with the encrypting > version of this system (although all the hooks are already there) and > if anyone wants to take a crack at adding in an implementation of the > draft encryption standard (which should be quite quick) that would > indeed be a useful effort. I will happily mail a copy of the draft RFC > to anyone who doesn't have it and can't get it. I didn't realize it, but the telnet RFCs and encryption draft RFCs are also available in the same directory on ftp.cray.com Perry From blancw at microsoft.com Sat Mar 5 13:57:46 1994 From: blancw at microsoft.com (Blanc Weber) Date: Sat, 5 Mar 94 13:57:46 PST Subject: New mailing list? Message-ID: <9403052158.AA01627@netmail2.microsoft.com> "I want each reader of these words to reflect on the phrase "implementing culture". If you do not realize the magnitude of this principle and have some respect for its enormity, I would sincerely suggest that your time would be better spent reading some political philosophy and some technological history and pondering over your desires, to make sure that you know them." Okay, Teach. :>) Thanks for the clarification, Eric. I remember some critical statements made about your attitude toward modifications to list and the suggestions which you apparently shot down. I remained silent but wondering. "Cypherpunks is where the politics meets the code. .... Policy separated from development lags the reality of deployment, and necessarily. " These are some things I have thought about, upon reading complaints against the tangential discussions which come up on the list: It is not unimportant to engage in these conversations as they develop, to allow for the associated efforts to achieve precision on attitudes/expectations which counter the rest of the intellectual atmosphere of acceptance, especially when one might be required to produce just cause why things should go in one direction (yours) rather than another (theirs); when you might have to answer to 'authorities' for non-complicity to collectivist programs. Some people do (and some should) struggle for better justification in their own mind, of their position relating to what they themselves do (writing & distributing code which permits alternatives to government-supplied arrangements), of what they advocate to others that they ought to do (positive or negative support for a method/plan of action), or would prevent (as in thwart the progress/implementation of Clipper). It is not unimportant to be clear about the propriety of the motives behind an argument, to be satisfied that one is correct - that it isn't merely 'whining' because one is not getting one's way, or because the government & its advisors are not sufficiently lenient in their outlook; that there is philosophical, logically consistency in the actions/solutions proposed. It is not unproductive to maintain a general awareness among all those who would deem to be of the same "attitudinal alignment". Else how could such a group survive as advocates of ideas promoting complete independence & total autonomy. (euphemism) I myself would welcome the existence of a more thorough elaboration on this subject, from yourself and the others who founded the list: an explanatory FAQ for reference, especially on the matter of "implementing culture", since this implies more than simply effects dealing with government. Blanc From hfinney at shell.portal.com Sat Mar 5 14:03:00 1994 From: hfinney at shell.portal.com (Hal) Date: Sat, 5 Mar 94 14:03:00 PST Subject: Stealth PGP Message-ID: <199403052203.OAA21880@jobe.shell.portal.com> I never saw the posting below here, only on sci.crypt. It seems relevant to the present discussion. I did take a look at the source code to stealth pgp; it is quite simple and nicely done. However it doesn't do anything special about disguising the encrypted session key. It just strips off the two length bytes PGP puts at the front. Not only is this revealing, it also doesn't always work. Apparently the program can't always reconstruct the original mpi length if the encrypted key's size happens to be much less than the modulus. It does print a warning in that case that the file won't be able to be de-stealth'd successfully. Stealth PGP is a nice start but it needs to be improved to be truly stealthy. > >From: qwerty at netcom.com (-=Xenon=-) > >Subject: Stealth for PGP Available. > >Message-ID: > >Organization: PGP Info Clearinghouse. > >Date: Thu, 24 Feb 1994 08:34:24 GMT > >Lines: 188 > > -----BEGIN PGP SIGNED MESSAGE----- > > I have placed Stealth1.0 up for anonymous ftp at netcom.com in > /pub/qwerty as stealth.tar.Z. I am not the author of Stealth. "Henry > Hastur" is the author. I will gladly forward mail to him if you tell me to > do so. My address is qwerty at netcom.com. So far it is only written for > Unix, so don't e-mail me asking for a DOS version or whatever. I'm just a > cheerleader and propagandist, who finally got some very kind soul to > "write me a real encryptor". > > Why Stealth? Wired magazine just gave a plug for the Mac program "Stego" > (ftp to sumex-aim.stanford.edu in /info-mac/cmp) by Romana Machado, which > will, like any steganograph, hide a message in a carrier message. Problem > is, anybody can reverse it, and if you are using PGP, immediately tell > you are one of those drug dealing, child molesting, cryptography users ;-). > Once Stealth is incorporated into such steganographs, then people can't > easily tell that what they've extracted out of that picture of Madonna is > even a message at all. If they don't have the right secret key to decrypt > it, then all they get is garbage. "What message?!" > > Questions: > > 1) What does Stealth have to do with farming? > 2) How do stealth encryptors make the Clipper chip look like a stupid > waste of YOUR tax money? > > [Answers: 1) Zip, 2) By demonstrating that even if the Clipper keys are > stolen, without your secret key they can't even tell you are using PGP]. > > -=Xenon=- > > Stealth V1.0 by Henry Hastur > ---------------------------- > > Stealth is a simple filter for PGP which strips off all identifying header > information to leave only the encrypted data in a format suitable for > steganographic use. That is, the data can be hidden in images, audio > files, text files, CAD files, and/or any other file type that may contain > random data, then sent to another person who can retrieve the data from > the file, attach headers, and PGP decrypt it. > > Stealth is not intended to replace the standardized methods of using > encryption (e.g. ASCII-armoured PGP email) ; in an ideal world we would > all be able to send openly encrypted mail or files to each other with no > fear of reprisals, however there are often cases when this is not possible, > either because the local government does not approve of encrypted > communication, or perhaps because you are working for a company that > does not allow encrypted email but doesn't care about Mandelbrot > GIFs. This is where Stealth and steganography can come into play. > > > Compiling > - - --------- > > Stealth has currently only been tested on BSD and SVR4 Unix (and as > such should work with most varieties of Unix), with both non-ANSI > compilers and ANSI compilers with 'minimal ANSI' flags. In order to > compile the program, you should just be able to extract the files > from the tar file provided, then type 'make'. If that fails you may > need to change the definition of CC and CFLAGS in the makefile to > get it to compile. On machines with gcc, the GNU C compiler, Stealth > can be compiled by simply changing the 'CC=cc' line in makefile to > 'CC=gcc'. > > Stealth has not yet been tested on MS-DOS, but the only likely problems > are with 16-bit integers (you may need to change some occurrences of > int to long in order to get stealth to work), and you will need to > remove the -DUNIX flag from compilations. Hopefully, version 1.1 > will be released shortly with full DOS compatibility. > > > Usage > - - ----- > > Stealth always reads from its standard input and writes to the standard > output, though when adding headers to data the data has to be stored in a > temporary file (see Security Concerns below). > > Command line arguments : > > -c Conventional encryption used rather than public key > -a Add headers (defaults to strip headers) > -v Verbose output. > > Stealth needs to be able to find your pubring.pgp file, which it does > by first checking in the directory pointed to by $PGPPATH, then the > current directory. > > > Examples > - - -------- > > To encrypt a file with PGP and store it in the file pgp.stl prior to > sending : > > pgp -ef < secrets.dat | stealth > pgp.stl > > To encrypt a file with conventional (IDEA) encryption, and pass to a > steganography program called steg_program : > > pgp -fec < secrets.dat | stealth -c | steg_program > > To take the output from a steganographic extraction tool, add headers > for key "Your Id", and decrypt : > > steg_program | stealth -a "Your Id" | pgp -f > secrets.dat > > To take the conventionally encrypted output from a steg program, attach > headers and decrypt : > > steg_program | stealth -ac | pgp -f > secrets.dat > > > Limitations > - - ----------- > > Files can be signed, but can only be encrypted to one recipient - extra > RSA headers for all but the first recipient will be stripped from the > file. In addition, if you specify conventional encryption but pass an > RSA-encrypted file into the filter the RSA-block will be stripped. In > either case, stealth will print out warnings to inform you of this. > > Stealth provides no support for ASCII-armoured PGP messages - it will > only work with the binary output format, and the output will have to > be converted to a useable form after processing, either with a > steganography program or a standard utility such as uuencode. > > Finally, for technical reasons there are potential problems with public > keys of size (typically) 2^n + 1 or 2^n + 2 (e.g. 513 or 1026). If you > are encrypting to a key of a peculiar size, it's possible that the algorithm > used to add headers could fail, but fortunately this can be detected while > stripping the headers, and a warning will be printed. If this warning > appears, > you will probably want to encrypt the data again until a suitably sized > RSA-block is created. > > It is NOT neccesary to remove garbage data that the steganography program > may have added to the end of the PGP-encrypted data. PGP output contains > an encrypted end-of-file mark that allows the program to decrypt correctly > and ignore any trailing garbage. > > > Security Concerns > - - ----------------- > > After passing through the stealth filter, the PGP-encrypted data is > essentially white noise, with no identifying marks, and whilst it may > well have enough peculiarities for an expert cryptanalyst to recognize > it as encrypted data, the probability is much less than would be the > case with a PGP header identifying the recipient attached. > > One other concern is that stealth has to create a temporary file when > reading in data to attach headers, and depending on the build options > chosen the program will store it in either $PGPPATH, the current directory > or /tmp. On Unix machines, the file will be deleted as soon as it is opened, > making it difficult to capture, but on other operating systems the file > will only be deleted when it has been used. (In either case the file will > be zeroed before being closed). > > In addition, some operating systems will use temporary files on your disk > to emulate unix pipes (e.g. MS-DOS) - these files will not be zeroed when > finished with ! > > > Export Restrictions > - - ------------------- > > Stealth is probably not covered by current export restrictions under the > US ITAR regs, but I'm not a lawyer, so if in doubt check it out yourself. > It was written outside the US and imported, so should soon be available > on some European ftp sites as well as US sites. > > > Henry Hastur > > > > > -----BEGIN PGP SIGNATURE----- > Version: 2.3 > > iQCVAgUBLWwfawSzG6zrQn1RAQEjlQP/d85opZ6aMXfFpDu/KQz0DAzFxXNjiSZy > 9l56kIUkmAx0aT5qF3UAg2UTDagiJlFNz6UXFhEKBkDV4JLJPq5C8HtsdpCiSLWr > vVD2IEdASEd9ALCQMLS/YxVv6GG85n+phyoEV5ALsD1f0y4Nbk2Gfb+rexk5rN3a > hFYRUekVuNY= > =pkdK > -----END PGP SIGNATURE----- From hughes at ah.com Sat Mar 5 14:04:51 1994 From: hughes at ah.com (Eric Hughes) Date: Sat, 5 Mar 94 14:04:51 PST Subject: Truly Stealthy PGP In-Reply-To: <199403052121.NAA19624@jobe.shell.portal.com> Message-ID: <9403052155.AA07488@ah.com> OK. Here's the situation again, hopefully more clearly. Unfortunately, more clearly in mathematics often means more notation. Let n be the modulus, and #n be the length of the modulus in bits. Let k be the smallest multiple of eight greater than #n. Let L = 2^k be the bit length of the byte container for n and numbers mod n. Call an encrypted session key as it appears in the cyphertext Q. We want the Q's to be randomly distributed over the interval [0,L). Suppose the encrypted session key R = Q mod n. The integer R is in the interval [0,n), and so can't be evenly distributed over [0,L). The session key S = R^d mod n, where d is the private exponent. The entropy I calculated was the entropy of the distribution of the R's with the prior condition that the Q's were randomly distributed. In other words, if the key is byte-oriented and if the public representation of the encrypted session key reveals zero information, the distribution of the encrypted session keys must be non-random. I calculated exactly how non-random that could possibly be, and the answer was, not much. One more time. We want the encrypted key, as it appears to the world, to look random. So let's assume it _is_ random, and see how that affects the rest of the system. If the encrypted session key, as represented, is random over a range of bytes, it can't be completely random over the modulus in question, since the modulus doesn't divide two to the number of bits. There's some left over, and therefore some numbers map to more encrypted session keys than others. Now, since we have a non-random distribution, we need to see how that affects security, since a non-random distribution lowers the search space for brute force search. I calculated exactly how much it can lower the size of the search space. The maximum decrease in entropy is two bits, or a factor of four smaller. This isn't enough to worry about for large moduli. Therefore, we can conclude that it is safe to use a representation of the encrypted session key which is random. I've left out how we go from a non-uniform encrypted session key (which must be generated with a distribution of the entropy calculated) to a uniform distribution in the representation of the encrypted session key. This is not at all obvious. >If the session key is chosen from [0,L), still the encrypted session >key m = sd^e mod n will be uniform in [0,n). No, in fact it won't be uniform. That was the calculation I just did. >I don't quite follow here >how exactly we go from something uniform in [0,n) to something uniform in >[0,L), if that is what Eric is proposing. You just can't get uniformity over both intervals at the same time. What I showed is that you can tolerate non-uniformity in one range in order to get uniformity in the other. Eric From hayden at krypton.mankato.msus.edu Sat Mar 5 14:08:37 1994 From: hayden at krypton.mankato.msus.edu (Robert A. Hayden) Date: Sat, 5 Mar 94 14:08:37 PST Subject: Looking for listserver In-Reply-To: <01H9M6T2CNC28WY1E2@citadel.edu> Message-ID: On Sat, 5 Mar 1994, Syl Miniter 803-768-3759 wrote: > i am interested in setting up a listserver and I would appreciate it if > someone can point at a source of some basics on the Internet Use archie to located Majordomo (I should know where the source site is, but I don't). It's a relatively straight-forward listserver that uses perl as its processing language. ____ Robert A. Hayden <=> hayden at krypton.mankato.msus.edu \ /__ -=-=-=-=- <=> -=-=-=-=- \/ / Finger for Geek Code Info <=> Political Correctness is \/ Finger for PGP 2.3a Public Key <=> P.C. for "Thought Police" -=-=-=-=-=-=-=- (GEEK CODE 1.0.1) GAT d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++ n-(---) h+(*) f+ g+ w++ t++ r++ y+(*) From 73211.3713 at CompuServe.COM Sat Mar 5 15:53:22 1994 From: 73211.3713 at CompuServe.COM (Loren Fleckenstein) Date: Sat, 5 Mar 94 15:53:22 PST Subject: stego Message-ID: <940305234908_73211.3713_DHI59-2@CompuServe.COM> I'm a newspaper reporter researching a how-to story on crypto. 1) Besides RIPEM, PGP and ViaCrypt PGP, any suggestions for capsule reviews of other public-key products? I'm interested only in public-key implementations. 2) Are there stego programs out there that will weave cipherdata into digital pictures or audio? 3) Has anyone reviewed the AT&T secure phones & modems? Your thoughts? Please reply by e-mail as I am not a list subscriber. I also am a big believer in encrypting all traffic, so here is my public key. I am not looking to quote anyone -- all I need are ideas. However, if you say something temptingly quotable, I'll email you back for permission. Short of your grant of permission, I consider your material for background purposes, i.e., I'm free to use it without attributing where I got it. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.4 mQCNAi16V84AAAEEAMNVRFU+CqFRhaOnnZ5hdY8D0o/3tdwzV08D1p/gLP9l8fYZ LKVFsuIQKzna4PSMoJyeUVWUcBftLQCNX0K+phzqTdpMPEnH82ToH8JGgRg873Fq WaQkzj3M+K3ExYVC2EVFfAvOa1iCyRCSrEr2hfQOP99XYMFS7w8UUf0SamE5AAUR tAVsZGZqcg== =nH+6 -----END PGP PUBLIC KEY BLOCK----- -- Loren Fleckenstein 37211.3713 at cserve.com reporter, The Press-Enterprise office tel. (909) 654-0564 From jim at bilbo.suite.com Sat Mar 5 17:38:04 1994 From: jim at bilbo.suite.com (Jim Miller) Date: Sat, 5 Mar 94 17:38:04 PST Subject: some technical steganography Message-ID: <9403060133.AA22869@bilbo.suite.com> Eric Hughes wrote: > > >What does "appears relatively random" really mean? How do you > >measure the randomness of a sequence of bits? > > Randomness is the wrong measure. Suppose I take 2^10 > random bits and prepend 16 zeros. How random is this? > Almost as random, and this can be made precise. How > compressible is it? Almost incompressible. Now, what > about 2^20 bit? 2^30? > > It is not randomness but recognizability which is at issue. > One of my assumptions was that the stuff you're trying to hide is not recognizable. In one of my posts I used the phrase "unremarkable encrypted message". I should have said "unrecognizable encrypted message". I assert that an "unrecognizable encrypted message" will be a random sequence of bits. Is my assertion correct? Should I be using the phrase "high entropy" instead of "random"? Assume for the moment that there is a way to produce an unrecognizable encrypted message using public-key encryption. (I leave it to the experts to figure out the best way do that.) I still believe that if the reverse stego process frequently produces high entropy bit sequences, even if there is no hidden message, then the steganography system is successful. If the reverse stego process *always* produces a high entropy bit sequence, then the steganography system is perfect. Of course, this assumes there is no other way to detect a hidden message besides reversing the stego process and testing the result. Obviously, if the forward stego process (inserting the bits) leaves telltale traces, then it doesn't matter what the reverse stego process produces. To summrise, I believe a successful steganography system will include the following steps and have the following properties: step 1) encrypt you plaintext. step 2) hide the encrypted message in a public message (duh) property 1) the result of the encryption step should be a random sequence of bits. property 2) the bit insertion process must not leave telltale traces. property 3) the reverse stego process should product frequent "false hits". In other words, the reverse stego process should frequently produce high entropy bit sequences, even if there is no hidden message. Am I correct? Jim_Miller at suite.com From jef at ee.lbl.gov Sat Mar 5 17:46:04 1994 From: jef at ee.lbl.gov (Jef Poskanzer) Date: Sat, 5 Mar 94 17:46:04 PST Subject: better way to generate a permutation? Message-ID: <9403060145.AA21067@hot.ee.lbl.gov> I'm putting the polish on pnmstega/pnmdestega. Currently they spend the largest part of their time generating the permuted list of bit positions to use for storing the data bits. Not surprising, I knew the first version would be slow - it actually mallocs an array, fills it with numbers, and shuffles them. Now I'm looking for suggestions on better methods. I looked in Knuth, Sedgewick, and Schneier, and didn't find anything. Send email if you've got an idea. Something with a bit vector might work. --- Jef From hughes at ah.com Sat Mar 5 21:37:13 1994 From: hughes at ah.com (Eric Hughes) Date: Sat, 5 Mar 94 21:37:13 PST Subject: some technical steganography In-Reply-To: <9403060133.AA22869@bilbo.suite.com> Message-ID: <9403060528.AA07968@ah.com> >I assert that an "unrecognizable encrypted message" will be a random >sequence of bits. Is my assertion correct? It's neither correct or incorrect because the specific notion of randomness hasn't been specified. Your statement is falsifiable, however, since sometimes a non-random string of bits is what you want to get out, if what you would expect to get out normally was also non-random. And you want them to be non-random in the same way. >Should I be using the >phrase "high entropy" instead of "random"? No. This was the notion of random I pointed out that didn't work. If you add 16 zeros to the front of a gigabit random message, that's pretty recogizable, even though the entropy is may be very close to maximum. >Of course, this assumes there is no other way to detect a hidden >message besides reversing the stego process and testing the result. Don't count on it. Statistical tests can find correlations you hadn't suspected were there. In fact, for some message types, _not_ finding the correlations may indicate dithering, or maybe a steganographic message. >property 3) the reverse stego process should product frequent "false >hits". In other words, the reverse stego process should frequently >produce high entropy bit sequences, even if there is no hidden >message. If the prior probabilities of the message type that you're hiding in are not random, the steganographic extraction shouldn't be either, because then there's a distinction between an unaltered container and an incoded one. Eric From hughes at ah.com Sat Mar 5 22:01:23 1994 From: hughes at ah.com (Eric Hughes) Date: Sat, 5 Mar 94 22:01:23 PST Subject: Stealth PGP In-Reply-To: <199403052203.OAA21880@jobe.shell.portal.com> Message-ID: <9403060552.AA08011@ah.com> >However it doesn't do anything special about disguising the >encrypted session key. And as Hal and I have been discussing, that's not at all an obvious problem. A filter for PGP messages cannot make them completely random for all the reasons presented. The session keys must be generated differently if the encrypted form if them is to have a flat distribution. To wit, PGP itself must change in order to make a random PGP output format. Eric From hughes at ah.com Sat Mar 5 22:14:10 1994 From: hughes at ah.com (Eric Hughes) Date: Sat, 5 Mar 94 22:14:10 PST Subject: Update on user-level hack to do telnet encryption posted recently Message-ID: <9403060605.AA08029@ah.com> Perry doesn't like Graham's hack for telnet style encryption. Graham doesn't like Perry's attitude. Such a _small_ teapot. For the forseeable future, there will be the need for link encryption where one is connecting to a site where the far end doesn't have encrypted telnet available, _for_whatever_reason_at_all. There are lots of reasons, e.g. site managers are busy and the user did not plan in advance. It doesn't really matter. If you can't alter the remote end except by a user process, that's what you use. Perry is absolutely correct that this hack is very bad as a long-term solution, but it is labelled a hack, after all. Nevertheless, there is need for a short term solution. Graham seems to have provided one part of that. Great. Just because you shouldn't need to be using it in two years is no reason to say it shouldn't be written. Eric From rishab at dxm.ernet.in Sun Mar 6 01:11:34 1994 From: rishab at dxm.ernet.in (rishab at dxm.ernet.in) Date: Sun, 6 Mar 94 01:11:34 PST Subject: No Subject Message-ID: Everyone's talking about encrypted telnet. Has anyone at least READ the Kerberos FAQ? It's been in use for a while, and, to quote... > Kerberos is a network authentication system for use on physically > insecure networks, based on the key distribution model presented by > Needham and Schroeder.[3] It allows entities communicating over > networks to prove their identity to each other while preventing > eavsdropping or replay attacks. It also provides for data stream > integrity (detection of modification) and secrecy (preventing > unauthorized reading) using cryptography systems such as DES. > Practically speaking, Kerberos is mostly used in application-level > protocols (ISO model level 7), such as TELNET or FTP, to provide user > to host security. It is also used, though less frequently, as the > implicit authentication system of data stream (such as SOCK_STREAM) or > RPC mechanisms (ISO model level 6). It could also be used at a lower > level for host to host security, in protocols like IP, UDP, or TCP Being more 'official' than PGP, only a totally export-safe version has got out to ftp.funet.fi. Of course, it could be possible to patch PGP or something else into Bones, as the non-encrypting Kerberos is called. > An experimental Telnet Authentication Option has been > defined, and is described in RFC1416. (see also RFC1411). > These RFC's only define how > /authentication/ is to be performed; the standard for full encryption > is still under development. > An implementation of Kerberos V4 telnet is available via anonymous ftp > from ftp.uu.net, in /networking/telnet.91.03.25.tar.Z, but it predates > The IETF Common Authentication Technology Working Group is > currently defining security extensions for the FTP protocol. An > Internet Draft describing their work, and the source code for a > modified ftp/ftpd with the extensions, are now available > thumper.bellcore.com:pub/lunt/ftp.tar.Z > net-dist.mit.edu:tytso/ftp-wg/ftp.tar.Z ----------------------------------------------------------------------- Rishab Aiyer Ghosh "What is civilisation rishab at doe.ernet.in, rishab at dxm.ernet.in but a ribonucleic Voicemail +91 11 3760335; Vox/Fax/Data 6853410 hangover?" H-34C Saket New Delhi 110017 INDIA ----------------------------------------------------------------------- From rishab at dxm.ernet.in Sun Mar 6 01:13:35 1994 From: rishab at dxm.ernet.in (rishab at dxm.ernet.in) Date: Sun, 6 Mar 94 01:13:35 PST Subject: No Subject Message-ID: sdw at meaddata.com (Stephen Williams): > on pictures with few colors and a large amount of a small number of > colors (like cartoons, etc. with a backround), you could use the > unused color table entries. You set these to be the same colors as > the correspondingly largest used colors and use them when juxtaposed > with their color. This, and other similar methods will of course only work with GIFs; the problem is that GIFs compress, and the loss of compression caused by adding to the color table could be noticed, as could the fact that there are multiple entries with the same value. It's also somewhat more complicated for stego users to figure out where the data is - unless you use a 'standard' header or format, which is as known to the NSA as to cypherpunks. What worries me more about many stego methods is their assumption that 'stegging' a picture will not be noticed. I am not so sure, even if you stick to the LSB of an 8-bit blue channel of a 24-bit hi-res scan. Things like the abnormal frequency of 1s as mentioned earlier, are almost as easy to build into your stego program as to detect. I've worked a lot with images, particularly image recognition, and have seen many surprising similarities among pictures of some category that are human-noticable only after considerable statistical analysis (or filtering through sophisticated neural networks). It may well be possible to develop highly CPU-intensive techniques that can detect, or indicate suspicion towards, 'stegged' images. Unless, of course, equally complex stego techniques are developed, which will probably have the extremely low message-to-image ratio of the old 'letter to granny' codes. (Message in third letter of alternate words, etc., in innocuous, plausible letter.) This whole cat and mouse game with the authorities reminds me of the reaction I had to the story in Wired 2.02 on the Stealth watchers. OK, intrepid renegades take zoom-lens photos and listen in to secret frequencies, but only because US authorities don't REALLY mind. Come on, if Big Brother were really serious, Phil Zimmerman (and most of us on this list) would have been shot long ago, democracy be damned. As it so happens, PEOPLE still vote, not SPIES. From julf at penet.fi Sun Mar 6 02:45:50 1994 From: julf at penet.fi (Johan Helsingius) Date: Sun, 6 Mar 94 02:45:50 PST Subject: Update on user-level hack to do telnet encryption posted recently In-Reply-To: <199403052110.VAA27482@an-teallach.com> Message-ID: <199403061045.AA21401@lassie.eunet.fi> > Perry, I'm no longer interested in what you have to say. You've been > a wet blanket and have pooh-poohed every practical suggestion I've > ever seen anyone making - weren't you one of the first people to > post to the netphone project telling us we were all wasting our time? > > Cypherpunks write code, except when asked not to by Perry Metzger. Sigh. If trying to avoid re-inventing square wheels and duplicating stuff that has already been done is being a wet blanket, then I have to say I am very proud to join Perry in the "pseudo-tentacle wet blanket club". One of the major reasons I still read this list is so that I can find out when I am wasting my time - if somebody has come up with a workable solution, and it seems likely to gain wide acceptance, it is rather stupid of me to hide in my magical cyberspace fairytale virtualland and write code that no-one is going to pick up and use. But of course I am free to do so, should I so desire... Julf From gtoal at an-teallach.com Sun Mar 6 04:39:22 1994 From: gtoal at an-teallach.com (Graham Toal) Date: Sun, 6 Mar 94 04:39:22 PST Subject: Update on user-level hack to do telnet encryption posted recently Message-ID: <199403061234.MAA27780@an-teallach.com> As for this current "idea", with an implementation of an encrypted STANDARD telnet already written and likely available soon for anonymous FTP, I think I'm being sane, not "a wet blanket". You can already get a version of the Cray telnet that implements the authentication code and hack in a reimplementation of the encryption code if you wish. See below for that. However, producing silly non-standard telnet hacks makes little sense. Perry, I *already* have the bsd4.4 Kerberized telnet with DES that comes with the BSDI distribution (original code in the US, a re-implementation on supplementary floppies in the UK) - I've had it for half a year now, and you know what? - it's of no use to me at all. Not *one* of the dozen odd sites I telnet to is running it. Maybe in several years time we'll all be running the same encrypted telnet, but for now I want *something* to keep the nosey little kids from reading my packets and if I have to ftp a short source and compile it every time I log in somewhere then that's what I'll do. I bet my telnet sessions are secure a lot sooner than yours are. The degree of that security depends to some extent on how much help I get implementing a stream cypher because I'm not sure I trust myself to do it properly. So I would really appreciate if you don't think this project is worthwhile, that you simply don't contribute rather than going out of your way to encourage others not to as well. G From leonar716 at aol.com Sun Mar 6 04:54:57 1994 From: leonar716 at aol.com (leonar716 at aol.com) Date: Sun, 6 Mar 94 04:54:57 PST Subject: delete from list Message-ID: <9403060753.tn279686@aol.com> delete my name from cypherpunks BBS From pmetzger at lehman.com Sun Mar 6 07:16:57 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sun, 6 Mar 94 07:16:57 PST Subject: Update on user-level hack to do telnet encryption posted recently In-Reply-To: <9403060605.AA08029@ah.com> Message-ID: <9403061516.AA17049@andria.lehman.com> Eric Hughes says: > For the forseeable future, there will be the need for link encryption > where one is connecting to a site where the far end doesn't have > encrypted telnet available, _for_whatever_reason_at_all. There are > lots of reasons, e.g. site managers are busy and the user did not plan > in advance. It doesn't really matter. If you can't alter the remote > end except by a user process, that's what you use. I strongly disagree. If you truly insist, run your own telnetd on the remote machine. Don't run a hack. However, the right solution is to get the site manager to replace their telnet, a process that takes minutes and which, given the current epidemic of line tapping, is of obvious necessity even to the brain damaged. As I've noted, however, its trivial to run your own telnetd on another port if you absolutely insist. Perry From sinclai at ecf.toronto.edu Sun Mar 6 07:18:13 1994 From: sinclai at ecf.toronto.edu (SINCLAIR DOUGLAS N) Date: Sun, 6 Mar 94 07:18:13 PST Subject: Standard for SteGAnography In-Reply-To: <9403050751.AA13101@toad.com> Message-ID: <94Mar6.101754edt.11542@cannon.ecf.toronto.edu> > > know = 100% objective certainty > Well, OTP gives you this. Probabilistic encryption does too, I > think (the original version -- not the practical version). Quantum > cryptography is pretty close, depending on how much trust you place > in the laws of physics. Granted, none of these are very useful. Don't forget Dining Cryptographer's nets and CalShad nets. From pmetzger at lehman.com Sun Mar 6 07:26:47 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sun, 6 Mar 94 07:26:47 PST Subject: Update on user-level hack to do telnet encryption posted recently In-Reply-To: <199403061234.MAA27780@an-teallach.com> Message-ID: <9403061526.AA17058@andria.lehman.com> Graham Toal says: > Perry, I *already* have the bsd4.4 Kerberized telnet with DES that comes with > the BSDI distribution (original code in the US, a re-implementation on > supplementary floppies in the UK) Not the same program at all. Why don't you actually read some of the RFCs instead of making yourself look foolish? > Not *one* of the dozen odd sites I telnet to is running it. Have you asked them to run it? Have you considered simply running the daemon yourself on another port instead of implementing some crude hack? Perry From werner at mc.ab.com Sun Mar 6 10:07:08 1994 From: werner at mc.ab.com (tim werner) Date: Sun, 6 Mar 94 10:07:08 PST Subject: Update on user-level hack to do telnet encryption posted recently In-Reply-To: <9403061516.AA17049@andria.lehman.com> Message-ID: <199403061806.NAA19210@sparcserver.mc.ab.com> >From: "Perry E. Metzger" >Sender: owner-cypherpunks at toad.com >... As I've noted, however, >its trivial to run your own telnetd on another port if you absolutely >insist. > >Perry How do you do that? From mg5n+ at andrew.cmu.edu Sun Mar 6 10:48:27 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Sun, 6 Mar 94 10:48:27 PST Subject: Stealth PGP Message-ID: There are actually several clever ways that you can get around the problem with the RSA encrypted data being less than the modulus. The simplest is to encrypt it more than once. Suppose you have a modulus m of legnth n. You then create a block of data to encrypt, b, of legnth n. If b is less than m, encrypt it with RSA. If not, don't encrypt it. Then take 2^n-b-1 (which, btw, is the same as xoring b with all one-bits). If that result is less than m, encrypt it with RSA. Since m is greater than half of 2^n (it must be, otherwise it would be less than legnth n), all possible plaintexts will be encrypted at least once with RSA, some twice. This does leave a somewhat uneven distribution of values when comparing plaintext and ciphertext (which can be minimized by more encryptions), but that only shows up when and if the message is decrypted; as long as you use random padding properly before encrypting, the encrypted data will look completely random. My ideal "Stealth-PGP" would work something like this: Take a file, encrypt it with a random session key, prepend the session key to the file, encrypt the first n bytes (which include the session key and part of the encrypted data) with RSA if it's less than m, XOR it (reverse all bits), and then encrypt with RSA if that's less than m. Actually, putting the data inside the RSA might not be a good idea, it would not work well for small files unless you added a legnth byte. Maybe the RSA part could just be filled with random padding... From banisar at washofc.cpsr.org Sun Mar 6 11:06:16 1994 From: banisar at washofc.cpsr.org (Dave Banisar) Date: Sun, 6 Mar 94 11:06:16 PST Subject: Time Article on Clipper Message-ID: <9403061401.AA55948@Hacker2.cpsr.digex.net> Time Magazine June 7, 1994 TECHNOLOGY WHO SHOULD KEEP THE KEYS? The U.S. government wants the power to tap into every phone, fax and computer transmission BY PHILIP ELMER-DEWITT Until quite recently, cryptography -- the science of making and breaking secret codes -- was, well, secret. In the U.S. the field was dominated by the National Security Agency, a government outfit so clandestine that the U.S. for many years denied its existence. The NSA, which gathers intelligence for national security purposes by eavesdropping on overseas phone calls and cables, did everything in its power to make sure nobody had a code that it couldn't break. It kept tight reins on the ''keys'' used to translate coded text into plain text, prohibiting the export of secret codes under U.S. munitions laws and ensuring that the encryption scheme used by business -- the so-called Digital Encryption Standard -- was weak enough that NSA supercomputers could cut through it like butter. But the past few years have not been kind to the NSA. Not only has its cover been blown, but so has its monopoly on encryption technology. As computers -- the engines of modern cryptography -- have proliferated, so have ever more powerful encryption algorithms. Telephones that offered nearly airtight privacy protection began to appear on the market, and in January U.S. computermakers said they were ready to adopt a new encryption standard so robust that even the NSA couldn't crack it. Thus the stage was set for one of the most bizarre technology-policy battles ever waged: the Clipper Chip war. Lined up on one side are the three- letter cloak-and-dagger agencies -- the NSA, the CIA and the FBI -- and key policymakers in the Clinton Administration (who are taking a surprisingly hard line on the encryption issue). Opposing them is an equally unlikely coalition of computer firms, civil libertarians, conservative columnists and a strange breed of cryptoanarchists who call themselves the cypherpunks. At the center is the Clipper Chip, a semiconductor device that the NSA developed and wants installed in every telephone, computer modem and fax machine. The chip combines a powerful encryption algorithm with a ''back door'' -- the cryptographic equivalent of the master key that opens schoolchildren's padlocks when they forget their combinations. A ''secure'' phone equipped with the chip could, with proper authorization, be cracked by the government. Law-enforcement agencies say they need this capability to keep tabs on drug runners, terrorists and spies. Critics denounce the Clipper -- and a bill before Congress that would require phone companies to make it easy to tap the new digital phones -- as Big Brotherly tools that will strip citizens of whatever privacy they still have in the computer age. In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two-thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it. The battle lines were first drawn last April, when the Administration unveiled the Clipper plan and invited public comment. For nine months opponents railed against the scheme's many flaws: criminals wouldn't use phones equipped with the government's chip; foreign customers wouldn't buy communications gear for which the U.S. held the keys; the system for giving investigators access to the back-door master codes was open to abuse; there was no guarantee that some clever hacker wouldn't steal the keys. But in the end the Administration ignored the advice. In early February, after computer- industry leaders had made it clear that they wanted to adopt their own encryption standard, the Administration announced that it was putting the NSA plan into effect. Government agencies will phase in use of Clipper technology for all unclassified communications. Commercial use of the chip will be voluntary -- for now. It was tantamount to a declaration of war, not just to a small group of crypto-activists but to all citizens who value their privacy, as well as to telecommunications firms that sell their products abroad. Foreign customers won't want equipment that U.S. spies can tap into, particularly since powerful, uncompromised encryption is available overseas. ''Industry is unanimous on this,'' says Jim Burger, a lobbyist for Apple Computer, one of two dozen companies and trade groups opposing the Clipper. A petition circulated on the Internet electronic network by Computer Professionals for Social Responsibility gathered 45,000 signatures, and some activists are planning to boycott companies that use the chips and thus, in effect, hand over their encryption keys to the government. ''You can have my encryption algorithm,'' said John Perry Barlow, co-founder of the Electronic Frontier Foundation, ''when you pry my cold dead fingers from my private key.'' The seeds of the present conflict were planted nearly 20 years ago, when a young M.I.T. student named Whitfield Diffie set out to plug the glaring loophole in all traditional encryption schemes: their reliance on a single password or key to encode and decode messages. Ultimately the privacy of coded messages is a function of how carefully the secret decoder keys are kept. But people exchanging messages using conventional coding schemes must also find a way to exchange the key, which immediately makes it vulnerable to interception. The problem is compounded when encryption is employed on a vast scale and lists of keys are kept in a central registry. Diffie's solution was to give everybody two keys -- one that could be widely distributed or even published in a book, and a private key known only to the user. For obscure mathematical reasons, a message encoded with either key could be decoded with the other. If you send a message scrambled with someone's public key, it can be turned back into plain text only with that person's private key. The Diffie public-key encryption system could solve one of the big problems facing companies that want to do business on the emerging information highway: how to collect the cash. On a computer or telephone network, it's not easy to verify that the person whose name is on a credit card is the one who is using it to buy a new stereo system -- which is one of the reasons catalog sales are rife with fraud. But if an order confirmation encoded with someone's public key can be decoded by his or her private key -- and only his or her private key -- that confirmation becomes like an unforgeable digital signature. However, public-key encryption created a headache for the NSA by giving ordinary citizens -- and savvy criminals -- a way to exchange coded messages that could not be easily cracked. That headache became a nightmare in 1991, when a cypherpunk programmer named Phil Zimmermann combined public-key encryption with some conventional algorithms in a piece of software he called PGP -- pretty good privacy -- and proceeded to give it away, free of charge, on the Internet. Rather than outlaw PGP and other such programs, a policy that would probably be unconstitutional, the Administration is taking a marketing approach. By using its purchasing power to lower the cost of Clipper technology, and by vigilantly enforcing restrictions against overseas sales of competing encryption systems, the government is trying to make it difficult for any alternative schemes to become widespread. If Clipper manages to establish itself as a market standard -- if, for example, it is built into almost every telephone, modem and fax machine sold -- people who buy a nonstandard system might find themselves with an untappable phone but no one to call. That's still a big if. Zimmermann is already working on a version of PGP for voice communications that could compete directly with Clipper, and if it finds a market, similar products are sure to follow. ''The crypto genie is out of the bottle,'' says Steven Levy, who is writing a book about encryption. If that's true, even the nsa may not have the power to put it back. Reported by David S. Jackson/San Francisco and Suneel Ratan/Washington Copyright 1994 Time Inc. All rights reserved. Transmitted: 94-03-06 13:04:08 EST From hfinney at shell.portal.com Sun Mar 6 11:21:28 1994 From: hfinney at shell.portal.com (Hal) Date: Sun, 6 Mar 94 11:21:28 PST Subject: Truly Stealthy PGP (algorithm) Message-ID: <199403061922.LAA26901@jobe.shell.portal.com> (I'm having a bit of trouble with my mail UA; all of my saved messages on this thread keep disappearing, so I apologize for a slight lack of continuity here. I'm having to work solely from memory of the earlier discussion.) If I understand Eric's general idea, we would keep trying session keys under a set of rules which would lead to the desired statistical distribution of the encrypted key. Here is an algorithm which would work. (I hope I am remembering the notation Eric used correctly.) Let L be the next power of 256 above the modulus n. Let t be the integer part of L/n, so that L = n*t + s with s in [0,n). Call the PGP IDEA session key SK, and the encrypted version of that m = SK^e. Now do these steps: 1) Pick a random SK in [0,n). 2) RSA-encrypt it to form m = SK^e mod n. 3) Choose a random k in [0,t]. 4) Calculate the "stegged" encrypted key as M = m + k*n. This will be uniform in [0,(t+1)*n) if m is uniform in [0,n), which I think it is. 5) if M is not in [0,L) (i.e. if M >= L) then go back to step 1. 6) Otherwise store M as a raw binary number taking log base 256 of L bytes. The idea is that once we get M uniform in [0,(t+1)*n) we can make it uniform in [0,L) simply by rejecting those candidates which were too high. This will only happen if k=t and m>=s. Now, it seems to me that the worst case for rejection is when n=L-1, in which case t=1, s=1, and almost one-half of all initial SK choices will be rejected. Following Eric's reasoning, this would be an effective loss of one bit of key length, from say 1024 to 1023, which is tolerable. (Eric actually suggested that as many as two bits could be lost, but I don't see that happening with this algorithm. It doesn't really matter anyway because both 1 and 2 are so small.) Using this algorithm with the current Stealth PGP would produce a "truly stealthy" version which I think would be indistinguishable from random bytes without access to the receiver's private key. Hal From banisar at washofc.cpsr.org Sun Mar 6 11:41:42 1994 From: banisar at washofc.cpsr.org (Dave Banisar) Date: Sun, 6 Mar 94 11:41:42 PST Subject: Time Article on Clipper Message-ID: <9403061445.AA48291@Hacker2.cpsr.digex.net> > Message-Id: <9403061401.AA55948 at Hacker2.cpsr.digex.net> > Date: Sun, 6 Mar 1994 14:01:55 -0500 > From: Dave Banisar > To: clipper at washofc.cpsr.org > Subject: Time Article on Clipper > Sender: owner-cypherpunks at toad.com > Precedence: bulk > > Time Magazine June 7, 1994 > > > TECHNOLOGY > > WHO SHOULD KEEP THE KEYS? > oops I got ahead of myself there. That should be March 14. Look for it on your newsstand tomorrow. From gtoal at an-teallach.com Sun Mar 6 12:00:49 1994 From: gtoal at an-teallach.com (Graham Toal) Date: Sun, 6 Mar 94 12:00:49 PST Subject: Update on user-level hack to do telnet encryption posted recently Message-ID: <199403062000.UAA17352@an-teallach.com> > Perry, I *already* have the bsd4.4 Kerberized telnet with DES that comes with > the BSDI distribution (original code in the US, a re-implementation on > supplementary floppies in the UK) Not the same program at all. Why don't you actually read some of the RFCs instead of making yourself look foolish? Well if you have nothing useful to contribute but won't shut up anyway, I will. This conversation is over. > Not *one* of the dozen odd sites I telnet to is running it. Have you asked them to run it? Have you considered simply running the daemon yourself on another port instead of implementing some crude hack? I already do this. Goodbye. :: ^From.*metzger |/dev/null G From pmetzger at lehman.com Sun Mar 6 12:09:16 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sun, 6 Mar 94 12:09:16 PST Subject: Update on user-level hack to do telnet encryption posted recently In-Reply-To: <199403062000.UAA17352@an-teallach.com> Message-ID: <9403062009.AA17340@andria.lehman.com> Graham Toal says: > Well if you have nothing useful to contribute but won't shut up anyway, > I will. This conversation is over. For the benefit of those who aren't being petulant, I will repeat: The existing, already implemented and available, cryptographic authentication (but not encrypted) version of the new BSD telnet is available from: ftp.cray.com(128.162.15.3):src/telnet/telnet.94.02.07.NE.tar.Z This is not theoretical code; it really exists. See for yourself. No, it doesn't just do kerberos. The proposed telnet encryption and authentication RFCs are available in the same directory. The BSD 4.4 domestic distribution already has the encrypted version of the code in it; perhaps someone should "liberate" it. Those wishing to run an encrypted telnet to a remote machine that does not support the new telnet options should ask the remote system administrator to install the new telnet, which compiles on virtually every architecture around, including SVR4 (or at least Solaris). Failing that, you can run your own telnetd on the remote host. Sorry if suggesting that people use already existing code is being a "wet blanket". Perry From jmueller at gac.edu Sun Mar 6 13:42:04 1994 From: jmueller at gac.edu (Joel T Mueller) Date: Sun, 6 Mar 94 13:42:04 PST Subject: PGP (surprise, surprise..) Message-ID: <9403062141.AA06273@gac.edu> Greetings, Could anyone tell me, is it true that PGP 2.3 was watered down to appease the RSA folks? If so, would it be a better idea to use 2.2? Thanks. -- Joel Mueller - GAT/O -d+(---) -p+ c++@ l+ u++ e m+ s+/- n- h-- f+@ g+(-) w+ t(--) ry? PGP 2.3a Public Key : finger jmueller at gac.edu or on keyservers. 0C6D75 01 0E 16 A7 29 C4 48 75 54 CD 99 09 88 88 3C 39 From fhalper at pilot.njin.net Sun Mar 6 13:48:51 1994 From: fhalper at pilot.njin.net (Frederic Halper) Date: Sun, 6 Mar 94 13:48:51 PST Subject: Mondex card Message-ID: <9403062148.AA23777@pilot.njin.net> I don't know if you all have heard of the Mondex card that is going to be impl -emented in England. Does anyone have any info/articles on it (the New York Times had a small piece in the Sunday Magazine)? Will foreigners be given Mondex cards when they enter the country? Reuben Halper PGP key available on request From jim at bilbo.suite.com Sun Mar 6 16:17:41 1994 From: jim at bilbo.suite.com (Jim Miller) Date: Sun, 6 Mar 94 16:17:41 PST Subject: some technical steganography Message-ID: <9403070012.AA20650@bilbo.suite.com> > >> I assert that an "unrecognizable encrypted message" will be a >> random sequence of bits. Is my assertion correct? > > It's neither correct or incorrect because the specific > notion of randomness hasn't been specified. > I don't understand what you mean by "specific notion of randomness hasn't been specified". How many different "notions of randomness" are there? > Your statement is falsifiable, however, since > sometimes a non-random string of bits is what you want to > get out, if what you would expect to get out normally was > also non-random. And you want them to be non-random in the > same way. > I agree. The output of the reverse stego process should produce similar results, regardless of the presence of a hidden message. That's the point I've been trying to make. I've been attempting to make that point by describing a hypothetical stego system that, when run in reverse, produces a random sequence of bits. I suppose there could be other hypothetical stego systems that produce non-random output, but then you would need a decryption system that could understand and decrypted that non-random output. I prefer random bit sequences. Or perhaps I should say - bit sequences with no apparent structure. > > Of course, this assumes there is no other way to detect a > > hidden message besides reversing the stego process and > > testing the result. > > > > Don't count on it. Statistical tests can find > correlations you hadn't suspected were there. In fact, > for some message types, _not_ finding the correlations > may indicate dithering, or maybe a steganographic > message. > I agree completely. This is a large part of what makes effective steganography so difficult to achieve. Jim_Miller at suite.com From norm at netcom.com Sun Mar 6 16:34:06 1994 From: norm at netcom.com (Norman Hardy) Date: Sun, 6 Mar 94 16:34:06 PST Subject: Format of PGP ciphered message Message-ID: <199403070034.QAA26077@mail.netcom.com> Is there any specification of the format of a PGP enciphered message short of the program itself? From wcs at anchor.ho.att.com Sun Mar 6 16:51:22 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Sun, 6 Mar 94 16:51:22 PST Subject: PGP (surprise, surprise..) Message-ID: <9403070050.AA04935@anchor.ho.att.com> Joel Mueller asks: > Could anyone tell me, is it true that PGP 2.3 was watered down to > appease the RSA folks? If so, would it be a better idea to use 2.2? > Thanks. No, of course it wasn't. There was some hoax article on the network purporting that PGP was rigged, which didn't even have Phil's name right. First of all, you can look at the code yourself, and see the differences between 2.2 and 2.3 and successors - the discussion on the net centered around bug fixes and getting things to work consistently across platforms. Second (or zeroth), RSA has been annoyed at Phil for a while :-) Among other things that have been done to deal with this, Phil is no longer developing mainstream freeware PGP, though he has worked on licensed commercial versions like ViaCrypt. The PGP official development is going on outside the US, where it's not covered by the PKP/RSA patents and where there isn't a problem exporting the code (US ITAR doesn't forbid importing crypto software.) So don't worry. If you're concerned about not violating RSA's patent, buy the VIaCrypt port for $100 (plus shipping and sales tax.) Bill # Bill Stewart AT&T Global Information Solutions, aka NCR Corp # 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204 fax-6399 # email bill.stewart at pleasantonca.ncr.com billstewart at attmail.com # ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465 From pmetzger at lehman.com Sun Mar 6 17:05:49 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Sun, 6 Mar 94 17:05:49 PST Subject: Format of PGP ciphered message In-Reply-To: <199403070034.QAA26077@mail.netcom.com> Message-ID: <9403070104.AA17554@andria.lehman.com> Norman Hardy says: > Is there any specification of the format of a PGP enciphered message short > of the program itself? Yes. It comes with the PGP docs. Perry From avalon at coombs.anu.edu.au Sun Mar 6 18:21:38 1994 From: avalon at coombs.anu.edu.au (Darren Reed) Date: Sun, 6 Mar 94 18:21:38 PST Subject: Update on user-level hack to do telnet encryption posted recently In-Reply-To: <9403062009.AA17340@andria.lehman.com> Message-ID: <9403070221.AA21299@toad.com> Has anyone got an encrypted version of that port bouncer program done yet ? And a `client' to go with it (be useful). I figure this could be used to solve the telnet problem... but does anyone have any suggestions for rlogin or just disable it ? From dmandl at panix.com Sun Mar 6 18:21:43 1994 From: dmandl at panix.com (David Mandl) Date: Sun, 6 Mar 94 18:21:43 PST Subject: PGP (surprise, surprise..) Message-ID: <199403070221.AA19552@panix.com> jmueller at gac.edu says: >Greetings, > > Could anyone tell me, is it true that PGP 2.3 was watered down to >appease the RSA folks? If so, would it be a better idea to use 2.2? Thanks. Completely untrue. I can assure you that RSA was no more appeased by 2.3 than by 2.2, though there is now of course a truly legal version in ViaCrypt PGP. Source code for the guerilla-ware versions is as always available for your inspection, and you're free to compile it yourself. You should use the latest one, period (I believe it's currently 2.3a for MS-DOS and UNIX; MacPGP is 2.3). --Dave. -- Dave Mandl dmandl at panix.com From hughes at ah.com Sun Mar 6 18:37:08 1994 From: hughes at ah.com (Eric Hughes) Date: Sun, 6 Mar 94 18:37:08 PST Subject: some technical steganography In-Reply-To: <9403070012.AA20650@bilbo.suite.com> Message-ID: <9403070228.AA09368@ah.com> >How many different "notions of randomness" >are there? Notions of randomness fall into two basic categories, probabilistic and statistical. The dividing line between the two of them is whether you are doing inference forward or reverse. In both cases the randomness means evenly distributed. Probabilistic randomness is inference forward. One assumes a distribution of states before, the priors, and calculates the expected distribution of states after, the posteriors. Quantum mechanical randomness is probabilistic randomness, since quantum randomness is held to be inherent in nature, and from that predictions can be made about the future. The analysis of gambling strategies is probabilistic, since one assumes something random, like dice rolls or deck shuffles, and infers what the likely outcomes might be. Statistical randomness is inference backward. One takes an observed set of posteriors and tries to deduce whatever is available about the priors. Cryptographic randomness is of this nature, since one is presented with ciphertext and asked to figure out the plaintext. Two major questions about statistical randomness and decidability, "Can I see a pattern in it?", and compressibility, "Can I make a smaller representation of it?" Something is statistically random if one cannot answer questions about it more accurately than by guessing. There are various sorts of statistical randomness, depending on what analytical tools are available. If you allow any Turing machine, you get algorithmic complexity concepts like Kolmogorov-Chaitin randomness. There is randomness which is incompressibility to a particular coder. There is randomness with respect to statistical measures; one can take the difference of an observed posterior distribution and a probabilistically calculated posterior distribution and apply standard statistical tests. How far is this distribution from expected, and is the likelihood for this difference? >I prefer random bit >sequences. Or perhaps I should say - bit sequences with no apparent >structure. Your clarification makes a difference. Randomness as lack of structure can be quantified by looking for conditional probabilities. E.g. P( x_0 = 1 | x_3 = 0 ) is the conditional probability that x_0 is 1 in the case that x_3 = 0. If this probability is not 1/2 exactly, then you have a correlation. Conditional probabilities in general get hairy fast, even when the predicates, i.e. the events, are limited to particular bits equalling zero or one, and the standard propositional connectives "and", "or", & "not". There are questions of independence whose resolution requires a detour into predicate logic. E.g. P( x = 0 | x = 1 ) = 0, clearly, because the two events are logically dependent. One of the ways of measuring these probabilities in the aggregate is with entropy measures. The entropy of a probability distribution is the expected value of the negative logarithm. If you can determine an entropy which is not maximal, then you've found a correlation, even if exploiting the correlation might not be obvious. This maximality must be exact, and not approximate. For example, in the example I gave with 16 zero bits prepended to a random message, the bit entropy deviates ever so slightly from maximal, but that indicates a correlation. The problem is that that entropy is a probabilistic entropy, not a statistical one. Had we measured the same entropy value, it would not have allowed us to conclude anything, if all we had was the entropy. We could have also just looked at the first few bits. Anyway, since entropies are expected values on probabilities, one can also have conditional entropies as well. The criteria for non-recognizability is that all conditional entropies are maximal. This, again, is a probabilistic notion, since the calculation of all conditional entropies for a particular message is an exponential time algorithm. Eric From craig at hebron.connected.com Sun Mar 6 18:52:28 1994 From: craig at hebron.connected.com (ANGeL) Date: Sun, 6 Mar 94 18:52:28 PST Subject: New mailing list? In-Reply-To: <199403050033.QAA23619@net.bio.net> Message-ID: I agree completely. I've been kind of lurking since I joined the list, mainly because I don't know much technical cryptography, and have been here mainly to learn more. This list traffic is starting to get to be just too much. (65 new messages today) /|NGeL of |>eATH 21 keystrokes south of Seattle (on a clear day) Finger me for my PGP 2.3a public key. Have you terrorized a Republican today? From craig at hebron.connected.com Sun Mar 6 18:53:23 1994 From: craig at hebron.connected.com (ANGeL) Date: Sun, 6 Mar 94 18:53:23 PST Subject: Meeting in Seattle? In-Reply-To: Message-ID: > > Is anyone in Seattle setting up a link for the meeting? If so, please let > > me know. > > I'm in Seattle but my impression is that there aren't many people on the > list here. > You could be wrong about that. Maybe we could set up a link. /|NGeL of |>eATH 21 keystrokes south of Seattle (on a clear day) Finger me for my PGP 2.3a public key. Have you terrorized a Republican today? From craig at hebron.connected.com Sun Mar 6 18:54:38 1994 From: craig at hebron.connected.com (ANGeL) Date: Sun, 6 Mar 94 18:54:38 PST Subject: basic RSA info Message-ID: I'm working on writing some simple code fora class, and I was wondering if anyone had some information on the RSA algorithm that I could look at. I don't know a lot about cryptology at the moment, so I'd need it in layman's terms. /|NGeL of |>eATH 21 keystrokes south of Seattle (on a clear day) Finger me for my PGP 2.3a public key. Have you terrorized a Republican today? From jdwilson at gold.chem.hawaii.edu Sun Mar 6 18:58:38 1994 From: jdwilson at gold.chem.hawaii.edu (Jim Wilson VA) Date: Sun, 6 Mar 94 18:58:38 PST Subject: spooks In-Reply-To: <9403031629.AA09423@pilot.njin.net> Message-ID: <9403070258.AA08019@gold.chem.hawaii.edu> > > If there are any spooks on this list aren't they required by law to say that > they are if somoeon asked if anyone on on th list was employed by CIA, DOD, FBI > or NSA? > Reuben Halper > If undercover police can tell you that they are not a cop and then arrest you without your being able to claim entrapment, why should the three letter agency agents be compelled to do so by law? (Not an arguement in favor of this but a question as to what law would require this.) -Jim From hfinney at shell.portal.com Sun Mar 6 19:40:47 1994 From: hfinney at shell.portal.com (Hal) Date: Sun, 6 Mar 94 19:40:47 PST Subject: Where'd pgptools go? Message-ID: <199403070341.TAA01514@jobe.shell.portal.com> I notice on csn.org:/mpj there is now pgptl10d.zip, PGP Tools version 1.0d. However, 1.0d is not the whole PGP Tools program. It is just an addendum which implements Diffie-Hellman. Apparently pgptl10c.zip is still needed to give you the whole of PGP Tools. Does anyone know of an FTP site which still has pgptl10c available? Thanks - Hal From rcain at netcom.com Sun Mar 6 20:44:14 1994 From: rcain at netcom.com (Robert Cain) Date: Sun, 6 Mar 94 20:44:14 PST Subject: Screen and secure sessions Message-ID: <199403070444.UAA19567@mail.netcom.com> What follows is part of a dialog I am having with netcom support right now about the use of the Screen hyper-shell. I've been using it between home and work and it is awesome if you have never seen it. The man pages for it in ascii are ~rcain/pub/screen.man if you are on netcom and want to check out what it can do. There is someplace here I could put it for anon ftp if somebody could tell me the name of that drirectory from a netcom shell. The dialog starts as a discussion of the problem I have with the two or three minute inactivity timeout on the San Jose modems and is mostly about the low impact I see it having on resource usage. If you know all about Screen or aren't really interested in a bunch of justification, go forward about 100 lines to get to the part that discusses crypto. Peace, Bob > Netcom Support sez: > > > > Robert Cain writes: > > > > > > [some stuff deleted] > > > > > > First the short duration of your modem timeout pushes the envelope of > > > the ridiculous. I'm not sure what it is but when a brief conversation > > > or call of nature causes it to disappear *IT IS TOO DAMNED SHORT*. > > > > I'm sorry you have a problem with our policy, but we have no > > intent to change it in the future. We'll take your suggestions > > under consideration, but as I said we have no plans to modify > > it at this time. > > You certainly sound intransigent. What would the implications of > doubling it be for example? You could at least try it for a while > and see if it has the effect of increasing the load on modem banks > signifigantly. What is the currently programmed inactivity interval > anyway? I lost it again in the middle of this damned note because > I got a phone call. Damn I hate it when that happens. At lest > this time there was a "vi -r" message in my mailbox after logging > on. > > > > > > > I have a solution to this that I am using on our sun network at > > > work. It is a package called "screen" that has wonderful features > > > like multiple windows (all stacked one atop the other) that are > > > easy to create and switch between if you want several contexts > > > available at once. The most exciting feature is that if I wish > > > to or if my line goes down, I can reconnect to it at the next > > > login and pick up as if nothing had happened. This would be a > > > wonderful feature at netcom too. I know that your no nohup > > > hacks prevent us from having processes that persist when we log > > > off (OR ARE FORCED OFF) but if you changed that specifically > > > for the screen processes and it's descendants to instead reduce > > > them to the lowest possible priority until a reconnect then all > > > this hassle would go away and netcom could offer a very neat > > > feature. IBM mainframes have had disconnect/reconnect forever and > > > I've never understood the lack of it on Unix. Here it is! It > > > is a very friendly and powerful capability. Users would love it > > > and the cost to netcom would be entries in process tables and > > > swap space for the processes. You seem to have more than enough > > > of those kinds of resources now. Please consider it. > > > > The use of "Screen" is not supported on Netcom because of its drain on > > system resources. It violates our policy against running detached > > backround processes. This is also a policy we have no plans to modify > > at this time. > > Hmmm, I'm not sure you read me. What I am suggesting would not > violate the intent of your policy WRT detached background processes. > Let me try and persuade you. > > If whatever you use to kill processes upon detachment, logout or forced > by timeout, could instead merely lower their priority to the minimum > then, as I said, they would not load the system's cycle capacity, > merely occupy some process specific tables and some swap space. I am > pretty sure that in one of the netcom newsgroups (to which I am posting > a copy of this) we hassled this out and it was determined what the cost > in real memory was for a process's tables that was totally swapped > out. It was truly insignifigant in proportion to the size of real > memory that is on the systems. There is little drain on system > resources if you do this unless the number of processes becomes > absurdly high. > > Yes, there is a cost for swap space. Is it possible to set up your > unix to use more than one swap area? If so then it could be arranged > that a user's pages were swapped into storage he is paying for > (possibly after he/she had exceeded some limit in the system swap > area) and then this would become a revenue generator for netcom rather > than a drain on resources. If that is not a thing you know how to do > then you could simply establish a daemon that checks the number of > processes (or the total size) and warns the user when he is in > violation of the limit. That limit should be based on a determination > of the real cost in process tables and swap space rather than just set > arbitrarily. I don't see how my request does much more than offer > serial line users enjoy!!>. They can and do stay logged in indefinitely and in effect have > various processes running all the time without concern about an > inactivity timeout. > > Arguing against having a bunch of virtual windows makes no sense > because you can effect that if you know emacs reasonably well anyway. > Screen is just an easier way that doesn't require one to learn emacs. > As a hypershell, Screen has *many* powerful features for power users. > For fairly naive users only a fairly few keystrokes need be > remembered to use it's most useful features. In combination with > the menu program you offer it would be very powerful across a slow > line. > > One of Screen's features is a rather elaborate filtering mechanism whereby > all incoming keystrokes and outgoing screen data can be filtered by > user programs. I would like to use this to add encryption for my phone > line. It would be straightforward to encrypt my outgoing and incoming > data here at my PC that is acting as a terminal since I think my terminal > emulator has similar filter hooks so the same programs that I used on > the netcom end or my work end would function on this end as well if I > explicitly wrote them to be that way. Given that, I would make Screen > effectively my login shell, have it negotiate (via the filters) a > secure link with my terminal emulator here at home and then go through > another password process before invoking my startup shell. Viola I no > longer have to worry about someone grabbing my real password nor can I > be snooped or spoofed between my system and a system at netcom. This > has *HUGE* advantages to users and I will use a cypher (IDEA) in a mode > that is *very* fast so that the system load that would be introduced > by the crypdec filters would not be all that great. I have all the > necessasary C libraries of long integer math routines and hard crypto > functions as well as the theoretical knowledge of crypto needed to code > what's left to write such a filter. > > Hell, Screen's capability would *greatly* enhance Netcom's account > attractiveness and good crypto could be used as a big selling point in > attracting commercial accounts where you make substantial profit per > account. In fact when I get this to work I wouldn't be surprised if > users demand it. :-) > > I have the man pages for Screen in my ~rcain/pub directory if anybody > at netcom wants to check out Screen's capabilities. I could also > make them temorarily available for incoming anon ftp if requested. > Now, while all this is true in theory, in all honesty I am too deeply involved in other things (like a day job) to actually do the implementation I speak of but I *do* have all the tools if anybody else wants to take a shot at writing the filters. Since screen runs across rlogin just fine, if this were done I could rlogin to any other machine on the net and have a secure session across the net. I think it could also be made to be secure across "talk" or "irc" sessions and even email between machines. It could also be used as the front end to any text based telnet port too. So if you want to be able to dial in securely at least and communicate with a system that is secure, and across systems that are secure badly enough to put the time into it (or pay me enough to quit my day job :-), here is a chance to maybe make some history. I think this is the right way to get a start on global network security. Screen offers such a rich environment for single windowed connections already that it is a natural starting point given that it's author has thought ahead to the kinds of filters we need. It also could care less what shell you run and it is transparent to the applications running below it (from the experience I have had to date) It is a work of art to begin with IMHO and with this crypdec capability there would hardly be a reason not to use it since if you don't know it and don't want to learn, you won't know Screen is there until you invoke it's commands with the ctrl-A key (which can be changed to anything else as an escape if you use applications that are fond of ctrl-A.) Peace and hoping, Bob -- Bob Cain rcain at netcom.com 408-354-8021 "I used to be different. But now I'm the same." --------------PGP 1.0 or 2.0 public key available on request.------------------ -- From markh at wimsey.bc.ca Sun Mar 6 21:29:15 1994 From: markh at wimsey.bc.ca (Mark C. Henderson) Date: Sun, 6 Mar 94 21:29:15 PST Subject: Where'd pgptools go? Message-ID: > I notice on csn.org:/mpj there is now pgptl10d.zip, PGP Tools version > 1.0d. However, 1.0d is not the whole PGP Tools program. It is just an > addendum which implements Diffie-Hellman. Apparently pgptl10c.zip is still > needed to give you the whole of PGP Tools. Does anyone know of an FTP > site which still has pgptl10c available? Thanks - > > Hal on wimsey.bc.ca: /pub/crypto/software/dist/US_or_Canada_only_XXXXXXXX/RSA/PGP/PGPTOOLS: total 328 -rw------- 1 markh user 0 Feb 23 11:11 DO_NOT_EXPORT -r--r--r-- 1 markh user 21076 Feb 23 11:10 mgmny10e.zip -r--r--r-- 1 markh user 143871 Feb 23 11:10 pgptl10c.zip cd into /pub/crypto/software and read the README file for the current value of XXXXXXXX -- Mark Henderson markh at wimsey.bc.ca (personal account) RIPEM MD5OfPublicKey: F1F5F0C3984CBEAF3889ADAFA2437433 ViaCrypt PGP Key Fingerprint: 21 F6 AF 2B 6A 8A 0B E1 A1 2A 2A 06 4A D5 92 46 cryptography archive maintainer -- anon ftp -- wimsey.bc.ca:/pub/crypto From markh at wimsey.bc.ca Sun Mar 6 21:53:09 1994 From: markh at wimsey.bc.ca (Mark C. Henderson) Date: Sun, 6 Mar 94 21:53:09 PST Subject: Screen and secure sessions Message-ID: On a related note. There's a program called term which is popular in the Linux community. from the latest term version announcement: (For those that don't know: Term is a user level slip replacement. It ISN'T slip, but achieves much of the functionality. Error correction, compression, and multiplexing across a serial line are all supported, enabling X windows across a serial line and such.. } Now, term already allows compression across the line (yes it has features for dealing with lines which can't handle certain characters). You can have several sessions going, file transfers and even X clients. I believe that it wouldn't take too much work to add DH key exchange and IDEA or triple DES? (GNU GMP might be a good place to look for the multiple precision math, but there are lots of choices). Am I going to do it? Well, not this week. If anyone has time to work on this, the term source is available by anon ftp from ftp tartarus.uwa.edu.au in /pub/oreillym/term. Last time I looked term would run on many popular Unix (or Unix-like) systems. Mark -- Mark Henderson markh at wimsey.bc.ca (personal account) RIPEM MD5OfPublicKey: F1F5F0C3984CBEAF3889ADAFA2437433 ViaCrypt PGP Key Fingerprint: 21 F6 AF 2B 6A 8A 0B E1 A1 2A 2A 06 4A D5 92 46 cryptography archive maintainer -- anon ftp -- wimsey.bc.ca:/pub/crypto From sergey at delbruck.pharm.sunysb.edu Mon Mar 7 00:41:15 1994 From: sergey at delbruck.pharm.sunysb.edu (Sergey Goldgaber) Date: Mon, 7 Mar 94 00:41:15 PST Subject: Standard for SteGAnography In-Reply-To: <9403050859.AA13734@toad.com> Message-ID: On Sat, 5 Mar 1994, Eli Brandt wrote: > My point is, invulnerability to *what attack*? An attacker may know > the algorithm, or not; may have known plaintext; may be able to > choose plaintext; may be able to read a channel, or to garble it, or > to change it; may have limited or unlimited space and time; might be > able to factor in polynomial time -- there are a lot of parameters > here. And it makes no sense at all to say, "Well, let's just > consider the strongest possible attack." > > Eli My original response was concerning an algorithm "good enough to withstand an opponent who has full documentation of your algorithms and methods lots of funds, and everything except your keys." That opponent may, concievably, be the NSA or another person/organisation with access to similar resources. The consensus seems to point to such an opponent as being one who could mount the "strongest possible attack". It may not be practical to consider such a general danger when designing particular encryption schemes; but, it is likewise impractical to make sweeping generalizations concerning a given scheme's invulnerability. Sergey From ebrandt at jarthur.cs.hmc.edu Mon Mar 7 01:03:20 1994 From: ebrandt at jarthur.cs.hmc.edu (Eli Brandt) Date: Mon, 7 Mar 94 01:03:20 PST Subject: Standard for SteGAnography In-Reply-To: Message-ID: <9403070903.AA24454@toad.com> > My original response was concerning an algorithm "good enough to withstand > an opponent who has full documentation of your algorithms and methods lots > of funds, and everything except your keys." That's what they have; what can they *do*? As I've been trying to get across, that is not a full specification of capabilities. Enough. Eli ebrandt at hmc.edu From Lyle_Seaman at transarc.com Mon Mar 7 07:33:45 1994 From: Lyle_Seaman at transarc.com (Lyle_Seaman at transarc.com) Date: Mon, 7 Mar 94 07:33:45 PST Subject: Corporations In-Reply-To: Message-ID: Sandy Sandfort writes: > On Tue, 1 Mar 1994, David L Womack wrote: > > then, is offshore. My understanding is that > > corporate earnings are subject to the host > > country's tax, NOT U.S. tax. And, tax waivers > > are not difficult to get from these other countries. > > Yup. And a variation of this is what's called double > invoicing. It's one of the things that made Hongkong > great. Now, knowing all this, every reader of this list should be **deeply** suspicious of any official "trade deficit" figures. Lyle From mpjohnso at nyx10.cs.du.edu Mon Mar 7 08:18:35 1994 From: mpjohnso at nyx10.cs.du.edu (Michael Johnson) Date: Mon, 7 Mar 94 08:18:35 PST Subject: Where'd pgptools go? In-Reply-To: <1994Mar7.035353.15506@mnemosyne.cs.du.edu> Message-ID: <9403071616.AA17095@nyx10.cs.du.edu> Hal writes: >I notice on csn.org:/mpj there is now pgptl10d.zip, PGP Tools version >1.0d. However, 1.0d is not the whole PGP Tools program. It is just an >addendum which implements Diffie-Hellman. Apparently pgptl10c.zip is still >needed to give you the whole of PGP Tools. Does anyone know of an FTP >site which still has pgptl10c available? Thanks - OOPS -- I must have prematurely deleted something. I still have it on the Colorado Catacombs BBS (303-938-9654), and I'll put it back up on csn.org within a day or so. I thought I merged the new with the old to create the latest .zip file.... ___________________________________________________________ |\ /| | | | | \/ |o| | Michael Paul Johnson Colorado Catacombs BBS 303-938-9654 | | | | / _ | mpj at csn.org ftp csn.org \mpj\README.MPJ for access info.| | |||/ /_\ | aka mpjohnso at nyx.cs.du.edu mikej at exabyte.com | | |||\ ( | m.p.johnson at ieee.org CIS 71331,2332 VPGP key by finger | | ||| \ \_/ |___________________________________________________________| From hughes at ah.com Mon Mar 7 08:42:22 1994 From: hughes at ah.com (Eric Hughes) Date: Mon, 7 Mar 94 08:42:22 PST Subject: Truly Stealthy PGP (algorithm) In-Reply-To: <199403061922.LAA26901@jobe.shell.portal.com> Message-ID: <9403071634.AA10351@ah.com> >If I understand Eric's general idea, we would keep trying session keys >under a set of rules which would lead to the desired statistical >distribution of the encrypted key. I actually said nothing about how to get the particular distribution of keys specified, since that was another issue. I was more concerned with just getting the one result across. >Here is an algorithm which would work. It does work, and I'll put down a proof sketch below. Notation alert: >Let L be the next power of 256 above the modulus n. Let t be the integer >part of L/n, so that L = n*t + s with s in [0,n). Call the PGP IDEA session >key SK, and the encrypted version of that m = SK^e. Now do these steps: >1) Pick a random SK in [0,n). This random number in [0,n) is the wrong distribution, but that's OK, since we'll be throwing some numbers away. >2) RSA-encrypt it to form m = SK^e mod n. RSA encryption is a bijection (an 1-1 map). If it were not, there would be two or more possible decryptions for a given ciphertext. Therefore RSA encryption is a permutation, and a permutation of probabilities preserves expected values of functions of the probability, such as entropy. Since we assume the entropy of the SK is maximal (probabilistic entropy), therefore the entropy of the m's is maximal. So the m's have a flat distribution. (As always, the above statements about bijection hold only if SK is multiple of one of the divisors of the modulus. But then if you do find one of those, you've also factored the modulus and thus broken the key. We assume this doesn't happen, since if it does little of this matters anyway.) >3) Choose a random k in [0,t]. >4) Calculate the "stegged" encrypted key as M = m + k*n. Hal now observes that M is uniformly distributed. This is correct, and happens because m is in [0,n) and we are adding a multiple of n to m. This means that each M has a unique represenative as some pair . Since both m and k are independently random (max entropy, flat distribution), so is M. >5) if M is not in [0,L) (i.e. if M >= L) then go back to step 1. >The idea is that once we get M uniform in [0,(t+1)*n) we can make it >uniform in [0,L) simply by rejecting those candidates which were too high. What we have here is a Markov chain. We have accepting states and rejecting/retrying states. Since the probabilities in the chain are independent of each other and are also time-invariant, the distribution of final probabilities is the same as the distribution of normalized accepting probabilities. In simple terms, you can just retry until you get it right. Since the probabilities are all the same before, they will all be the same after, only larger to account for the fact that some possibilities didn't work. [re: rejection and retry] >This will only happen if k=t and m>=s. That's right, and that means that for m < s you have valid k in [0,t+1) and for m >= s only for [0,t). If you go back an look at the entropy expression, you'll see exactly this difference in relative probability for the two parts of [0,n). >Now, it seems to me that the worst case for rejection is when n=L-1, in >which case t=1, s=1, and almost one-half of all initial SK choices will >be rejected. Right, but the worst case for rejection is not the same as the worst case for entropy loss, which occurs at n=L/2+1 and s=t-1, i.e. at the other end of the spectrum entirely. >Following Eric's reasoning, this would be an effective loss >of one bit of key length, from say 1024 to 1023, which is tolerable. Actually not. The loss of effective key length happens based on the posterior distribution of the session keys, not on the number of rejections that happen in the process. >Using this algorithm with the current Stealth PGP would produce a >"truly stealthy" version which I think would be indistinguishable from >random bytes without access to the receiver's private key. Indeed. Observe, though, that as far as deployment went, this would require modification to PGP itself for it to be anything like widespread. Eric From norm at netcom.com Mon Mar 7 08:47:55 1994 From: norm at netcom.com (Norman Hardy) Date: Mon, 7 Mar 94 08:47:55 PST Subject: Format of PGP ciphered message Message-ID: <199403071648.IAA23312@mail.netcom.com> Thanks! From conrad at merl.com Mon Mar 7 08:54:32 1994 From: conrad at merl.com (Eric Conrad) Date: Mon, 7 Mar 94 08:54:32 PST Subject: RSAREF help requested Message-ID: <9403071654.AA20575@merl.com> I need to use RSAREF to do 3 simple things: generate a keypair, encrypt a file, and decrypt a file. This is so that I can safely encrypt online information with the public key, while keeping the private key offline. PGP does what I want, but I can't use it due to legal reasons. Ripem does too much (all the mail and key management stuff), and is too complex for my purposes. I've begun writing the C code using the RSAREF libraries to do what I want, but I'd rather not recreate the wheel. Has anyone written the simple tools I described? ...Eric From cowen at glia.biostr.washington.edu Mon Mar 7 10:44:15 1994 From: cowen at glia.biostr.washington.edu (cowen at glia.biostr.washington.edu) Date: Mon, 7 Mar 94 10:44:15 PST Subject: No Subject Message-ID: <9403071854.AA05340@glia.biostr.washington.edu> about joe6pack>>> though joe 6-pack might not vote, and likely won't even understand about the crypto of it all. he would understand the police listening in on his conversations with jill 6-pack. and not like it to well. i do think though that the ge that the general public should know, what the congress is getting itself into other topics before congress get aired why not this one. making it simple for simple minds, might be beyond some folks though there has been talk here about how to go about the process. which on the surface looks so easy. but the general populace of the US of A has a bit of problem with concepts at times. big bangs and lots of noise and death, that sure does catch attention, for about 20 seconds. the computer folks are going to be fighting with the gov't types til the end of time and the joe 6-packs are going to be stuck in the middle. but we need them more than we need to alienate them. they do pay taxes, some of them do vote, and some of them are the rich and famous we want to get our point across to. not every rich man knows about computers. we as a group or as individuals should at least try to let the joe 6-packs that we know in on the secrets the gov't and the FBI and the NSA are trying to hide from him. maybe that is the point of a so called free nation. and sure we might not run this country, but public outcry most times turns heads in congress. charles the monster maker From jeremy at crl.com Mon Mar 7 11:04:00 1994 From: jeremy at crl.com (Jeremy Cooper) Date: Mon, 7 Mar 94 11:04:00 PST Subject: basic RSA info In-Reply-To: Message-ID: On Sun, 6 Mar 1994, ANGeL wrote: > I'm working on writing some simple code fora class, and I was wondering > if anyone had some information on the RSA algorithm that I could look > at. I don't know a lot about cryptology at the moment, so I'd need it in > layman's terms. > > /|NGeL of |>eATH > 21 keystrokes south of Seattle (on a clear day) > Finger me for my PGP 2.3a public key. > Have you terrorized a Republican today? > >From what I know, RSA thrives on the following formula. Every key in an RSA public key system has two parts. One part is a very very large number, and the other is a relatively small number. We will call the large number 'l' and the small number 's'. These two numbers are calculated beforehand (shown in a later equation). To encrypt plaintext (which is what we call the stuff to be encrypted) with an RSA key, you use the following formula: [ E stands for encrypted text. P stands for plaintext ] P^s E = ------ l In this example. Let's use the letter 'A' for our plaintext. Let's say we have a key with l = 85 and s = 3. (don't worry about where those numbers came from, we'll make them later). If we use the ASCII standard, the character 'A' has a value of 65. So if we plug in all the values we get: 65^3 E = -------- = 2307 and a remainder of 92 119 To decrypt, you use the private key. In this case, the private key is l = 119 s = 32 and the new equation is: 92^32 D = ------- = 6937619471... and a remainder of 65 119 So we have encrypted with one key, and decrypted with the other. Now as to how we arrived at these two key parts, I will explain. When you make an RSA key, you generate three numbers. Two of them are prime and one is just odd. We'll name these P Q and E respectively. The first part of the key is P * Q, the second part of the key is E. In the above example, P = 17 Q = 7 E = 3. So we end up with the key {119, 3}. This is the public key. To make the private key, we keep the first part the same, but we change E. The new E now equals: (P - 1)(Q - 1) E = -------------- Eo (Eo means the old value of E) So the value of E for the private key is (16 * 6) / 3 = 32. Now that I think about it. I am sure to have messed something up. Please send a flame back attacking what I foobared. Thank you. _ . _ ___ _ . _ ===-|)/\\/|V|/\/\ (_)/_\|_|\_/(_)/_\|_| Stop by for an excursion into the-=== ===-|)||| | |\/\/ mud.crl.com 8888 (_) Virtual Bay Area! -=== From warlord at MIT.EDU Mon Mar 7 11:48:05 1994 From: warlord at MIT.EDU (Derek Atkins) Date: Mon, 7 Mar 94 11:48:05 PST Subject: Format of PGP ciphered message In-Reply-To: <199403070034.QAA26077@mail.netcom.com> Message-ID: <9403071947.AA24030@toxicwaste.media.mit.edu> Currently, the only documenation is in the file PGFORMAT.TXT that is in the PGP distribution. -derek From mech at eff.org Mon Mar 7 12:12:47 1994 From: mech at eff.org (Stanton McCandlish) Date: Mon, 7 Mar 94 12:12:47 PST Subject: A useful quote/stat to spread Message-ID: <199403072012.PAA00645@eff.org> "In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two-thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it." - Philip Elmer-Dewitt, "Who Should Keep the Keys", _TIME_, Mar. 4 1994 From mg5n+ at andrew.cmu.edu Mon Mar 7 12:37:19 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Mon, 7 Mar 94 12:37:19 PST Subject: basic RSA info In-Reply-To: Message-ID: Jeremy Cooper wrote: > Now that I think about it. I am sure to have messed something up. > Please send a flame back attacking what I foobared. Thank you. okay... overall pretty good tho. > When you make an RSA key, you generate three numbers. > Two of them are prime and one is just odd. The encryption exponent must not contain any common factors with (p-1)(q-1). This means that it is always odd, but that's not necessarily the only factor that you need to check. > P^s > E = ------ > l The remainder, not the quotient. Usually written as E = P^s mod l From eman at netcom.com Mon Mar 7 12:54:58 1994 From: eman at netcom.com (Emanuel Barros) Date: Mon, 7 Mar 94 12:54:58 PST Subject: clipper & corp. espionage Message-ID: <199403072055.MAA04077@mail.netcom.com> Hi, I'm new to the list. I was wondering if the clipper chip passed. what's stopping corrupt government people from selling access to the encryption to the highest bidders to spy on competitors communications. just curious. Emanuel(eman at netcom.com) From fhalper at pilot.njin.net Mon Mar 7 13:16:44 1994 From: fhalper at pilot.njin.net (Frederic Halper) Date: Mon, 7 Mar 94 13:16:44 PST Subject: Public Key Message-ID: <9403072116.AA15856@pilot.njin.net> Kent, would you send me your key again. I have to talk to you. Reuben Halper -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQCPAi16KosAAAEEAMUwRni4a9+GbuAhHDLcBWK60hCJUYxhr2hYokpELAhx0ejp 2fq61Tu9Hjn051CN8Xy5nu6sv2ODfG/t59l4DJSb5pirQaII3zaX0rMX0ydwGDoW YakL4ow1lNY+d/k14KpIuUW404+fNuNhIGSkdVLQIfbOgh0preK7/P44AKvdABEB AAG0JlJldWJlbiBIYWxwZXIgPGZoYWxwZXJAcGlsb3Qubmppbi5uZXQ+iQCVAgUQ LXorceK7/P44AKvdAQEUxwQAoffTibRlwE5tNQVGvrulh1OQgXNhTRec9vUaUwPy U64FIZ+KnmdfYgiJYXtcItA90EB9MDexazKeqJzMOPShVNOfyiwy2yUlnQs425f8 DxBvM//zuvj6s4/mXDTPUZtG9PP0HVaEGTJY15JdfRqtj/w+HHnsHlgCnj0NnIhX TW8= =D9UX -----END PGP PUBLIC KEY BLOCK----- From gnu Mon Mar 7 13:23:50 1994 From: gnu (gnu) Date: Mon, 7 Mar 94 13:23:50 PST Subject: Welcome to the foia-keys announcement list; request update Message-ID: <9403072122.AA06378@toad.com> You expressed interest in my FOIA request for the Clipper key database. Here's a minor update on the request. We send all our FOIA requests by registered mail, return reciept requested. According to the Post Office, NIST received our request on 28 Feb 94. This means that their response is due ten or twenty business days after that day. Based on experience, we believe that an actual timely response is unlikely; the government doesn't feel an obligation to follow the law. However, I encourage you to call or write NIST's FOIA officer (Karl Bell, Deputy Director of Administration, NIST, Building 101, Gaithersburg, Maryland) to indicate your interest in both the content and the timeliness of his response. John Gilmore gnu at toad.com From dmandl at lehman.com Mon Mar 7 13:23:50 1994 From: dmandl at lehman.com (David Mandl) Date: Mon, 7 Mar 94 13:23:50 PST Subject: clipper & corp. espionage Message-ID: <9403072119.AA21144@disvnm2.lehman.com> > Hi, I'm new to the list. I was wondering > if the clipper chip passed. what's stopping > corrupt government people from selling access > to the encryption to the highest bidders to spy > on competitors communications. > just curious. > > Emanuel(eman at netcom.com) Nothing. --Dave. From patrickb at panix.com Mon Mar 7 14:17:22 1994 From: patrickb at panix.com (Patrick Breitenbach) Date: Mon, 7 Mar 94 14:17:22 PST Subject: Mondex card Message-ID: <199403072217.AA18242@panix2.panix.com> Recent articles on Mondex: The Economist, 1/29/94 NewsBytes, "The Cashless Card: UK Banks Introduce Mondex", 1/6/94 >From what I can tell: Mondex appears to be a rather agressive attempt at an open system for digital cash. The three major players are NatWest, Midland Bank and British Telecom. Unlike many other efforts, they are using a completely anonymous method rather than auditing all transactions. The cards are smart (IC chips embedded on a credit card sized card. I am not sure of the security specifics. They will be capable of representing 5 core currencies and many more temporarily. The "Mondex" name has been reserved in 30 countries and market research has been done in Japan, the US, Germany and France as well as the UK. They are piloting in the British town of Swindon (not sure of the size). Other interesting moves along these lines: Electronic Payment Services/MAC Network are piloting prepay Lufthansa/German Post/2 German Banks looking at multi-app card patrick breitenbach patrickb at panix.com From warlord at MIT.EDU Mon Mar 7 14:25:40 1994 From: warlord at MIT.EDU (Derek Atkins) Date: Mon, 7 Mar 94 14:25:40 PST Subject: Screen and secure sessions In-Reply-To: Message-ID: <9403072222.AA25374@toxicwaste.media.mit.edu> I've actually spoken to the author of Term regarding adding an encryption layer to the protocol. I took a look and was trying to find an easy way to hook it in. The most difficult part would be the key exchange... The possibilities I came up with were using DH to get either a DES, 3-DES, or IDEA key, or using Charon to get a kerberos session key (DES). I think DH is a better solution... In my copious amounts of free time.... ;-) If you are interested in this project, let me know.. I'm more than happy to discuss what I've found so far, and discuss design, etc. -derek From lefty at apple.com Mon Mar 7 15:13:24 1994 From: lefty at apple.com (Lefty) Date: Mon, 7 Mar 94 15:13:24 PST Subject: clipper & corp. espionage Message-ID: <9403072312.AA00708@internal.apple.com> >Hi, I'm new to the list. I was wondering >if the clipper chip passed. what's stopping >corrupt government people from selling access >to the encryption to the highest bidders to spy >on competitors communications. > >just curious. Um, the goodwill and general trustworthiness of our elected officials and their duly-designated appointees? Just a guess, mind you. -- Lefty (lefty at apple.com) C:.M:.C:., D:.O:.D:. From ub075 at freenet.victoria.bc.ca Mon Mar 7 17:42:26 1994 From: ub075 at freenet.victoria.bc.ca (Ryan A. Perkins) Date: Mon, 7 Mar 94 17:42:26 PST Subject: New Remailer Message-ID: <9403080147.AA04763@freenet.victoria.bc.ca> With a fair number of remailers down lately, I thought that I'd announce my remailer. It's been running for a long time now, and I still haven't got PGP to work. The remailer is rperkins at nyx.cs.du.edu. No logs are kept by me of this service. Aburt, the operator does not know about the remailer, but if he asks me to remove it, I will. -- Ryan Perkins - 1:340/13 | I feel that suicide jumpers see a glimpse of ub075 at freenet.victoria.bc.ca | sanity as they throw themselves from the ledge. Ask for PGP 2.3 public key | That's why they scream all the way down. 8C5357 : 9F FF BA 93 54 D5 18 78 4B 1E DA GC E3 4E From ub075 at freenet.victoria.bc.ca Mon Mar 7 17:56:17 1994 From: ub075 at freenet.victoria.bc.ca (Ryan A. Perkins) Date: Mon, 7 Mar 94 17:56:17 PST Subject: New Remailer Message-ID: <9403080201.AA06163@freenet.victoria.bc.ca> >With a fair number of remailers down lately, I thought that I'd announce >my remailer. It's been running for a long time now, and I still haven't >got PGP to work. The remailer is rperkins at nyx.cs.du.edu. Couple other things. Mail to rperkins at nyx10.cs.du.edu and rperkins at nox.cs.du.edu will work too. It supports the "##" paste header, and will strip all lines after a "." on the first column of a line. -- Ryan Perkins - 1:340/13 | I feel that suicide jumpers see a glimpse of ub075 at freenet.victoria.bc.ca | sanity as they throw themselves from the ledge. Ask for PGP 2.3 public key | That's why they scream all the way down. 8C5357 : 9F FF BA 93 54 D5 18 78 4B 1E DA GC E3 4E From mech at eff.org Mon Mar 7 18:14:58 1994 From: mech at eff.org (Stanton McCandlish) Date: Mon, 7 Mar 94 18:14:58 PST Subject: Leahy to hold hearings on Clipper Chip! Message-ID: <199403080212.VAA10363@eff.org> Forwarded message: From: jberman at eff.org Jerry Berman Date: Mon, 7 Mar 1994 19:09:22 -0500 Subject: Leahy to hold hearings on Clipper Chip! Dear Friends on the Electronic Frontier: I have some good news to share with you. Senator Leahy just sent me a letter indicating that he *will* be scheduling hearings on the Administration's Clipper Chip proposal. I would like to thank all of you who sent us messages to forward to him urging hearings. I'm sure that stack of messages we printed out made a significant impact on the Senator -- the stack was over seven inches tall! (We look forward to the day when no trees will have to be sacrificed in the furtherance of democracy!) And if you haven't written a message to Rep. Cantwell yet about her proposed amendment to the Export Control Act, please do so and forward it to cantwell at eff.org. This is an address we set up to enable us to collect messages in support of her bill. We have been printing out messages and delivering them each week -- so far we've received over 4500 letters of support. For more information on the Cantwell bill, send a message to cantwell-info at eff.org. Thanks again. We'll let you know as soon as the Clipper hearing gets scheduled. Sincerely, Jerry Berman EFF Executive Director -.-.-.-.-.-.-. forward from Sen. Leahy -.-.-.-.-.-.-.-.-.-. United States Senate Committee on the Judiciary Washington, DC 20510 March 1, 1994 Mr. Jerry Berman Executive Director Electronic Frontier Foundation 1001 G Street, Suite 950 East Washington, DC 20001 Dear Jerry, Thank you for forwarding to me the many thoughtful and informative messages you received over the Internet regarding the Administration's recent approval of an escrowed encryption standard, known as the Clipper Chip. Many of the messages urge Congress to hold hearings to review the Administration's Clipper Chip standard. In fact, I intend to hold a hearing before the Judiciary Subcommittee on Technology and the Law, which I chair, to consider the important issues raised by the Clipper Chip. I will let you know when a date for the hearing is scheduled. Thank you again. Sincerely, /s/ PATRICK J. LEAHY United States Senator PJL/jud -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. JOIN EFF!! ========== EFF's work as a civil liberties organization in Washington has been very successful, but the realization of our goals of freedom and privacy online can only come with the active and vocal participation of the entire online community. Now that you have personally experienced both the threat of the loss of your privacy and the power having won the first battle, won't you take that next step and become a member of EFF? By joining EFF, you will help us to expand our reach to educate and involve an even greater number of people in the shaping of these critical issues. Your tax-deductible donation will tie you into the EFF information network and support our public policy and legal work. As a member, you will be guaranteed timely the timely information and mechanism you need to respond on these issues. Our voices in unity *do* make a difference. -------- 8< ------- cut here ------- 8< -------- MEMBERSHIP IN THE ELECTRONIC FRONTIER FOUNDATION ================================================ Print out in monospaced (non-proportional) font and mail to: Membership Coordinator Electronic Frontier Foundation 1001 G Street, NW, Suite 950 East, Washington, DC 20001 SIGN ME UP! ----------- I wish to become a member of the Electronic Frontier Foundation. I enclose: ___ Regular membership -- $40 ___ Student membership -- $20 * Special Contribution I wish to make an additional tax-deductible donation in the amount of $__________ to further support the activities of EFF and to broaden participation in the organization. PAYMENT METHOD: --------------- ___ Enclosed is a check or money order payable to the Electronic Frontier Foundation. ___ Please charge my: ___ MasterCard ___ Visa ___ American Express Card Number: _____________________________________________ Expiration Date: _________________________________________ Signature: _______________________________________________ NOTE: We do not recommend sending credit card information via email! YOUR CONTACT INFORMATION: ------------------------- Name: __________________________________________________________ Organization: __________________________________________________ Address: _______________________________________________________ _______________________________________________________ Phone: _____________________ FAX: _____________________ BBS: _____________________ BBS Name: ____________________ E-mail addresses: ______________________________________________ ______________________________________________ PREFERRED CONTACT ___ Electronic: Please contact me via the Internet address listed above. I would like to receive the following at that address: ___ EFFector Online - EFF's biweekly electronic newsletter (back issues available from ftp.eff.org, pub/EFF/Newsletters/EFFector). ___ Online Bulletins - bulletins on key developments affecting online communications. NOTE: Traffic may be high. You may wish to browse these publications in the Usenet newsgroup comp.org.eff.news (also available in FidoNet, as EFF-NEWS). ___ Paper: Please contact EFF through the US Mail at the street address listed above. NOTE: Paper documents available upon request. "Networks & Policy" Newsletter automatically sent via US Mail. PRIVACY POLICY -------------- EFF occasionally shares our mailing list with other organizations promoting similar goals. However, we respect an individual's right to privacy and will not distribute your name without explicit permission. ___ I grant permission for the EFF to distribute my name and contact information to organizations sharing similar goals. [This form from eff.org 3/7/94 Cantwell--please leave this line on the form!] The Electronic Frontier Foundation is a nonprofit, 501(c)(3) organization supported by contributions from individual members, corporations and private foundations. Donations are tax-deductible. From jef at ee.lbl.gov Mon Mar 7 19:38:20 1994 From: jef at ee.lbl.gov (Jef Poskanzer) Date: Mon, 7 Mar 94 19:38:20 PST Subject: random number generator for pnmstega - comments? Message-ID: <9403080338.AA24987@hot.ee.lbl.gov> I combined the "minimal" generator from PGP with another one. The key length is still 31 bits. The way I figure it, that's enough to deter exhaustive search by most entities, but it's not so much that there will be export problems. As long as I put strong cautions in the doc about relying on this RNG as your primary cipher, and as long as it seems likely to be secure against cryptanalysis, I think this is a good compromise. The minimal generator by itself is known to be insecure. By using it as input to a shift register, I think enough complexity is added that it becomes an unknown again. Comments are welcome. --- Jef /* libpbm6.c - pbm utility library part 6 ** ** Simple, portable, reasonably robust random number generator. ** ** Copyright (C) 1994 by Jef Poskanzer. ** ** Permission to use, copy, modify, and distribute this software and its ** documentation for any purpose and without fee is hereby granted, provided ** that the above copyright notice appear in all copies and that both that ** copyright notice and this permission notice appear in supporting ** documentation. This software is provided "as is" without express or ** implied warranty. */ #include "pbm.h" /* This is a combination of a linear congruential generator and a feedback ** shift register. Values from the LCG are used to keep a circular buffer ** filled; results are produced by xoring three values from the table. ** The modulus of the LCG must be a power of two for this to produce ** equidistributed results. This LCG actually uses a modulus that's ** a power of two minus one, but that's close enough. ** ** DO NOT MODIFY, IMPROVE, EXPAND, ENHANCE, OR IN ANY WAY CHANGE this ** generator. It is used for cryptographic storage of data - if the ** sequence is changed, the data will become unrecoverable. ** ** The linear congruential generator is: ** Minimal Standard Pseudo-Random Number Generator ** Author: Fuat C. Baran, Columbia University, 1988 ** Based on code in "Random Number Generators: Good Ones are Hard to Find", ** by Stephen K. Park and Keith W. Miller in Communications of the ACM, ** 31, 10 (Oct. 1988) pp. 1192-1201. ** ** The feedback shift register is similar to the one described in "Algorithms", ** Robert Sedgewick, 1983, page 38. */ #define A 16807L #define M 2147483647L /* Mersenne prime 2^31 -1 */ #define Q 127773L /* M div A (M / A) */ #define R 2836L /* M mod A (M % A) */ static long value = 1; #define TABLESIZE 55 #define TAP1 0 #define TAP2 23 #define TAP3 (TABLESIZE-1) static long table[TABLESIZE]; static int offset; static long lcg() { long hi, lo; hi = value / Q; lo = value % Q; value = A * lo - R * hi; if ( value <= 0 ) value += M; return value; } void pm_srandom( seed ) long seed; { if ( seed == 0 ) /* Zero doesn't work in this RNG anyway, so we use it as a flag. */ value = time( 0 ) ^ getpid(); else value = seed; for ( offset = 0; offset < TABLESIZE; ++offset ) table[offset] = lcg(); } long pm_random() { offset = ( offset + 1 ) % TABLESIZE; table[offset] = lcg(); return table[offset] ^ /* TAP1 is zero, optimize */ table[( offset + TAP2 ) % TABLESIZE] ^ table[( offset + TAP3 ) % TABLESIZE]; } From catalyst-remailer at netcom.com Tue Mar 8 08:44:51 1994 From: catalyst-remailer at netcom.com (catalyst-remailer at netcom.com) Date: Tue, 8 Mar 94 08:44:51 PST Subject: Decoding the Electronic Future Message-ID: <199403081645.IAA06909@mail.netcom.com> US News & World Report Copyright, 1994, U.S. News & World Report All rights reserved. U.S.NEWS & WORLD REPORT, MARCH 14, 1994 DECODING THE ELECTRONIC FUTURE By Vic Sussman WILL ENCRYPTION SECURE OR DENY PRIVACY RIGHTS? Would you hand over a spare set of house keys to your local police to help them fight crime, trusting that they would never enter your home without good reason? According to opponents of the so-called Clipper chip, a powerful new telecommunications encoding device, that is an apt metaphor for what the White House, the FBI and the supersecret National Security Agency are asking of a gullible American public. Clipper backers insist the innovation will not only help in an increasingly desperate fight against crime but actually give Americans more privacy than ever. The Clipper controversy--which has sparked frenzied debate and angry protests in recent weeks--swirls around a small sliver of silicon that can be built into telephones. Ordinary phones can be tapped with anything from cheap scanners to quaint-tech alligator clips. But Clipper phones use encryption technology to scramble voice, fax, electronic mail and other data transmissions into digital gibberish. Only other Clipper phones can unscramble the information, which makes the Clipper an untappable system. Well, almost. A phone that can't be tapped is every cop's nightmare, because anyone from drug traffickers to terrorists would be able to scheme and plot with impunity. So under a plan hatched by the NSA and backed by the White House, government agents would be able to unscramble Clipper's secret code by using two mathematical keys. To guard against abuse, the keys would be held by two government agencies. Authorities would first have to get a warrant--standard wiretap procedure--before obtaining the decoders. Key escrow, as it's called, may sound good on paper, but critics maintain it will be both invasive and ineffectual. In addition, Democratic Sen. Patrick Leahy of Vermont maintains that Clipper is a ``misstep in export policy.'' U.S. companies would have a tough time selling compromised telecommunications products overseas and consequently would have to manufacture both domestic and foreign versions, an expensive proposition. IBM, Apple, Microsoft and the Software Publishers Association, among many others, oppose Clipper. Leahy's Technology and the Law Subcommittee is planning March hearings on these issues. HISTORY'S SHADOW. Critics are also doubtful that Clipper's decoding keys will be sufficient to deter government recklessness, pointing to past abuses by the FBI, NSA and CIA. But Georgetown University computer scientist Dorothy Denning contends that much more stringent controls against illegal eavesdropping exist today. ``The greater danger,'' she insists, ``is losing the ability to wiretap, giving organized crime and terrorism the advantage.'' Law enforcement authorities also say they are looking for no more authority than they already have--to make lawful requests to have the telecommunications industry cooperate in crime prevention. But Marc Rotenberg, Washington director of Computer Professionals for Social Responsibility, a public-interest group that has collected more than 50,000 signatures on an anti-Clipper petition, doesn't buy that argument. In fact, he says, the government has admitted the system could be easily breached by the NSA, which wouldn't need a warrant if it made its demand under the rubric of national security. Many valid concerns about Clipper, says Rotenberg, ``are similarly dismissed with the claim of national security, a dangerous way to design our civilian communications infrastructure.'' The Clipper chip has been proposed as a voluntary standard. But once the Internal Revenue Service, the Pentagon and other agencies order tens of thousands of Clipper phones, it will be impossible to do government business using any other equipment. Indeed, the biggest fear raised by Clipper is that it is the digital camel's nose under the electronic tent. Another White House proposal, for instance, would require that all future telecommunications systems--everything from phones to online services--be ``wiretap friendly,'' says Jerry Berman, executive director of the Electronic Frontier Foundation. Even the most vociferous Clipper opponents concede a legitimate need for electronic surveillance, but many would like to see Congress rather than agencies like the NSA determine the proper balance of government needs and individual rights. Cliff Stoll, whose book THE CUCKOO'S EGG focused attention on computer espionage, thinks the Clipper controversy is overblown by both sides. In fact, he contends, the typical telephone or computer user doesn't need any encryption more powerful than pig Latin. Erhaps-pay. From sdw at meaddata.com Tue Mar 8 09:10:46 1994 From: sdw at meaddata.com (Stephen Williams) Date: Tue, 8 Mar 94 09:10:46 PST Subject: stego In-Reply-To: <940305234908_73211.3713_DHI59-2@CompuServe.COM> Message-ID: <9403081711.AA24995@jungle.meaddata.com> It just came to mind about a funny stego (usage) thread in an in-company newsgroup at a company I was contracting at. They were 'downsizing' and planning on laying off a fairly large percentage of people. There was a discussion obliquely related in one of the local talk groups. The seemingly related messages all furthered the point in a diplomatic way, except the first letter of each line spelled a more direct statement. (JERKS, SUCKS, ...) It was pretty funny, especially when people responded to the ostensible message and then later found out about the stego one. One person started it and those that noticed followed up likewise. sdw -- Stephen D. Williams Local Internet Gateway Co.; SDW Systems 513 496-5223APager LIG dev./sales Internet: sdw at lig.net sdw at meaddata.com OO R&D Source Dist. By Horse: 2464 Rosina Dr., Miamisburg, OH 45342-6430 Comm. Consulting ICBM: 39 34N 85 15W I love it when a plan comes together From shipley at merde.dis.org Tue Mar 8 10:04:51 1994 From: shipley at merde.dis.org (Evil Pete) Date: Tue, 8 Mar 94 10:04:51 PST Subject: (forward message on privacy) Message-ID: <9403081804.AA24829@merde.dis.org> ------- Forwarded Message Date: Sun, 6 Mar 1994 21:04:02 -0800 From: lile at netcom.com (Lile Elam) Message-Id: <199403070504.VAA22694 at mail.netcom.com> To: kw-comm at remarque.berkeley.edu Subject: chips... Today I ran into a situation that made me completely nausiated and feel like my privacy had been completely invaded... It involves a chip which is implanted in animals and used for identification... Prehaps I over-reacted but my gut tells me that I haven't. That's what makes me still feel nausiated when I think about it. So I thought I would see what you thought about it. My housemate and I are looking to get some cats for our house. We decided to go to the Peninsula Humane Society (in the south San Francisco area) and see about adopting them from there as this is where lost or stray animals are kept and if unclaimed after a month, are put to sleep. I fell in-love with a beautiful black simi-long hair cat named "Hawk", a five year old male with yellow eyes. We got along really well (I am a cat person by nature) and I decided to adopt him. He is very gental and loving which seems so strange for such a big male cat. I kept calling him "she" :). So, I went to the front desk and spoke with the Animal Coordinator/Advisor. Everything was going great and they were impressed that my dad's a veterinarian. Said it sounded like we could provide Hawk with a wonderful home. Then the woman said, "All we have to do is implant a microchip in the animal and you'll be set". Well, I turned pale and said, "What's this chip and why is it needed?" I was told that it was used to identify the animal in case it became lost. A identifaction number is stored on this microchip and can be used to find the pet's owner and home. Well, I said I didn't want a chip in this cat and that it was a violation of privacy. There was a woman standing next to me, awaiting getting her pet, and she turned to me and said, "I don't see what the problem is?" I responded, "Well, if their doing this to animals, how soon will it be before they implant the same sort of thing in us?" She said, "Oh, I hadn't thought about it like that." and became quiet. I told the attendant that I was strongly opposed to this chip implant and couldn't accept the cat with it. So she is going to check with her boss tomorrow to see if I can get the cat without the chip. She said she understood my concerns about big brother and that a few people have had similar reactions. I'll send you an update tomorrow and let you know if I can get the cat without the chip... I was really upset about this. My housemate asked me why and I said, "It's too close. Don't forget that we are animals too! We can't really talk til we're 2 so I could see this I.D. microchip being used in human babies. And what about people who might suffer from memory loss? A reason to use a chip in adults would be to "identify" you if you forgot who you were or if you were not using your born identity. The possiblities are endless!" And with the NII coming, well it's as bad as the clipper chip, if not worse! So, am I totally over-reacting? I really do feel like this chip is wrong and don't know what to do... Below is the brocure contents about the C.H.I.P. program. How do you feel about it? thanks, - -lile ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lile Elam | "Remember... No matter where you go, there you are." lile at netcom.com | Un*x Admin / Artist | Buckaroo Banzai ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C. H. I. P. Campaign to Help Identify Pets Peninsula Humane Society 12 Airport Blvd. San Mateo, CA 94401 Seventy percent of missing animals never come home because they have no permanent I.D. or their owners don't know how to find them. Here at PHS, only 3% of the stray cats and 57% of the stray dogs brought to the shelter ever return to their family. Because you care about your animals, your home is as secure as possible. But thefts, accidents and natural desasters such as fires and earthquakes, do happen - even to caring and responsible pet owners like you. Despite your best efforts, your animal could get loose and become lost. That's why your newly adopted friend has become part of our new Campaign to Help Identify Pets (CHIP). PHS is working in conjunction with InfoPet, maker of computerized identification microchips, to expand our lost and found services. With the new microchip implant program, we hope to reunite as many animals as possible with their families. High-Tech Identification: - ------------------------- When you adopted your animal, a tiny microchip implant, no larger than a grain of rice, was implanted under his/her skin. There was no additional cost for this implant, and the procedure was easy and required no anesthetic. It was as simple as a routine vaccination. The microchip contains a unique I.D. number which can be activated by a special hand-held scanning device (much like bar codes in grocery stores). In the future, if your animal becomes lost and is brought to the shelter or a local participating veterinary hospital, his/her unique I.D. number will be read by the scanner. This number can then be traced through a computer database that stores vital information such as your name, address and phone number. If your animal was adopted from PHS, his/her records will be kept on a computer at our shelter, and InfoPet's national registry, will list the PHS Adoptee" and our phone number next to his I.D. number. When other, non-PHS aniamls are "chipped" by a private veterinarian, their records go on file directly with th InfoPet national computer registry. InfoPet National Registry: - -------------------------- Although your adopted pet is automatically registered with PHS, for an additional fee of $30 you can also register your animal directly with the InfoPet national registry. (To do so, use the InfoPet form that was given to you at the time you brought your animal home from the shelter.) The InfoPet database is accessable 24 hours a day and can be reached by calling toll free 1-800-INFOPET. If you choose to register directly with InfoPet, they will replace the PHS Adoptee listing with your animal's record which includes your name, address, phone number, and other facts that will be helpful to someone trying to reunite you with your pet. Regardless of where you are registered, however, keep in mind that the registries are only helpful if they are kept up to date with current information. If you move or change your phone number, be sure to notify PHS and/or InfoPet right away. Licensing and Microchip Identification: - --------------------------------------- The microchip does not replace the need to license your animal with the San Mateo County Animal Services Division. By law, every dog and cat must be licensed and have proof of rabies vaccination. In addition, under the current ordinance in the unincorporated areas of San Mateo County, dogs and cats must be spayed or neutered unless the owner possesses a breeding or unaltered animal permit. You have 60 days to licenses your animals(s). A current tag should be worn by both dogs and cats at all times. However, the microchip implant is an acceptable alternative to waaring a tag for cats only. Dogs are encuraged to have the implant in the event their collar is broken or lost. Commonly Asked Questions: - ------------------------- Q) How is the chip implanted? Is it painful? A) Done with a specialized sterile needle containing the chip, the injection is simple and requires no anesthetic. The procedure takes seconds and causes no more discomfort than a routine injection. Q) Is the chip large? Will it bulge under the skin? A) The microchip is 11 mm in length or the size of a grain of rice. Once implanted it is invisible from the skin's surface. Q) Will the chip move around in my animals body? A) No, it is injected under the skin. The body naturally forms a wall around the chip and keeps it secure. Q) Will the implant mictrochip cause any medical problems? A) No, it is made of bio-comptible glass which is naturally accepted by the tissue of your animal. Q) Why should I microchip my animal when he already has a license or never goes outside? A) For extra protection. Animals can accidently escape the confines of your home or lose their collars in a variety of situations. Q) Can the I.D. number be changed? A) No, it is unalterable and provides permanent identification. Q) Can the information be accidently erased or deactivated in any way? A) The microchips have a lifespan of approximately 20 years. To date, no chip has gone inactive. Q) Can other companion animals get the microchip implant? A) Right now PHS will only implant adopted cats and dogs. Howerver, microchips have been implanted in other animals. Contact InfoPet or your local veterinarian for more information. Q) Are all microchips the same? Can the InfoPet chip be read by other company scanners? A) No, unfortunately there are several different companies currently producing microchips and scanning devices. At this time, most of the chips can only be read by the scanning devices produced by the sanme ccompany. It is our hope that a common scanning device will be available in the future. In the meantime, PHS will check each animal brought to the shelter first for the InfoPet chip (the chip being used throughout San Mateo County) and then for the other chip that is being used in a few other communities in the bay area. Q) What happens if I move out of the area? A) Notify InfoNet's computer bank (Tool-Free: 1-800-INFOPET), then contact your new veterinarian, aniaml shelter or humane society in your new location to find out if they have the InfoPet microchip scanning program available. For More Information, Please call: (415) 340-7022, ext.320 ------- End of Forwarded Message From rcain at netcom.com Tue Mar 8 10:08:38 1994 From: rcain at netcom.com (Robert Cain) Date: Tue, 8 Mar 94 10:08:38 PST Subject: Wrong permissions for screen.man Message-ID: <199403081809.KAA05938@netcom9.netcom.com> -- Bob Cain rcain at netcom.com 408-354-8021 "I used to be different. But now I'm the same." --------------PGP 1.0 or 2.0 public key available on request.------------------ From sergey at delbruck.pharm.sunysb.edu Tue Mar 8 10:58:36 1994 From: sergey at delbruck.pharm.sunysb.edu (Sergey Goldgaber) Date: Tue, 8 Mar 94 10:58:36 PST Subject: more steganography talk In-Reply-To: <199403051330.AA13596@access2.digex.net> Message-ID: On Sat, 5 Mar 1994, Peter Wayner wrote: > Sorry to be so distracted. This is a very interesting topic for > me, but I've been bogged down with more prosaic topics. I think > the Mimic FUnction implementation that I did is a very general > standard for steganography. On the current level, it just deals > with text, but you can make it do bits by just using the alphabet > of just plain {0,1}. > > Here are the important points about it: > > 1) If the grammars are made complex enough, they can simulate > anything you can compute with a computer. I.e. You can encode > data in a Turing-complete way. I find it fascinating how complimentary cryptography and AI are! > is done by translating RSA encryption into > a context-free grammar. I wonder if anyone has actually gone to all the trouble of developing some kind of binary CFG? It should be easier to design than an equally effective human-language Turing-complete CFG. > that there could be many practical "incomplete" attacks > that worked in general cases. What kinds of "incomplete" attacks could possibly work against Mimic functions implementing Turing-complete CFGs? > 4) It is still unclear how to generate RSA-level strength > with Mimic Functions. Can't you simply use a Turing-complete CFG, and meta-CFG? Do such things exist on computer media? > Understanding what makes grammars hard and easy to grok is a > hard question. Why not just ask an AI? :) > 6) The process is slightly difficult to implement, but I've > got two running versions (as I've mentioned before on the > list). One in C and the other in Pascal. Do you know if anyone has ported either of those over to anything other than the Mac? Good to have you join the discussion, BTW... Sergey From cort at ecn.purdue.edu Tue Mar 8 11:11:10 1994 From: cort at ecn.purdue.edu (Cortland D. Starrett) Date: Tue, 8 Mar 94 11:11:10 PST Subject: keeping secrets from myself Message-ID: Here is a practical problem that has me frustrated.... Situation: Assume that I am the treasurer at my local church. This implies responsibility to record each Sunday's offering (the money collected) in the church financial books. An account is maintained for each member of the church. Money received from members each Sunday is credited to their respective accounts. Each January, a report is prepared for each parishioner showing a summary of the charitable contributions for the previous year. This information is used for tax purposes. Currently, the treasurer knows EVERYTHING about EVERYONE (regarding charitable giving). As a privacy advocate, this is indeed uncomfortable (for giver and treasurer). Problem: I want to know as little as possible about church member giving. Give and Take: It will be difficult/impossible to prevent the treasurer from seeing each weeks' checks. However, a privacy improvement may be achieved if the running totals are kept hidden. How can I provide a comprehensive year-end statement to each parishioner while maintaining maximum privacy? Does cryptography have anything to offer to this situation? What procedures/protocols could be implemented? What privacy enhancements could be included with the church accounting software? Cort. From hughes at ah.com Tue Mar 8 11:28:31 1994 From: hughes at ah.com (Eric Hughes) Date: Tue, 8 Mar 94 11:28:31 PST Subject: ANNOUNCE: Cypherpunks meeting March 12 Message-ID: <9403081911.AA13066@ah.com> ANNOUNCEMENT ============ Monthly Cypherpunks Meeting Saturday, 12 March 1994 MBONE: 12:00 noon PST - 3:00 p.m. PST Bay Area physical: 12:00 noon PST - 6:00 p.m. Cygnus Support Offices, Mt. View, CA Theme for March: Politics, Strategy, and Action The time has come to go on the offensive. We have labored too long in reaction to the government attempts to restrict cryptography. This meeting will be a planning meeting for real-life strategies in the political arena. -- The Free Communication Amendment to the Constitution of the United States Section 1. Free, private, and secure speech being necessary to the stability of a free state, the right of the people to possess, to import into or to export from the United States and all territory subject to its jurisdiction, to manufacture, to buy, to sell, and to use communications and cryptography devices shall not be denied, abridged, or infringed by the United States or by any of the states. Section 2. Anonymous listening and anonymous speech being necessary for the free expression of unpopular beliefs and opinions, the right not to identify oneself and the right to use a pseudonym to identify oneself, to listen and to speak, for both public and private speech, shall not be denied, abridged, or infringed by the United States or by any of the states. -- Anti-Clipper legislation -- Senate hearings on Clipper -- HR 3627, removal on civilian encryption equipment from the ITAR -- Positioning of cryptography in the marketplace of ideas Jim Warren, the miracle man behind the passage of California AB 1624, which mandated public access to legislation data which were already computerized, will be speaking at Mt. View. About the MBONE. We have considered a real-time audio conference via the MBONE. Interest has been expressed from the following places: Boston, Washington, D.C., Boulder, Austin, New York, Cleveland, San Diego, Seattle, Finland, Germany Unfortunately, it is unclear whether Cygnus Support, where the SF Bay Area cypherpunks meet, will be ready for the MBONE by this Saturday. Nevertheless, with enough other sites participating, there will be an MBONE conference at this time regardless of whether the Mt. View site is able to participate. There will have to be some spontaneous symmetry breaking for running that channel should Mt. View be unable to join. It may be possible for Mt. View to participate by making a direct connection to an MBONE site and have an audio mix happen there. This has yet to be tested. Specific announcements with addresses and directions for each of the MBONE sites will follow. This one should be good. 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 karn at qualcomm.com Tue Mar 8 11:36:49 1994 From: karn at qualcomm.com (Phil Karn) Date: Tue, 8 Mar 94 11:36:49 PST Subject: Response to CJ request for Applied Cryptography Message-ID: <199403081935.LAA04889@servo.qualcomm.com> United States Department of State Bureau of Politico-Military Affairs Office of Defense Trade Controls Washington, DC 20522-0602 MAR 2 1994 [stamped] In reply refer to ODTC Case CJ 038-94 YOUR LETTER DATED: February 12, 1994 REQUEST FOR COMMODITY JURISDICTION DETERMINATION FOR: "Applied Cryptography" Cryptographic Book by Bruce Schneier Your commodity jurisdiction (CJ) request was referred to the Departments of Commerce and Defense for their review and recommendations. As a result, the Department of State has determined that the referenced commodity is not subject to the licensing jurisdiction of the Department of State since the item is in the public domain. However, this ruling covers only the subject book and not the two source code disks that the book references and that are available from the author. Should you require further assistance on this matter, please contact Maj. Gary Oncale at (703) 875-5655. Sincerely, [signed] William B. Robinson Director Office of Defense Trade Controls Phil Karn 7431 Teasdale Avenue San Diego, CA 92122 From cme at sw.stratus.com Tue Mar 8 14:19:49 1994 From: cme at sw.stratus.com (Carl Ellison) Date: Tue, 8 Mar 94 14:19:49 PST Subject: Standard for Stenography? Message-ID: <199403082219.RAA10365@galt.sw.stratus.com> Bill Stewart wrote: >Carl Ellison's "tran" program takes an interesting approach for data >scrambling - it takes a simple checksum of the first N bytes of the data, >which is order-invariant (I think it was a byte-wise XOR?) >and uses it as a random-number seed for scrambling blocks of data; >it's easy to reverse because the checksum is the same after scrambling. The old tran used the sum of the bytes. The new tran uses the histogram of the bytes (of the first block -- 8KB or the whole message). This carries more information. That seeds a PRNG (currently subtract-with-borrow, but it could be made stronger -- e.g., with DES or IDEA encrypting the output before use) which then drives a pairwise byte swap over each 8KB block of the stream. This is a self-inverse. I can send code to anyone interested. It's also on ripem.msu.edu. - Carl From jim at bilbo.suite.com Tue Mar 8 16:02:00 1994 From: jim at bilbo.suite.com (Jim Miller) Date: Tue, 8 Mar 94 16:02:00 PST Subject: INFOPET Message-ID: <9403082356.AA04709@bilbo.suite.com> I just called 1-800-INFOPET and sure enough, INFOPET is for real. The guy who answered the phone was quite proud of their efforts, claiming to have over a million people (yes, he used the word "people") in their database (people == pet owners, veterinarians, animal shelters). Jim_Miller at suite.com From phantom at u.washington.edu Tue Mar 8 16:11:43 1994 From: phantom at u.washington.edu (Matt Thomlinson) Date: Tue, 8 Mar 94 16:11:43 PST Subject: intricacies of cpunks link-up? Message-ID: I've mailed eric on this, but no response yet and our time is running out. If seattle was to get a group meeting set up for saturday and we wanted to link up with the bay area meeting, what _exactly_ should I be asking for? MBONE connections? (is this video, btw, or just an audio link?) I was hoping to get this set up, but.. we'll see. answers appreciated. mt Matt Thomlinson Say no to the Wiretap Chip! University of Washington, Seattle, Washington. Internet: phantom at u.washington.edu phone: (206) 548-9804 PGP 2.2 key available via email or finger phantom at hardy.u.washington.edu From mech at eff.org Tue Mar 8 17:08:07 1994 From: mech at eff.org (Stanton McCandlish) Date: Tue, 8 Mar 94 17:08:07 PST Subject: EFF's Barlow v. Denning on Clipper - AOL March 10, 9PM EST LIVE Message-ID: <199403090107.UAA08118@eff.org> CLIPPER CHIP DEBATE Thursday, March 10, 9 pm eastern Dorothy Denning, cryptologist and chair of the computer science department at Georgetown University, will debate John Perry Barlow, cognitive dissident and co-founder of the Electronic Frontier Foundation, in the TIME Odeon on America Online this Thursday at 9 pm. Philip Elmer-DeWitt, TIME senior writer, and Robert Pondiscio, TIME public affairs director, will moderate. The floor will be open to questions from the audience. You need an America Online account to participate. Call America Online at 703-448-8700 to subscribe. Philip Elmer-DeWitt ped at panix.com ped at well.com TIME Magazine philiped at aol.com Read TIME on America Online, where we get paid to take abuse. -- Stanton McCandlish * mech at eff.org * Electronic Frontier Found. OnlineActivist F O R M O R E I N F O, E - M A I L T O: I N F O @ E F F . O R G O P E N P L A T F O R M O N L I N E R I G H T S V I R T U A L C U L T U R E C R Y P T O From wcs at anchor.ho.att.com Tue Mar 8 17:58:26 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Tue, 8 Mar 94 17:58:26 PST Subject: Church Accounting - keeping secrets from myself Message-ID: <9403090051.AA26529@anchor.ho.att.com> Cortland Starrett (cort at ecn.purdue.edu) asked a question about how a church treasurer could keep track of running totals of donations from parishioners without being blatantly reminded of what they are except at tax time. Secrecy doesn't have to be real high, since the treasurer does see each check as it comes in, and could keep track separately. One technique that could be adapted is to add a large random number to each person's initial balance, and then subtract that at the end of the year to get the total for tax purposes. Pick a bunch of numbers, say between 100K and 900K save them in a file, and give everyone a copy of their number. Also add up the total of the random numbers so that you can get the whole spreadsheet to balance. Then everybody's running total can be visible without it conveying any useful information except to people who want to track changes from week to week, since you can't tell if $654321 means you gave $1 (with a random number of 654320) or $554321. The total number shouldn't cause overflow problems for 32-bit integers unless you've got more than 3-4000 people. For convenience, you may want to derive the random number from a hash of the person's name, in case they or use lose records. Not letting the left hand know what the right hand is doing..... Bill P.S. Of course, this is just another example of how taxation negatively affects people's lives - if you weren't paying income taxes, you wouldn't need to keep track of deductions to charities, and you could just pay in cash. From jpp at markv.com Tue Mar 8 18:12:43 1994 From: jpp at markv.com (jpp at markv.com) Date: Tue, 8 Mar 94 18:12:43 PST Subject: INFOPET In-Reply-To: <9403082356.AA04709@bilbo.suite.com> Message-ID: <9403081811.aa29443@hermix.markv.com> If you had a 'breed' pet (like a dog, or cat with papers, or an exotic bird) and paid in the thousands of dollars, you would view this device as a way to discorage thieves. Think of it as the Lojack of pets. But I certainly don't advocate puting them in people... And *I* don't have one... I think... The size of a grain of rice... Hmmm... I wonder what exactly is in those 'inventory controll' poles beside the doors at shops... I supose I'd better stay away from the free vacinaiton programs offered by the government in the future... I wonder if the CIA/FBI/NSA had these things back in the swine flu days... Man that shot hurt... Oh dear this is truely an evil line of thought... j(...1984 is fiction, 1984 is fiction, 1984 is fiction...)' -- O I am Jay Prime Positive jpp at markv.com 1250 bit fingerprint B06229 = B8 95 E0 AF 9A A2 CD A5 89 C9 F0 FE B4 3A 2C 3F 524 bit fingerprint 2A915D = 8A 7C B9 F2 D5 46 4D ED 66 23 F1 71 DE FF 51 48 Public keys via `finger jpp at markv.com', or via email to pgp-public-keys at io.com Your feedback is welcome directly or via my symbol JPP on hex at sea.east.sun.com Resist the Clipper Chip, write "I oppose Clipper" to Clipper.petition at cpsr.org From nobody at jarthur.cs.hmc.edu Tue Mar 8 18:17:36 1994 From: nobody at jarthur.cs.hmc.edu (nobody at jarthur.cs.hmc.edu) Date: Tue, 8 Mar 94 18:17:36 PST Subject: Decoding the Electronic Future Message-ID: <9403090217.AA28982@toad.com> US News & World Report Copyright, 1994, U.S. News & World Report All rights reserved. U.S.NEWS & WORLD REPORT, MARCH 14, 1994 DECODING THE ELECTRONIC FUTURE By Vic Sussman WILL ENCRYPTION SECURE OR DENY PRIVACY RIGHTS? Would you hand over a spare set of house keys to your local police to help them fight crime, trusting that they would never enter your home without good reason? According to opponents of the so-called Clipper chip, a powerful new telecommunications encoding device, that is an apt metaphor for what the White House, the FBI and the supersecret National Security Agency are asking of a gullible American public. Clipper backers insist the innovation will not only help in an increasingly desperate fight against crime but actually give Americans more privacy than ever. The Clipper controversy--which has sparked frenzied debate and angry protests in recent weeks--swirls around a small sliver of silicon that can be built into telephones. Ordinary phones can be tapped with anything from cheap scanners to quaint-tech alligator clips. But Clipper phones use encryption technology to scramble voice, fax, electronic mail and other data transmissions into digital gibberish. Only other Clipper phones can unscramble the information, which makes the Clipper an untappable system. Well, almost. A phone that can't be tapped is every cop's nightmare, because anyone from drug traffickers to terrorists would be able to scheme and plot with impunity. So under a plan hatched by the NSA and backed by the White House, government agents would be able to unscramble Clipper's secret code by using two mathematical keys. To guard against abuse, the keys would be held by two government agencies. Authorities would first have to get a warrant--standard wiretap procedure--before obtaining the decoders. Key escrow, as it's called, may sound good on paper, but critics maintain it will be both invasive and ineffectual. In addition, Democratic Sen. Patrick Leahy of Vermont maintains that Clipper is a ``misstep in export policy.'' U.S. companies would have a tough time selling compromised telecommunications products overseas and consequently would have to manufacture both domestic and foreign versions, an expensive proposition. IBM, Apple, Microsoft and the Software Publishers Association, among many others, oppose Clipper. Leahy's Technology and the Law Subcommittee is planning March hearings on these issues. HISTORY'S SHADOW. Critics are also doubtful that Clipper's decoding keys will be sufficient to deter government recklessness, pointing to past abuses by the FBI, NSA and CIA. But Georgetown University computer scientist Dorothy Denning contends that much more stringent controls against illegal eavesdropping exist today. ``The greater danger,'' she insists, ``is losing the ability to wiretap, giving organized crime and terrorism the advantage.'' Law enforcement authorities also say they are looking for no more authority than they already have--to make lawful requests to have the telecommunications industry cooperate in crime prevention. But Marc Rotenberg, Washington director of Computer Professionals for Social Responsibility, a public-interest group that has collected more than 50,000 signatures on an anti-Clipper petition, doesn't buy that argument. In fact, he says, the government has admitted the system could be easily breached by the NSA, which wouldn't need a warrant if it made its demand under the rubric of national security. Many valid concerns about Clipper, says Rotenberg, ``are similarly dismissed with the claim of national security, a dangerous way to design our civilian communications infrastructure.'' The Clipper chip has been proposed as a voluntary standard. But once the Internal Revenue Service, the Pentagon and other agencies order tens of thousands of Clipper phones, it will be impossible to do government business using any other equipment. Indeed, the biggest fear raised by Clipper is that it is the digital camel's nose under the electronic tent. Another White House proposal, for instance, would require that all future telecommunications systems--everything from phones to online services--be ``wiretap friendly,'' says Jerry Berman, executive director of the Electronic Frontier Foundation. Even the most vociferous Clipper opponents concede a legitimate need for electronic surveillance, but many would like to see Congress rather than agencies like the NSA determine the proper balance of government needs and individual rights. Cliff Stoll, whose book THE CUCKOO'S EGG focused attention on computer espionage, thinks the Clipper controversy is overblown by both sides. In fact, he contends, the typical telephone or computer user doesn't need any encryption more powerful than pig Latin. Erhaps-pay. From tomj Tue Mar 8 18:49:15 1994 From: tomj (Tom Jennings) Date: Tue, 8 Mar 1994 18:49:15 -0800 (PST) Subject: (forward message on privacy) (fwd) In-Reply-To: <9403090221.AA01084@wps.com> from "Flesh" at Mar 8, 94 06:21:38 pm Message-ID: <9403090249.AA01170@wps.com> > Today I ran into a situation that made me completely nausiated and feel like > my privacy had been completely invaded... It involves a chip which is > implanted in animals and used for identification... Humans are worth more money, and genotyping will do the same thing, for cheaper, and with little outcry. Implanted chips means at least a doctors visit for every humasn in the country; genotyping only happens like fingerprinting, when you get a drivers license or soemthing. I think the underlying concern is OK, but misplaced worrying about kitty-cats. Cats can certainly be violated, but usually aren't aware of it ahead of time, and there's not much they can do about it :-) Consider also they generally *kill* cats they can't return. A chip implant under these circumstances seems not a problem. -- Tom Jennings -- tomj at wps.com -- World Power Systems -- San Francisco, Calif. From jim at bilbo.suite.com Tue Mar 8 19:11:08 1994 From: jim at bilbo.suite.com (Jim Miller) Date: Tue, 8 Mar 94 19:11:08 PST Subject: Decoding the Electronic Future Message-ID: <9403090304.AA07956@bilbo.suite.com> [..] Law enforcement authorities also say they are looking for no more authority than they already have--. [..] Perhaps LE is not asking for more *authority*, but they sure are asking for more *capability*. If LE had the capability to do everything they're currently authorized to do (wiretaps, search and seizure, follow people, undercover officers, sting operations, obtain financial records, public security cameras, etc), on a nationwide scale, the US would truly be a police state. It's not so much the amount of "authority" that is keeping the US from being a police state, it is LE's level of capability. Don't give LE more capabilities. One person's opinion, Jim_Miller at suite.com From huntting at glarp.com Tue Mar 8 19:17:38 1994 From: huntting at glarp.com (Brad Huntting) Date: Tue, 8 Mar 94 19:17:38 PST Subject: chips... In-Reply-To: <9403081804.AA24829@merde.dis.org> Message-ID: <199403090314.UAA00343@misc.glarp.com> > Today I ran into a situation that made me completely nausiated and > feel like my privacy had been completely invaded... It involves a > chip which is implanted in animals and used for identification... > [....] "Well, if their doing this to animals, how soon will it be > before they implant the same sort of thing in us?" She said, "Oh, > I hadn't thought about it like that."... Several years ago (like mid or early 80's if I recall), there was just such a program for marking children. It involved implanting a "microchip" on the surface of a tooth. I remember hearing about it on one of those "human interest" stories that air on slow news days when the local TV stations burn through the local police blotter and government press releases too quickly and need to kill time with unimportant trivia lest they mention something that actually matters. Unfortunatly, that's all I remember about it. brad From MIKEINGLE at delphi.com Tue Mar 8 19:46:31 1994 From: MIKEINGLE at delphi.com (Mike Ingle) Date: Tue, 8 Mar 94 19:46:31 PST Subject: ViaCrypt PGP for Unix, CompuServe Message-ID: <01H9QU2FITZO9N47FQ@delphi.com> I got a flyer from ViaCrypt today about these: ViaCrypt PGP for MS/DOS $99.98 one user, $299.98 five user ViaCrypt PGP for Unix $149.98 one user, $449.98 five user ViaCrypt PGP for C$ $119.98 one user The Unix versions are for: SunOS 4.1.x, RS/6000 AIX, HP 9000 700/800 UX, SCO 386/486 UNIX (others soon). The Compu$pend version integrates into CompuServe Information Manager or CS Navigator for Windows. Includes the regular PGP and an integration program for CompuServe. DigiSig+ cryptographic modules: RSA, DES, and DSS. Developers' Kit $950 two user for MS/DOS. DigiSig+ D150. Software crypto engine. $80 to $20 depending on quantity. DigiSig+ D350. Parallel port crypto device, looks like a modem. $625 DigiSig+ D355. As above but plugs into serial port. $635 DigiSig+ D360. Internal board for PC. $595 Memory card - securely stores a secret key. $30 for two. From flesh at wps.com Tue Mar 8 19:52:02 1994 From: flesh at wps.com (Flesh) Date: Tue, 8 Mar 94 19:52:02 PST Subject: (forward message on privacy) Message-ID: <9403090351.AA01505@wps.com> Forwarded message: From hughes at ah.com Tue Mar 8 20:28:59 1994 From: hughes at ah.com (Eric Hughes) Date: Tue, 8 Mar 94 20:28:59 PST Subject: EFF's Barlow v. Denning on Clipper - AOL March 10, 9PM EST LIVE In-Reply-To: <199403090107.UAA08118@eff.org> Message-ID: <9403090421.AA14437@ah.com> You don't suppose someone with a brand spanking new $10 credit AOL account and who also had an Internet connection could provide a live feed of the debate to the world, do you? Nah. Eric From pfarrell at netcom.com Tue Mar 8 21:11:12 1994 From: pfarrell at netcom.com (Pat Farrell) Date: Tue, 8 Mar 94 21:11:12 PST Subject: DC Physical Meeting This Saturday Message-ID: <199403090511.VAA22280@netcom8.netcom.com> -----BEGIN PGP SIGNED MESSAGE----- This Saturday, March 12 starting at 3:00 PM EST and running until 5:30 PM, there will be a physical Cypherpunks meeting at the EFF's offices in downtown Washington DC. The meeting title is: Cypherpunks distributed meeting Politics, Strategies, and Action The meeting will run in parallel with several other c'punk meetings. If the technology works, we will have realtime audio feeds from other sites. If not, we'll call in using speakerphones (bring your long distance credit card as EFF is _not_ sponsoring us.) With the Clinton Administration's continued insistance on Clipper and the current revision of the FBI's Digital Telophony bill, we c'punks "inside the Beltway" need to get organized. Please do not bring PCs or floppies. We will be inside EFF's offices, and should not bring in, nor take out, any hardware or magnetic media. Paper copies of the MD5 hash of your PGP/ViaCrpyt keys for swapping are fine. We can use email or the keyservers to exchange the actual keys. Some EFF staffers are interested in getting signatures for their ViaCrypt keys. So this will be a good chance to expend the web of trust. Directions: EFF is at the Metro Center stop of the Metro. There is nearby street parking. The Metro stop is literally inside the building lobby. Address is 1001 G street, North West. This is the corner of 11th and G. EFF is in suite 950 East, but the meeting is on the 8th floor. Coming by the metro, leave the station through the Woodies Deli. Go though there, and there will be a set of double doors oposite an escalator. Go though the doors, around a corner and up two escalators. You should then be in the lobby of the EFF building. Off the street, We are next door to the Grand Hyatt, which is right across the street from the Washington Convention Center. Once again, come in and you should be in the lobby of our building. We will send folks down on the hour to let you into the EFF's secure space. Outside of those times, you can set up an appointment, or you will need to call up to get an EFF staff member to come down and let you in. Call 202-347-5400. ext 224 and ext 205 will probably get answered Saturday. Questions: Contact pfarrell at netcom.com or leave a voicemail (up until about noon Saturday) at (703) 267-2986) -----BEGIN PGP SIGNATURE----- Version: 2.3a iQBVAgUBLX1aIR9bGnaOb/KNAQF5BgIAx6SwF1q2H2W/Pt85g7TdfWV+vQIuU6oZ k42HeH8+CiRftiIGbtueso9v/hF1sLYAyUs+/4NAYPXegLpLzbrUbQ== =GlHV -----END PGP SIGNATURE----- From mpjohnso at nyx10.cs.du.edu Tue Mar 8 21:55:53 1994 From: mpjohnso at nyx10.cs.du.edu (Michael Johnson) Date: Tue, 8 Mar 94 21:55:53 PST Subject: Where'd pgptools go? Message-ID: <9403090535.AA27672@nyx10.cs.du.edu> Hal writes: >I notice on csn.org:/mpj there is now pgptl10d.zip, PGP Tools version >1.0d. However, 1.0d is not the whole PGP Tools program. It is just an >addendum which implements Diffie-Hellman. Apparently pgptl10c.zip is still >needed to give you the whole of PGP Tools. Does anyone know of an FTP >site which still has pgptl10c available? Thanks - I've merged the old & new files, now -- and put 10c back, just in case I missed something. ___________________________________________________________ |\ /| | | | | \/ |o| | Michael Paul Johnson Colorado Catacombs BBS 303-938-9654 | | | | / _ | mpj at csn.org ftp csn.org \mpj\README.MPJ for access info.| | |||/ /_\ | aka mpjohnso at nyx.cs.du.edu mikej at exabyte.com | | |||\ ( | m.p.johnson at ieee.org CIS 71331,2332 VPGP key by finger | | ||| \ \_/ |___________________________________________________________| From warlord at ATHENA.MIT.EDU Tue Mar 8 22:19:50 1994 From: warlord at ATHENA.MIT.EDU (Derek Atkins) Date: Tue, 8 Mar 94 22:19:50 PST Subject: ANNOUNCE: Boston Area Cypherpunks Meeting Message-ID: <199403090618.BAA24930@charon.MIT.EDU> There will be a meeting of the Boston Area Cypherpunks on Saturday, March 12, 1994 in MIT Room 1-115 starting at 3pm EST. The plan is to have an audio link to the other cypherpunks meetings around the country and around the world. The title for this meeting is: Politics, Strategies, and Action All further announcements about the Boston Area meeting will be made on the mailing list "cypherpunks-east at MIT.EDU". (Send sub/unsub requests to cypherpunks-east-request) Directions to MIT 1-115: Via T: Get off at Kendall, on the Red Line. Walk away from the marriott hotel, and walk until the street dead ends at Amhust. Take a right, and then keep walking. Follow the path across Ames street, and keep walking past the Great Sail, and when the path splits, take the 45-degree right path. Keep walking until you reach the steps into the building, and go in. Walk to the other end of the corridor. You will be in a large cathedral-like lobby (lobby 7) in front of 77 Mass Ave. Follow the signs for 1-115 from here. Via Bus: Take route 1 to 77 Mass ave and follow the signs Via Car: Drive to Cambridge. MIT building 1 is on the corner of Mass Ave. and Mem Drive, slightly south of 77 Mass Ave. Find a place to park, and enter the building from Mass Ave. Follow the signs to room 1-115. -derek From mbriceno at netcom.com Tue Mar 8 22:55:25 1994 From: mbriceno at netcom.com (Marc Briceno) Date: Tue, 8 Mar 94 22:55:25 PST Subject: chips... Message-ID: <199403090654.WAA07961@mail.netcom.com> X-Anon-Password:legal9road X-Anon-To:cypherpunks at toad.com >> Today I ran into a situation that made me completely nausiated and >> feel like my privacy had been completely invaded... It involves a >> chip which is implanted in animals and used for identification... > >> [....] "Well, if their doing this to animals, how soon will it be >> before they implant the same sort of thing in us?" She said, "Oh, >> I hadn't thought about it like that."... > >Several years ago (like mid or early 80's if I recall), there was >just such a program for marking children. It involved implanting >a "microchip" on the surface of a tooth. > Routine implants of transponder devices into humans are not a question of if, but only of when. I predict that they will become routine before the end of the decade. First they will be voluntary, used primarily in children to facilitate identification in case of abduction, some years later they will become mandatory for all drivers, to combat the use of fake driver licenses, and soon thereafter transponders will become the primary, if not sole accepted form of ID for all business transactions. A generation from now transponders will be mandatory used not only for identification, but for routine tracking of the movements of every citizen. If you think this sounds crazy, go to Germany, where you will find a camera on every major intersection, tracking your every move. -=T.A.Z. From 71431.2564 at CompuServe.COM Wed Mar 9 07:08:36 1994 From: 71431.2564 at CompuServe.COM (Bradley W. Dolan) Date: Wed, 9 Mar 94 07:08:36 PST Subject: FinCen Message-ID: <940309145545_71431.2564_FHA66-1@CompuServe.COM> This may be old news to you guys, but some of it was new to me: bdolan at well.sf.ca.us ... From: Bradley Parsons Subject: Clipper's Grandaddy: FinCEN To: uwsa at shell.portal.com Date: Wed, 9 Mar 94 1:57:27 CST Mailer: Elm [revision: 70.85] Status: R >From acad.stedwards.edu!parsons Wed Mar 9 01:42:56 1994 Newsgroups: alt.politics.clinton Path: acad.stedwards.edu!parsons From: parsons at acad.stedwards.edu (Bradley J. Parsons) Subject: Clipper's Daddy: FinCEN Sender: parsons at acad.stedwards.edu (Bradley J. Parsons) Message-ID: <1994Mar9.071635.3171 at acad.stedwards.edu> Date: Wed, 9 Mar 1994 07:16:35 GMT Distribution: usa Organization: Austin, Texas From: Ralf Brown Date: Mon, 7 Mar 1994 04:09:18 GMT 1.6: Big Brother

Big Brother Wants to Look Into Your Bank Account (Any Time It Pleases)

By Anthony L. Kimery ------------------------------------------------------- There wasn't much to go on. The police salvaged the slip of paper that a small-time East Coast drug dealer tried to eat before being arrested, but on it they found scribbled only a telephone number and what appeared to be the name "John." This frustrated the police. They had anticipated more incriminating information on the man they believed was the supplier not only to the dealer they'd just busted, but also to dozens of other street corner crack peddlers. With two slim leads, the police weren't technically equipped to do much more than antiquated detective work that probably wouldn't yield evidence they could use to indict John. So they turned to the quasi-secretive, federal Financial Crimes Enforcement Network (FinCEN) for the digital sleuthing they needed. Less than 45 minutes after receiving the official police request for help, FinCEN had retrieved enough evidence of criminal wrongdoing from government databases that the district attorney prosecuting the case was able to seek indictments against John on charges of money laundering and conspiracy to traffic narcotics. The local police were impressed. Launched with a low-key champagne reception at the Treasury Department in April 1990, FinCEN is the US government's (perhaps the world's) most effective financial crime investigation unit. Even Russian President Boris Yeltsin asked for its help in locating stolen Communist Party funds. This state-of-the-art computer-snooping agency is quietly tucked away under the auspices of the Treasury Department. Its mission is to map the digital trails of dirty money, be it the laundered profits from drug sales, stolen S&L loot, hidden political slush funds, or the financing conduits of terrorists. It's the only federal unit devoted solely to the systematic collation and cross-analysis of law enforcement, intelligence, and public databases. Until August 1993, FinCEN headquarters was an old Social Security Administration building with a ceiling ravaged by asbestos abatement crews, but that didn't seem to faze director Brian Bruh (he retired in October). With 25 years of experience in law enforcement, Bruh is a seasoned federal cop who has headed up criminal investigations at both the IRS and the Pentagon. Prior to overseeing FinCEN, he was the chief investigator for the Tower Commission, President Reagan's blue ribbon probe into the Iran-Contra scandal. FinCEN was his crowning achievement, and he took pride in directing visitors to FinCEN's computer command center as he touted the agency's successes. In private and in testimony to Congress, statistics roll off Bruh's tongue. Last year FinCEN's computer operations center responded to priority requests for tactical intelligence on nearly 12,000 individuals and entities, doubling the 1991 workload. The 1993 total will be three times the 1991 sum. Longer-term strategic analytical reports have been completed for 715 investigations involving 16,000 other individuals and entities. Two of the government's biggest strikes against organized drug-money laundering - operations Green Ice (a lengthy DEA operation that resulted in the arrests of high-ranking Cali and Medellin cartel financial officers and the seizure of US$54 million in cash and assets) and Polar Cap V (a spinoff of Green Ice that culminated in April 1990) - owe a great deal to FinCEN for having identified and targeted money laundering activities via computer. In the Polar Cap operation, FinCEN's computer tracking documented more than US$500 million in financial activity by 47 individuals who have since been indicted on drug trafficking and money laundering charges. Inside FinCEN's new digs on the second floor of a gleaming high-rise office building down the road from the CIA in Vienna, Virginia (otherwise known as "Spook City"), the talents of the IRS, FBI, DEA, Secret Service, and other traditional federal cops such as customs agents and postal inspectors are pooled. According to senior intelligence officers, these investigative units can access the resources of the CIA, the National Security Agency (which intercepts data on electronic currency movements into and out of the United States, some of which make their way into FinCEN's analyses), and the Defense Intelligence Agency. Bruh and other FinCEN officials openly acknowledge their association with the CIA, but they refuse to discuss further any aspect of FinCEN's dealings with it or any other intelligence agency. In addition to the CIA, intelligence officials have admitted, off the record, that the National Security Council and the State Department's Bureau of Intelligence and Research (INR) have also joined FinCEN's impressive intelligence crew. In short, FinCEN is a one-of-a-kind cauldron containing all the available financial intelligence in the United States. "It's the first ever government-wide, multi-source intelligence and analytical network brought together under one roof to combat financial crimes," said Peter Djinis, director of the Treasury Department's Office of Financial Enforcement and one of the few Treasury officials close to FinCEN activities. "FinCEN is absolutely necessary," said a senior General Accounting Office (GAO) official involved in an audit of FinCEN required by new anti-money- laundering laws passed last year. The agency's report wasn't released by press time, but according to the GAO official, no irregularities were uncovered. However, the GAO's scrutiny skirted emerging concerns about privacy, civil rights, and the appropriate role of the intelligence community. FinCEN's mission requires the involvement of the intelligence community, particularly in tracking the financial dealings of terrorists and in conducting financial counterintelligence, although few are willing to discuss the trend openly. Because these activities cross into the world of cloaks and daggers, some watchdogs are concerned that such endeavors will encroach on privacy and civil rights. When you look at the power of FinCEN and its proposed offspring, their fears seem justified.

How to Bust a John

The whiz kids at FinCEN are good. Very good. That's why state and local police have come to depend on FinCEN to pull them out of the electronic- sleuthing quicksand. The case of John the drug supplier is a good example of one of their less-complex assignments, and it illustrates the adeptness with which the government can collate existing financial data. Seated at a computer terminal inside FinCEN's former command post, a FinCEN analyst began the hunt. He started by querying a database of business phone numbers. He scored a hit with the number of a local restaurant. Next he entered the Currency and Banking Database (CBDB), an IRS database accessed through the Currency and Banking Retrieval System. CBDB contains roughly 50 million Currency Transaction Reports (CTRs), which document all financial transactions of more than US$10,000. By law these transactions must be filed by banks, S&Ls, credit unions, securities brokers, casinos, and other individuals and businesses engaged in the exchange of large sums of money. The analyst narrowed his quest by searching for CTRs filed for transactions deemed "suspicious." Financial institutions must still file a CTR, or IRS Form 4789, if a transaction under US$10,000 is considered suspicious under the terms of an extensive federal government list. There was a hit. A series of "suspicious" CTRs existed in the restaurant's ZIP code. Punching up images of the identified CTRs on his terminal, the FinCEN analyst noted that the transactions were made by a person whose first name was John. The CTRs were suspicious all right; they were submitted for a series of transactions each in the amount of US$9,500, just below the CTR threshold of US$10,000. This was hard evidence that John structured the deposits to avoid filinga Form 4789, and that is a federal crime. Selecting one of the CTRs for "an expanded review," the analyst got John's full name, Social Security number, date of birth, home address, driver license number, and other vital statistics, including bank account numbers. Plunging back into the IRS database, the analyst broadened his search for all CTRs filed on behalf of the suspect, including non-suspicious CTRs. Only 20 reports deemed suspicious popped up on the screen, but more than 150 CTRs were filed in all. A review of the non-suspicious ones revealed that on several, John listed his occupation as the owner or manager of the restaurant identified by the telephone number on the slip of paper taken from the arrested drug dealer. The connection between the name and the phone number originally given to FinCEN was secured. The FinCEN analyst then tapped commercial and government databases, and turned up business information on the restaurant showing that John had reported an expected annual revenue for his eatery of substantially less than the money he had been depositing, as indicated by the CTRs. Fishing in a database of local tax assessment records, the analyst discovered that John owned other properties and businesses. With the names of these other companies, the analyst went back into the CTR database and found that suspicious transaction reports were filed on several of them as well. As routine as such assignments as this case may be, the chumminess between FinCEN and the intelligence community raises serious questions about the privacy and security of the financial records of citizens John and Jane Doe, considering the intelligence community's historic penchant for illegal spying on non-criminals. Given the vast reach and ease with which the government can now tap into an individual's or business's financial records on a whim, these questions have received far too little scrutiny.

Whose Privacy?

"There are legitimate concerns" regarding privacy, a ranking House banking committee staffer conceded in an interview with Wired. "Quite frankly, there hasn't been much congressional oversight with respect to the intelligence community's involvement with FinCEN. When you start trying to look into this, you start running up against all kinds of roadblocks." The GAO official involved in auditing FinCEN agreed that questions regarding the intelligence community's involvement and attendant privacy concerns haven't been addressed. If such issues have been the subject of discussion behind the closed doors of the House and Senate intelligence committees, no one is talking openly about it. Meanwhile, the potential for abusive intrusion by government into the financial affairs of private citizens and businesses is growing almost unnoticed and unchecked. Two of the latest electronic inroads into the financial records of private citizens and businesses are "Operation Gateway," a FinCEN initiative, and the proposed Deposit Tracking System, which other intelligence agencies would like to see established. Both are inherently prone to abuse and provide a disturbing indication of the direction in which the government is moving. Gateway is a pilot program launched in Texas this July that gives state and local law enforcement officials direct access to the massive federal Financial Database (FDB) through a designated FinCEN coordinator. The FDB contains the records that financial institutions have been filing under the Bank Secrecy Act for the last 23 years - CTRs, suspicious transaction reports, International Transportation of Currency or Monetary Instruments reports, and Foreign Bank and Financial Accounts reports. In addition, Congress is expected to grant FinCEN authority to tap into the database of Forms 8300, which are reports of payments over US$10,000 received in a trade or business. These documents principally contain information on deposits, withdrawals, and the movement of large sums of currency. It is FinCEN's intent to give all state governments individual access to the FDB. Under the Gateway proposal, results from all queries would be written into a master audit file that will constantly be compared against other requests and databases to track whether the subject of the inquiry is of interest to another agency or has popped up in a record somewhere else. State coordinators designated by FinCEN will do the logging on, as FinCEN is uncomfortable with giving 50,000 federal agents and 500,000 police officers direct electronic access to its database. "This is very sensitive information," concedes Andy Flodin, special assistant to the FinCEN director. "We'd have to have additional security safeguards before we could open it up to every police agency." But while the FDB contains only records on major money movements and thus is not as much of a threat to individual privacy, the Deposit Tracking System (DTS) is a potential menace. If implemented, the estimated US$12.5 million computer system could be used to penetrate the security of bank accounts belonging to you, me, and 388 million other bank account holders in the US. The government argues that such a system is necessary for two reasons: first, to assess adequately the funding needed for federal deposit insurance and second, to locate the assets of individuals ordered by courts to make restitution for financial crimes - like the savings and loan crooks. (It seems the government can't trace most of the money they stole.) The first reason stems from a requirement of the seemingly innocuous Federal Deposit Insurance Corporation Improvement Act of 1991 - one of Congress's legislative responses to the savings and loan debacle. The Act requires the FDIC to study the costs, feasibility, and privacy implications of tracking every bank deposit in the United States. So far the DTS exists only on paper. The FDIC's completed feasibility study is currently being examined by Congress, but it is unlikely to act on it before late next year. For the time being, the US$12.5 million price tag seems to be the biggest drawback to its implementation. Concerns about the DTS have been widespread, although it has received scant attention in the mainstream press. But according to Diane Casey, executive director of the Independent Bankers Association of America, the DTS "would fundamentally change the relationships among banks, consumers, and the government in ways that have implications beyond banking policy. Our open and democratic society would be changed profoundly if any agency of the government maintained the scope of information on private citizens described in this proposal. It raises questions about our democracy that would have to be addressed by the highest policy-making levels of government." The American Bankers Association (ABA) voiced equally serious concerns. The ABA doubts "whether there are any privacy safeguards that would be adequate to effectively protect this database from use by government agencies and, eventually, private parties," an ABA spokesman explains. "It is inconceivable to the ABA that such a database could be used only by the FDIC in deposit insurance coverage functions. Such a database...would provide a wealth of information for investigations being conducted by the FBI, the Drug Enforcement Administration, and the IRS, to name but a few. Like the baseball diamond in Field of Dreams, build this database and they will come. Eventually, whether legally or illegally, they will gain access to this database." The FDIC forcefully argued against the DTS in the 234-page draft report it submitted to Congress in June 1993, but it may not have the bureaucratic clout necessary to kill the proposal. Wired was told by intelligence analysts and congressional sources dealing with oversight of the intelligence community that federal law enforcement and intelligence agencies are privately clamoring for the system, apparently disregarding both the privacy issues and the system's start-up cost (which does not include the additional US$20 million a year the feasibility study said would be required for facilities, for salaries and benefits, and for routine hardware and software maintenance). Further driving the intelligence agencies's desire for the DTS is the much- hyped role of economic intelligence gathering, a key focus of the Clinton administration's reform of the intelligence community. Agencies like the CIA view the system as a boon to their ability to monitor foreign financial dealings in the US, according to both congressional and intelligence sources.

Adding Intelligence to the Equation

Regardless of the form it takes, the sources said, the DTS and any other financial databases that come down the pike could be easily interfaced to FinCEN's Artificial Intelligence/Massive Parallel Processing (AI/MPP) program, a criminal targeting system that will go online in a few years. Because laundered money is moved undetected along with the millions of legitimate computerized wire transfers that occur daily, FinCEN's computer investigations naturally demand expert systems that can single the dirty money out of the crowd. FinCEN's current Artificial Intelligence capability allows it to search the Financial Database for suspicious, preprogrammed patterns of monetary transactions. While not very flexible, the system has successfully identified previously unknown criminal organizations and activities. But FinCEN has a hush-hush US$2.4 million contract with the US Department of Energy's Los Alamos National Laboratory to develop what Bruh and other FinCEN officials de-scribed as a powerful "money flow model." Unlike FinCEN's current system, Los Alamos's AI software will look for unexplained, atypical money flows. Coupled with a massively parallel computer system, the AI/MPP could perform real-time monitoring of the entire US electronic banking landscape. FinCEN's AI capabilities currently exploit the Financial Database for proactive targeting of criminal activity. The system automatically monitors the entire FDB database, constantly identifying suspicious financial activity in supercomputer-aided, rapid-response time. In addition to the FDB, FinCEN is applying AI to the Criminal Referral Forms that must be filed with FinCEN whenever banks, examiners, and regulators uncover financial activities they suspect are illegal. In the near future, all of these government databases will be interfaced by way of AI/ MPP technology. "MPP is critical to FinCEN's ability to analyze (banking) data to its full capacity," Bruh insists. The pure power of such a "database of databases" terrifies critics. Though FinCEN and other authorities discount the potential for abuse, tell that to the CIA. Its charter forbids it from engaging in domestic surveillance; nonetheless, it spied on Americans for seven consecutive presidential administrations (it says it finally ceased its internal spying in the mid- 1970s). FinCEN's AI operation has been employed legitimately with great success. Perhaps its least-known project was assisting the CIA in identifying and tracking the flow of money between Iran's state-sponsored Islamic fundamentalist terrorist organizations and the men linked to the bombing of the World Trade Center. According to a Treasury official and confirmed by Anna Fotias, FinCEN's congressional liaison, FinCEN identified suspicious transaction reports filed by a bank in New Jersey on wire transfers from Germany to the accounts of two of the men charged in the bombing. With the bank account in Germany identified, further AI processing - utilizing intelligence from the CIA's DESIST computer system, the world's most extensive database on terrorists - identified a company as a front for an Iranian terrorist group. Coupled with DESIST's data on the two men's terrorist connections, FinCEN was able to identify a number of previously unknown conduits of terrorist funding in the US and abroad. Similarly, FinCEN was crucial in identifying Iraqi assets in the US that were frozen in the wake of Iraq's invasion of Kuwait, according to a Treasury official. Still, given the CIA's less-than-spotless record, privacy advocates are likely to find it disturbing that there are some within the walls of CIA headquarters - apparently unbeknownst to anyone at FinCEN - who want to mesh DESIST with FinCEN's eventual AI/MPP ability and with all the databases FinCEN routinely surveys. The justification for creating such a system is compelling: More likely than not it would identify scores of previously unknown financial conduits to terrorists. Advocates of a full-time DESIST/FinCEN system carry their argument one step further: Hooked into the yet-to-be-authorized Deposit Tracking System, the DESIST/FinCEN system would be able to identify terrorist financial movements in real-time, thus providing early warning of potentially imminent terrorist actions. Some within the intelligence community take it still another step: They would have the system tied into the private computers that hold credit card transactions "so that we could have nearly instant time-tracking capability," according to one source who works closely with the CIA's Counterterrorist Center. Conversely, a CIA/FinCEN/DTS endeavor could monitor on a real-time basis the financial activity of narcotics traffickers, since drug dealing also is within the purview of the CIA. The agency's Counternarcotics Center, or CNC, already works closely with FinCEN. Before the CIA would be allowed to tap into a system as sensitive as the proposed Deposit Tracking System, it would have to clear plenty of civil liberties hurdles, not the least of which is the prohibition on the CIA from gathering intelligence on US citizens. As long as the DTS itself was shielded from direct access by the CIA, proponents could argue that the operation was allowable under law. Opponents, on the other hand, fear that the CIA would find a way to download, copy, or otherwise secretly access the DTS. "The risk of the CIA getting its hands on this is serious - we know the kind of unscrupulous people who populate the spook world," said a Washington-area private investigator who conducts many legitimate financial investigations for a CIA-linked firm. "This kind of financial data, when coupled with other information like a person's credit history, could be used for blackmail, bribery, and extortion," said the investigator, who has a military intelligence background. Bruce Hemmings is a veteran CIA clandestine-services officer who retired in 1989. Prior to the DTS proposal, he told Wired that the CIA routinely digs for financial dirt on people from whom the agency wants specific information. Typically they are foreign intelligence officers working in the US under a diplomatic guise, and this financial information is often used as leverage in getting them to talk. In less civilized venues, this is called blackmail. DTS could present an inviting mechanism for quieting unwanted dissent or for defanging an unruly congressional leader bent on exposing some questionable CIA operation. Although still in its embryonic stage and in spite of the looming privacy obstacle it will inevitably confront, FinCEN is seen by many in the government as the catalyst for a powerful, all- seeing, all-knowing, global, financial-tracking organization. In fact, FinCEN is al-ready working closely with INTERPOL, and Bruh's deputy just resigned to head up INTERPOL's US office. As the privacy debate heats up, FinCEN's digital dirty-money trackers go on about their work, hoping they don't have to choose sides if what they do becomes a full-blown privacy invasion problem. As Bruh puts it, "There's tons of crooks out there who are disguising their criminal profits. FinCEN needs to computerize as much as possible to be able to identify the really significant criminals and their activities." The question then becomes, at what point does it stop? * * * Anthony L. Kimery covers financial industry regulatory affairs as an editor at American Banker Newsletters. ------------------------------------------------------- Copyright (c) 1993 Wired magazine Requesting information from the Wired InfoBot (other than the help file) indicates your acceptance of the following terms and conditions: (1) These articles and the contents thereof may be reposted, remailed, or redistributed to any publicly accessible electronic forum provided that this notice remains attached and intact. (2) These articles may not under any circumstances be resold or redistributed for compensation without prior written agreement of Wired. (3) Wired keeps an archive of all electronic address of those requesting information from the Wired InfoBot. An electronic mailing list will be compiled from this archive. This list may from time to time be used by the staff of Wired Online Services for the purpose of distributing information deemed relevant to Wired's online readers. If you wish to have your name removed from this mailing list, please notify us by sending an electronic mail message to infoman at wired.com. If you have any questions about these terms, or would like information about licensing materials from Wired, please contact us via telephone (+1.415.904.0660), fax (+1.415.904.0669), or email (info at wired.com). From cowen at glia.biostr.washington.edu Wed Mar 9 09:43:14 1994 From: cowen at glia.biostr.washington.edu (cowen at glia.biostr.washington.edu) Date: Wed, 9 Mar 94 09:43:14 PST Subject: No Subject Message-ID: <9403091753.AA17699@glia.biostr.washington.edu> all this about newbies>> i for one am a newbie,, gee i hate that word,, at least to this list. though i have been in and around computers since 81. over 13 years now most of what i have been around is the bbs, and programing, and hardware of computers. also i am an information freak from early childhood. the major pitch of my crypto has been word based, not computer based but i understand the princibles behind it. though my main concern of late has been the up swing in government and criminal investigators involment in the computer field. most notablly with the clipper and other chips. i have always been a privacy advocate. having done things in early youth that in a world ruled by "big brother" i would surely be targeted for. i do not want the US of A or most of the free world to be ruled by "big brothers" that is why i read this list and others. yes in the past i have posted rants, and raves. but that is life. i talk the good ole heart and soul while others talk the techno ascept of the issues at hand. ' charles the monster maker From hayden at krypton.mankato.msus.edu Wed Mar 9 10:03:30 1994 From: hayden at krypton.mankato.msus.edu (Robert A. Hayden) Date: Wed, 9 Mar 94 10:03:30 PST Subject: he's baaaaaaaack Message-ID: I noticed following on comp.org.eff.talk this morning. Seems our friend is back, although it could be forged (dunno). (headers left intact) ---------- Forwarded message ---------- Subject: (fwd) Re: Time Poll Reports that 80% Oppose Clipper Newsgroups: alt.privacy.clipper,talk.politics.crypto,alt.privacy,comp.org.eff.talk,alt.politics.datahighway Relay-Version: ANU News - V6.1 08/24/93 VAX/VMS V5.5-1; site vax1.mankato.msus.edu Path: vax1.mankato.msus.edu!msus1.msus.edu!news.gac.edu!msc.edu!apctrc!paperboy.amoco.com!news.ans.net!howland.reston.ans.net!europa.eng.gtefsd.com!library.ucla.edu!ihnp4.ucsd.edu!ames!purdue!yuma!lamar.ColoState.EDU!tmp Newsgroups: comp.org.eff.talk,alt.privacy,alt.privacy.clipper,talk.politics.crypto,alt.politics.datahighway Subject: Re: Time Poll Reports that 80% Oppose Clipper Message-ID: <1994Mar7.225027.119747 at yuma> From: tmp at lamar.ColoState.EDU (L.Detweiler) Date: 7 Mar 94 22:50:27 GMT Followup-To: alt.privacy.clipper,talk.politics.crypto,alt.privacy,comp.org.eff.talk,alt.politics.datahighway References: <2ldaj8$h3k at news1.digex.net> Nntp-Posting-Host: lamar.acns.colostate.edu X-Newsreader: TIN [version 1.2 PL2] Lines: 11 Xref: vax1.mankato.msus.edu comp.org.eff.talk:2152 alt.privacy:916 talk.politics.crypto:744 alt.politics.datahighway:471 : ''The crypto genie : is : out of the bottle,'' says Steven Levy, who is writing a book about : encryption. If that's true, even the nsa may not have the power to put it : back. @#$%^&* cryptoanarchists are everywhere. now `cryptoanarchy' is an official media term! @#$%^&*! who wants to bet me any amount of $$$$ that the Levy book will be a great paen to the cypherpunks? Oh, the glorious cypherpunks, the digital warriors, the knights in incandescent armor, I bow before you. From collins at newton.apple.com Wed Mar 9 10:28:01 1994 From: collins at newton.apple.com (Scott Collins) Date: Wed, 9 Mar 94 10:28:01 PST Subject: Why the chip in my dog won't work in humans. Message-ID: <9403091743.AA29237@newton.apple.com> >> Today I ran into a situation that made me completely nausiated and feel like >> my privacy had been completely invaded... It involves a chip which is >> implanted in animals and used for identification... I have such a chip in my dog. Why? Animal services can destroy a stray animal after as little as 48 hours. My dog doesn't speak English, and if she loses her tags and gets lost --- she's a stray! Animal services scan (and you have to be pretty close, like those door-opening-id-cards) all the animals that are picked up. If there's a chip, the animal WON'T BE DESTROYED. They'll call the Infopet service, who will in turn call me, and I'll come pick her up. Additionally, I have pre-authorized emergency medical attention for her. If she needs help, she'll get it even if they don't know where I am. And, as others mentioned, if she is stolen then the next time she is taken in to the vet (my vet and many others in CA scan as a matter of course) or picked up by animal services ... I will know about it. I love my dog. She's a good companion; and I take good care of her. She has never lost her tags or `gotten loose'. But if she ever does... ...this chip will help me recover my property. Whoa! what happened to loving companion? How did we go from friend to chattel? The truth of the matter is that the law considers and dog _owners_ act as though dogs are property. They have value. They need to be protected like any other piece of property. I love my dog, but that doesn't change the fact that if she fell in love with YOU and wanted YOU to be her master and decided she no longer loved ME ... she would still stay with me, because she's mine. - --- - Is this the edge of a slippery slope for putting chips in human beings? I don't think so. The reasons for having such a device in a dog are completely different from the reasons for having them in an human being. In one case it is essentially to identify property (like a brand on a cow -- we still don't brand humans), in the other it is to make a certain kind of deception more difficult. Marking children as though they were animals or property? Grotesque. Marking adults for identification? Hopeless. Dogs don't even know what a chip is, let alone that they have one implanted in them. They won't remove or replace it; but a human bent on such a course will. Therefore, as identification or proof of permission, it will be no better than the cryptographic system beneath it. In which case, it will be pointless to have an implant rather than a smart card. Scott Collins | "That's not fair!" -- Sarah | "You say that so often. I wonder what your basis 408.862.0540 | for comparison is." -- Goblin King ................|.................................................... BUSINESS. fax:974.6094 R254(IL5-2N) collins at newton.apple.com Apple Computer, Inc. 5 Infinite Loop, MS 305-2D Cupertino, CA 95014 ..................................................................... PERSONAL. 408.257.1746 1024:669687 catalyst at netcom.com From cowen at glia.biostr.washington.edu Wed Mar 9 10:41:07 1994 From: cowen at glia.biostr.washington.edu (cowen at glia.biostr.washington.edu) Date: Wed, 9 Mar 94 10:41:07 PST Subject: No Subject Message-ID: <9403091851.AA17998@glia.biostr.washington.edu> re the issuing of smart cards in france. when will we in the US of A be issued our ID card? already in some states you hve to have so much id just to get a drivers liscence that it is not funny. recently my fiancee lost her date book, for her it is a purse anything about her that would be needed to form another history via id was in there. and being adopted she did not have a copy of her birth certificate.. makes you wonder if the "smart card" is reaaly the better idea. to make it seem good to folks, lets have encryption in the card we can access certain parts of the card, via our own password, given it would have to be a hard to get password, something like 2BeoR^3%iT in at least 10 charactors long. we could all have them hooked to our money supply that would cut down on the fake card/money/credit business a bit and give us more ability to be controled by the governing bodies if we fail to pay the IRS one year, they could just take it out at their stations in the big office at the IRS building. or even the voting, pass it through the voting booth reader and key int he ones you want to help control your life. neato,, do away with all the bulky change i carry around too!! charles the monster maker From marc at security.ov.com Wed Mar 9 11:06:48 1994 From: marc at security.ov.com (Marc Horowitz) Date: Wed, 9 Mar 94 11:06:48 PST Subject: I hate to blast the whole list with this, but.... Message-ID: <9403091906.AA02087@dun-dun-noodles.aktis.com> When requesting to be added to an Internet mailing list, *ALWAYS* try to send mail to listname-request at host to reach the administrators. We've gotten three messages to cypherpunks-east at mit.edu today asking to be added. Don't send mail to the list! If you want to be added, we'll be happy to do it if you send mail to cypherpunks-east-request at mit.edu. If you ever decide you no longer want to be on cypherpunks, send mail to cypherpunks-request at toad.com. And so forth. I'm on large lists which get several requests sent directly to the list every day by people who don't know any better. This is annoying All future list maintenance requests sent directly to cypherpunks-east will be met with scorn and derision, and quite possibly ignored. Thank you for your assistance. Marc From gtoal at an-teallach.com Wed Mar 9 11:40:08 1994 From: gtoal at an-teallach.com (Graham Toal) Date: Wed, 9 Mar 94 11:40:08 PST Subject: chips... Message-ID: <199403091936.TAA11490@an-teallach.com> an57322, I believe? Bwahahaha. Which adds to my theory that the major use of anonymity and |<00|_ anon handles on the net is posturing and self-grandification. Go sit in the corner with Xenon... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 8 Mar 1994 22:53:47 -0800 From: Marc Briceno Subject: Re: chips... Sender: owner-cypherpunks at toad.com Precedence: bulk X-Anon-Password:legal9road X-Anon-To:cypherpunks at toad.com -=T.A.Z. I'd change that password if I were you, TAZ, if someone else hasn't already done so... And when you get a new account, remember to post to penet.fi instead of the list directly. G From GERSTEIN at SCSUD.CTSTATEU.EDU Wed Mar 9 12:20:26 1994 From: GERSTEIN at SCSUD.CTSTATEU.EDU (GERSTEIN) Date: Wed, 9 Mar 94 12:20:26 PST Subject: keeping secrets from myself Message-ID: <940309151935.202248e2@SCSUD.CTSTATEU.EDU> On 8-MAR-1994, Cortland D. Starrett (cort at ecn.perdue.edu) said... ========== Here is a practical problem that has me frustrated.... Situation: Assume that I am the treasurer at my local church. This implies responsibility to record each Sunday's offering (the money collected) in the church financial books. An account is maintained for each member of the church. Money received from members each Sunday is credited to their respective accounts. Each January, a report is prepared for each parishioner showing a summary of the charitable contributions for the previous year. This information is used for tax purposes. Currently, the treasurer knows EVERYTHING about EVERYONE (regarding charitable giving). As a privacy advocate, this is indeed uncomfortable (for giver and treasurer). Problem: I want to know as little as possible about church member giving. Give and Take: It will be difficult/impossible to prevent the treasurer from seeing each weeks' checks. However, a privacy improvement may be achieved if the running totals are kept hidden. How can I provide a comprehensive year-end statement to each parishioner while maintaining maximum privacy? Does cryptography have anything to offer to this situation? What procedures/protocols could be implemented? What privacy enhancements could be included with the church accounting software? Cort. =========== I would think that the easiest way to take care of this would be to assign each member a randomly generated id (probably alphanumeric, and you can keep it around 6 characters), and then just use that number from then on. When a new member joins, create a new id and once they have a copy of it, put the id in a file that is stored out of your hands (but accessable if need be) in case you need to add someone else or if someone forgets their id. I know that this isn't as secure as some of the other methods suggested, but this (the method above) would seem to make the most sense simply because once it's started, there's not that much upkeep: 1- Member gets an id. 2- Member makes a deposit using just their id and only looking at the check amounts. For this, you would have to trust yourself or get some envelopes that only show the amount through a window. When you are done doing all the checks on the computer, dump them all into a bag or something and then start endorsing them. 3- At the end of the year, all you have to do is print a list of the id's and how much they have in their "account". At no time does anyone but the member know their id (unless they happen to share with someone, and it's up to them). As treasurer, you only know the account numbers. If you really didn't want to take the chance that you might learn some of the numbers (doubtful, as there would probably be 100's [maybe 1000's] of members), you could get someone else in the church (that you trust) to assign the id's and just have them let you know the new id's as they come along. Just my 0.02� worth. Adam Gerstein -=-=-=-=-=-=-=-=- Have _you_ said no to Clipper yet? To sign on to the letter, send a message to: Clipper.petition at cpsr.org with the message "I oppose Clipper" (no quotes) You will receive a return message confirming your vote. From hughes at ah.com Wed Mar 9 12:27:41 1994 From: hughes at ah.com (Eric Hughes) Date: Wed, 9 Mar 94 12:27:41 PST Subject: on tmp@lamar.acns.colostate.edu Message-ID: <9403092020.AA16279@ah.com> No, the Usenet post from that site is not forged. I just corresponded with LD himself there. Eric From mech at eff.org Wed Mar 9 13:42:28 1994 From: mech at eff.org (Stanton McCandlish) Date: Wed, 9 Mar 94 13:42:28 PST Subject: 80% of even the *NON*net public oppose Clipper (...when informed) Message-ID: <199403092033.PAA05551@eff.org> "In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two-thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it." - Philip Elmer-Dewitt, "Who Should Keep the Keys", TIME, Mar. 4 1994 EIGHTY PERCENT, folks. You know what that means. This is now the time to spread the word on Clipper, far, fast and wide. If there are 3 local newspapers in your area, send an op-ed or letter to the editor, to ALL of them, and magazines too. If you are a pro writer, time to start writing articles. Redistribute Clipper to the net, and especially to BBSs. The problem here is one, and one only: not enough people know about Clipper yet. When EVERYONE does, even Clinton dares not go against the will of 80% of the populace. Do you run a BBS? Make an anouncement about Clipper (and the 80% opposition rate!) as one of your login screens. Put it in your .signature or your .plan, print up some flyers, put it in your zine, wear it on a t-shirt, whatever it takes to get the message out. Leahy's hearings are going to be something else. The Cantwell bill will help. But nothing will be as effective as mass public outcry. Don't just sit here. Usenet will be here tomorrow, too. Do something to educate someone about Clipper and the threat it poses to our privacy NOW. After that, if you have yet to send in your short letter of support for the Cantwell bill (HR2637), which will reduce export restrictions on non-Clipper cryptography, please do it today. Send to cantwell at eff.org. -- Stanton McCandlish * mech at eff.org * Electronic Frontier Found. OnlineActivist "In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two-thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it." - Philip Elmer-Dewitt, "Who Should Keep the Keys", TIME, Mar. 4 1994 From frissell at panix.com Wed Mar 9 15:08:21 1994 From: frissell at panix.com (Duncan Frissell) Date: Wed, 9 Mar 94 15:08:21 PST Subject: In Memorium Message-ID: <199403092307.AA27329@panix.com> Sandy Sandfort's [sandfort at crl.com] inamorata, Diane Somers, died in a traffic accident on Tuesday afternoon. DCF And Death shall be no more: Death, thou shalt die! --- WinQwk 2.0b#1165 From MATTKELLY at antioc.antioch.edu Wed Mar 9 17:24:50 1994 From: MATTKELLY at antioc.antioch.edu (Matt_Kelly) Date: Wed, 9 Mar 94 17:24:50 PST Subject: please remove me from cypherpunks-announce list Message-ID: <01H9S4Q9SSEG00010W@antioc.antioch.edu> Please remove me from ALL (including cypherpunks-announce) lists. Thanks. From tcmay at netcom.com Wed Mar 9 17:57:49 1994 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 9 Mar 94 17:57:49 PST Subject: The Coming Police State Message-ID: <199403100158.RAA27863@mail.netcom.com> An alarmist title? Perhaps. But likely accurate. Since the theme of the upcoming Cypherpunks meeting on March 12th, with sites around the world tied together, is "politics" and since Eric Hughes has encouraged "rants," I'm making these comments now. The war is upon us. All _three_ of the major U.S. weekly news magazines have articles on cops in cyberspace, the threat of Clipper, and the fast computerization of the surveillance society. Books are being written on crypto issues (beyond the excellent Schneier book, I mean), and the issues have resonance amongst a skeptical public. Strange bedfellows, ranging from Pat Robertson and Phyllis Schlafly to civil libertarians on the other side have come out against Clipper. (I suspect had Bush won, Robertson and Schlaffly would be much quieter about Clipper, just as many Democrats are being somewhat circumspect in their criticisms of Clipper today. People need to realize this issue cuts across all party lines. Ditto for non-U.S. people as well, despite the U.S.-centric focus of these comments.) The Cypherpunks fill an important niche that none of the other major groups wants to--or are able to--fill. The EFF, CPSR, and ACLU have different skills than we have, have more money (we have _none_, of course, as an organization), and are mostly "centralized lobbying" groups (all are headquartered in Washington, D.C.). Cypherpunks are scattered around the world, with only this mailing list and the physical meetings creating any real nexus. By default, of course, the Bay Area has tended to dominate, in raw numbers, in physical meetings, and in the early history of the list, but hopefully this will change as the Cypherpunks continue to grow and as other sites become more active in their chose areas of expertise. And the Cypherpunks mailing list has an interactive mailing list filled with some of the world's best cryptographers and security experts (you know who you are), and several hundred creative folks, many of whom actually write code! Plenty of problems face us, but we have plenty of talent, too. And of course we have justice and the inevitability of technology on our side. IS A POLICE STATE REALLY COMING? "Not if we can help it," of course. But right now things look pretty grim. George Orwell got it mostly right, even in choosing a corporatist model of Britain as the setting instead of the more-expected Stalinist models of the time. (I'm an anarcho-capitalist, personally, so I have nothing against corporations _per se_. But I despise the situation of "state socialism," which is what fascism really is, in which corporations are given special rights and responsibilities in exchange for being supported or selectively rewarded by the State.) In the U.S. at least (and more on Europe and Asia later), the cyberspatial police state is no longer associated with just one political party. The Clipper program and Digital Telephony were started under the Reagan (probably_ and Bush (for sure) administrations, and now the Clinton and Gore folks have shown themselves to be enthusiastic supporters of Big Brother. The National Health Care program, perhaps temporarily stalled on a side street by the current Whitewater/Hillary circus, may have implications for this police state that are unclear....national ID cards, FinCEN-type monitoring of alcohol and tobacco purchases, even biometric identity systems. And the National Information Infrastructure, the NII, has the potential for further concentrating and regulating the presently anarchic networks. Driver's licenses for the information highway? Learner's permits? Revoked licenses for "hurtful speech" and other thoughtcrimes? WHAT ARE WE FACING? -- Digital Telephony II for easy access to _all_ communications channels. If this becomes law, expect all equipment makers to add wiretapping capabilities. All operating system makers may have to add tap points to allow government access (so much for "secure operating systems," such as Norm Hardy and others are working on). -- Clipper and its Big Brethren for easy access to the contents of files. The State will use its power to enforce standards, control exports, and punish corporations so as to ensure competitors do not arise. -- The likely criminalization (via civil forfeiture, a la the Drug War) of unapproved crypto alternatives. (As Whit Diffie has noted, this will not completely stop unapproved use, but will force it underground and marginalize it, causing most folks to so fear prosecution and forfeiture of their homes and companies that they'll avoid unapproved crypto and will help narc out others.) -- Expansion of these tools to other "New World Order" nations, including rapidly-developing systems in Germany, France, Britain, Japan, and other countries. (Reports of "family keys" being prepared for these countries, of restrictions on private use of crypto already in place in some of these countries, and of positive reaction to the American Clipper system.) -- The State getting involved in the "Digital Superhighway" increases the potential for licensing, control, speech codes, etc. For example, one can imagine "fair access" laws which ostensibly make getting on the Net easier and cheaper (not really, of course) but which come with strings attached. Limitations on pseudonyms, restrictions to only RSA-approved public keys (cf. a frightening proposal by Carl Malamud to "nationalize" public-key technology and then give every citizen his own public key...such a system would destroy most of the exciting possibilities some of us foresee and would create a complete surveillance market--this is just one possible future being bandied about by the technocrats and "policy wonks"). (I know some List members, especially those connected with the EFF, have a more charitable view of the NII. But even Mike Godwin has quipped about the "Digital Snooperhighway.") So, is it all hopeless? WHAT COULD DERAIL THE CYBERSPACE POLICE STATE? 1. Defeat of the Digital Telephony Bill. Groups like the EFF and CPSR effetively stopped the first attempt, but a new one was recently unveiled. In many ways, much worse than the first one. This one has to be stopped as well! (In general, all readers of this List should be signing the various petitions that come along, including the "I oppose Clipper" and "I support the Cantwell Bill" ones. You should make your own decisions, of course, but it is hard to imagine that any of you would be opposed to these sentiments. The key is to to make sure a significant fraction of you 700-800 readers sign these petitions! That's a hefty voting bloc, and would give Cypherpunks some additional respect or influence amongst the petition circulators.) 2. Work closely with EFF, CPSR, and other groups (ACLU?) in their efforts to stop these developments. Being that many of us know a fair amount about crypto, security, and computers, we could provide technical assistance to these organizations. (The Washington, D.C. group could, as we have often discussed, have an especially beneficial effect on the debate, as Congressional staffers could be brought up to speed by Cypherpunks in the area. Be sure to concentrate equally on Republicans and right wingers as on Democrats and left wingers!) (In my opinion, our "outlaw" image continues to serve us well. While the "suits" talk to Congresscritters, there's still a role to be played for more guerilla-oriented folks such as ourselves. Sure, there's a downside, and not all are comfortable being portrayed as "anarchists" or "cypher criminals," but that's how we got started--not that we are all either anarchists or criminals!--and there's been little pressure to change. For now, it lets us play a kind of "good cop-bad cop" game....or, "hybrid vigor," with the Cypherpunks filling a different niche than the suits of EFF and CPSR fill.) 3. Widespread repudiation of the Clipper program and its evil Big Brethren, the Capstone, Skipjack, Tessera, "iPower," and related technologies. We talk about Clipper a lot here, and about ways to defeat it, so I won't go into this here. 4. Active sabotage, to include: - Boycotts of AT&T for building Clipperphones, of VLSI Tech for building the Mykotronx chips, of National Semiconductor for building the "iPower" PCMCIA card, and of others who are becoming known for being involved (more on this later, when I am liberty to say more). (My old company, Intel, is a 20% owner of VLSI Tech, actual manufacturer of the Clipper chip--draw your own conclusions.) - "Big Brother Inside" stickers. Thanks to the several of you who actually got these stickers _made_....it was at the special meeting last April that I drew this logo on the whiteboard and then did a posting of the ASCII design. While I will not encourage you to surreptitiously place these stickers on boxes containing the products of the aforementioned companies, let your conscience be your guide. Wink. - Ridicule and "psychological warfare." I upset a few people when I called this "disinformation" a while back. I don't mean actual lies, but, rather, *creative speculation* and the sowing of doubts in people's minds. For example, most of us (safe to say, I think) understand that the real danger, the real threat, of Clipper is the imminent outlawing of alternatives to Clipper. We understand this even though the "facts" on Clipper are nominally that Clipper will be "voluntary." We "know" this is not so, both in terms of reasonable historical projections and in terms of the already-developing policies on exports which will make non-Clipper schemes much harder to export than Clipper. Hence, we need to "fill in the gaps" for people and point out to them that crypto alternatives to Clipper are likely to be banned or otherwise made nearly impossible to use. This banning may happen in various ways, ranging from outright bans on non-escrow crypto methods (yes, enforcement difficulties abound) to use of RICO and conspiracy laws to effectively make alternatives to Clipper too difficult to use--how'd you like to face subpoena of your bank records or IRS visits everytime a non-Clipper crypto scheme was detected? (IRS is understaffed, so this won't be trivial, but other things may be possible.) - Help to convince companies _not_ to use Clipjacked phones. Ideally, create a mood in which the use of Clipper marks one as a stooge of Big Brother and as not having a good work environment. (This can begin to work as potential hires ask pointedly, for example, about the Clipper policy of the company.) - Talks with journalists. We can reach far more people this way than by nearly anything else we do. Steven Levy will be at the Saturday meeting, preparing both an article on these issues, and a book for future publication (being an optimist, even I don't believe he'll be barred from publishing such a book). Other journalists are similarly interested. And the coverage by the major news magazines and newspapers is increasing, as noted above. WHAT ELSE CAN WE DO? - Increase deployment of crypto tools. Get the genie _all of the way_ out of the bottle. Make outlawing crypto too painful. Integrate PGP with standard mailers (a project that's been stalled for more than a year now). - Voice PGP or similar. A half-dozen projects are reportedly in various stages of completion. 486 PC prices are dropping into the noise, so that even dedicated Mac users (like me) can consider buying a 50 MHz or better 486 box and using it with a SoundBlaster-type processor card. But when will these systems actually appear? Time is of the essence. - New systems. I've said it before: we had some early wins with the Cypherpunks remailers, but follow-ons have been slow in coming. We often see a spate of good ideas--such as on digital money, or steganography, or the like--but then these ideas don't become "standards." This could be for a variety of reasons, so I'm not casting stones here. But it's a phenomenon we should think about and try to resolve. Let's find a way to get more "outposts" in cypherspace built, deployed, and maintained. Voice PGP, as mentioned above, would be a natural one. - Remailer sites in non-U.S. countries. This needs to be a higher priority. Get a robust remailer, using PGP or ViaCrypt PGP (for bulletproof legality reasons), in at least a dozen countries. Digital postage will help incentivize remailer operators to get into the business, to maintain the systems in a less-lackadaisical way (no offense, but seeing remailers drop like flies as student accounts expire or vanish mysteriously is not confidence-building). The "second generation remailer" stuff needs to be incorporated at least partly. - Private networks, like Little Garden, offer greater robustness against intrusions by regulatory authorities. The more of these ad hoc, anarchic nets, the less chance the State will have of (somehow) nationalizing or otherwise taking control of them. Especially if nodes are outside the U.S. - Several of us have expressed some serious interest in leaving the U.S., for various reasons. I am one of these folks. Many issues here, but creating more offshore locales for Cyperpunks activity, with good connections to other Nets, lots of encryption, etc., will be helpful. (Compiling a kind of "Cyberspace Retirement Places Rated" database is one project I am thinking of taking on after I finish the Cypherpunks FAQ. Lists of various places, their local laws and policies, tax situation, extradition treaties with the main police states, Net connections, etc. Maybe even some R&D trips down to the Caymans, Turks and Caicos Islands, Belize, etc. Contact me if interested.) - "Active Measures." More covert efforts to disrupt Clipper-type activities. Use your own imagination here. - Research the deep and disturbing links between various government programs. FinCEN and the siphoning-off of S&L funds by CIA proprietaries, the NSA's economic intelligence units and the surveillance of business dealings, the infiltration of Silicon Valley companies by government "sheep-dipped" agents, the links between the NSA and the German Bundesnachrichtendienst, the links between the Witness Protection Program and the three main credit reporting agencies (to falsify credit records, to hide assets, etc.). Granted, some of this stuff borders on "conspiracy theory" (a hobby of mine, perhaps unsurprisingly). But a lot of it is substantiated, if one knows where and how to look. James Bamford has been quoted as saying that he could fill an entire new book with the machination of the Surveillance State. And a lot more.... CONCLUSIONS We are at one of those important cusp points in history. The technologies of networks and of encryption make it very easy for exciting new structures to develop (cryptoanarchy, privacy, transnational entities, persistent organizations, anonymous systems, digital banks). But the same technologies make it possible for a cyberspatial police state to develop. The race is on. Some on this list (sometimes me, too) say "We've already won." Duncan Frissell and Sandy Sandfort often point out just how unenforceable the existing laws are, how few people comply with the tax laws, and how the internationalization of commerce has made national borders into permeable membranes. As I like to say, in my .sig, "National borders are just speed bumps on the information highway." But there are dangers of a repressive crackdown brought on by these new technologies, or as a _result_ of them. National ID cards like the "baby blue" cards the French are preparing, could allow checkpoints at all points-of-sale terminals (gotta collect sales tax, you know), monitoring of health status, and all sorts of other "security state" (both sense of the word) accouterments. The long-rumored "ban on cash" could occur, with draconian penalties for illicit cash (tax-avoiding!) transactions...confiscation of property works well here. (Some of the very same things that the crypto enthusiasts advocate, like ATMs tied to offshore bank havens, could actually be the reason cash is banned. That is, maybe they can't stop you from accessing your Bank of Caicos account, but they sure can try to make it hard for you to spend you CaicosCredits!) Who will win? I hope we will. But even the optimists--in whose camp I place myself--must surely concede the victory will not come without effort. We Cypherpunks may be remembered by generations hence as the MinuteMen of this revolution. --Tim May, who hopes to see many of you, physically or virtually, at the Saturday meeting. .......................................................................... 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^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway." From qjones at infi.net Wed Mar 9 20:09:46 1994 From: qjones at infi.net (Wayne Q Jones) Date: Wed, 9 Mar 94 20:09:46 PST Subject: FinCen In-Reply-To: <940309145545_71431.2564_FHA66-1@CompuServe.COM> Message-ID: The "roadblocks" put up by intelligence is no surprise. Afterall what did happen to the 10 millions of the Iran-Contra drug money? What about the DEA agent who stole several hundred thousand dollars in drug money? FinCen is one way of hiding the illegal drug escapades of the intelligence community. Wayne **************************************************************************** * Qjones at infi.net So I'm a dog...what else is new? * * Qjones at larry.wyvern.com Quote from life and times of a man * **************************************************************************** From pfarrell at netcom.com Wed Mar 9 20:22:50 1994 From: pfarrell at netcom.com (Pat Farrell) Date: Wed, 9 Mar 94 20:22:50 PST Subject: Wanted Sun DIN to audio adapter Message-ID: <84352.pfarrell@netcom.com> I'm looking for someone in the DC area who can lend me a Sun audio adaptor plug for this weekend's meeting. One end has mini-DIN that plugs into the Sun, and the other has standard microphone and headphone/speaker jacks. I've got one located on the net, but that will cost FedEx money to get from and back to its owner. I'd rather spend the money on pizza and beer. Please get back to me, or Dan Brown (brown at eff.org) if you can help. Thanks. Pat Pat Farrell Grad Student pfarrell at gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include From 68954 at brahms.udel.edu Thu Mar 10 00:19:31 1994 From: 68954 at brahms.udel.edu (Grand Epopt Feotus) Date: Thu, 10 Mar 94 00:19:31 PST Subject: The Coming Police State In-Reply-To: <199403100158.RAA27863@mail.netcom.com> Message-ID: Mr. May's rant was very inspiring I must say. Got me thinking on a few ideas here. Myself bieng a rather unorganized person, I'll just present these ideas in a spontaneous order. The idea of cheap, anarchist, free, toasternets, which are under the control of those supporting anonimity, encryptian services etc. is something that interests me a great bit. A system that can provide truly secure anon-remailers, because even the sysop deletes records and doesnt read them, is promising. I myself am trying to start such a system with some of my freinds throughout the net. Here are some ideas we are kicking around. First, we would need a IP connection, preferably one that is from a rather free, or non-questioning source. We may have one set up in the future from a fellow ex-hacker(as if you can ever be a ex-hacker) turned businessman. A connection that would bewilling to stand up to some pressure from authorities is desirable, otherwise as soon as you cause a stir, you may just find that your feed is costing a bit too much, or that you just cant seem to get the feed working properly etc...use your paranoia here. So really a symp[athetic source is really desirable in this case, since we most likely will be playing in the realm of the grey-legal areas. My personal opinion is to operate such a crypto-net with a double-blind, so that we running it cannot know the true addres of the users, only enuff to bill them if so desired. This way no records could be seized, and noone can be forced to reveal user names etc.. It would protect both the usrs, and suppliers. If billing is needed, then someone would need to help set up a accounting system that relies simply on anon-numbers, and such. Also, perhaps providing very secure, well-encrypted, and veryvery private space on a system would be helpful. maybe charging for a ten meg box that is fully encrypted with the users key, that only he can acces. Not even the system operators could read the contents. Once agin this protects both parties. And if somehow the telephony bill goes thru, lets pray it doesnt, than tap-proof storage would be a hot commodity for many people, but it would raise some serious legal questions for the suppliers. Now after a few of these nets are established, we could provide various other services. I think perhaps encrypted telnets between them, or automated chaining of remailers, etc.. Perhaps a large group of such crypto-nets could have a greater impact on the surveilance, s they could provide support for one another, as well as spreading the noise around a bit more. I also think that once they are spr4ead we could work together to allow more and more people acces to local dial-ups that allow anonimity. Meaning perhaps with much work we could coat the globe with the ability for people to have a completely anon account, still billed if desired, from any site. This would be a great feat IMO, as I myself find it difficult at times to find dial-ups in places I visit, and a anon dial-up would be a greeat boon. My personal philosophy that guides my actions is that as a service provider I do not need to know the name etc.. of the user, as long as I can bill him if needed. There is no need for me to know wht he is doing, o where he is telnetting to etc. With this in mind, I hope to be able to set-up a crypto-net, or as us romantic Sci-Fi fans call them, Data-haven 8) You're eqipped with a hundred billion nueron brain, that's wired and fired, and it's a reality generating device, but you've got too do it. Free youself ----Tim Leary---- From sameer at soda.berkeley.edu Thu Mar 10 01:20:19 1994 From: sameer at soda.berkeley.edu (Sameer) Date: Thu, 10 Mar 94 01:20:19 PST Subject: REMAIL: [Finally, I hope] The easy to install cypherpunks remailer Message-ID: <199403100920.BAA11626@soda.berkeley.edu> Hopefully it will work this time. I've stripped it down a little, and i've added some flexibility. It doesn't try to compile pgp for you, or find perl. You have to do that yourself. That was where most of my problems lay previously. Now it *should* work even if you're using your .forward file-- the functionality of your .forward file should not be lost, I hope. I *sure* hope this can be an actual release this time. (It's been *way* too long. [interesting how my cypherpunk coding increases in the days before a meeting. ;-]) Here's the readme. Available in soda.berkeley.edu:/pub/cypherpunks/remailer/remail-install.tar.gz The Cypherpunks Anonymous Remailer Installation Version 1.0 Installer: Sameer Remailer: Eric Hughes & Hal Finney, with minor modifications by Sameer ----------------------------------------------------------------------------- This is the Cypherpunks Anonymous Remailer Installation Suite Version 1.0. By simply running the script "install_remail" included in the archive, you can very easily install a cypherpunks anonymous remailer service in almost any UNIX account. The anonymous remailer uses the .forward file to pipe all mail to the remailer system. If mail to the remailer account is not acted upon by the remailer software, it goes to wherever mail should go based on what the .forward file said before the remailer was installed. (Hopefully.. no guarantees.) % gunzip RemailInstall.tar.gz % mkdir install % cd install % tar xfv ../RemailInstall.tar You might have to edit the remail_install program slightly if your system's "test" does not support the -x flag.. Try the following once you've untarred the remailer: % test -x bounce If that returns an error, you have to edit the -x and replace it with a -f in the beginning of the script "install_remail": EXECTEST=-x should be changed to: EXECTEST=-f Execute the installer program: % install_remail Answer all the questions. You need a perl and a pgp binary on your system already compiled. (You don't need pgp if you don't want PGP functionality, of course.) The program self-tests, and mails me that the remailer is running, if you want it to. I will forward that notice to the cypherpunks list and the person maintaining the list of active remailers. Remember that running a remailer is a sensitive issue on the net. If you choose to run a remailer, keep in mind that some powerful net-personalities object to anonymous remailers, possibly endangering your access to the internet. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. Running "remailer_remove" *should* clear up any problems that my script might create in your account, but I will guarantee nothing. There are so many strange versions of UNIX out there.. If it doesn't work, however, please tell me and a later release of this installer will hopefully fix that problem. Later releases will hopefully also incorporate a remailer with delays, mixing, and other nice features. Stay free, Sameer sameer at soda.berkeley.edu From tcmay at netcom.com Thu Mar 10 01:40:48 1994 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 10 Mar 94 01:40:48 PST Subject: The Coming Police State In-Reply-To: Message-ID: <199403100941.BAA17639@mail.netcom.com> Grand Epopt Feotus writes: > Mr. May's rant was very inspiring I must say. Got me thinking on > a few ideas here. Myself bieng a rather unorganized person, I'll just > present these ideas in a spontaneous order. Thanks. As longtime readers of Cypherpunks will know, I used to write more such articles. It's hard to keep saying the same things, though, so many of the early members don't write as much as they used to. The upcoming special meeting was enough of a motivation to inspire a longer essay than usual these days. > The idea of cheap, anarchist, free, toasternets, which are under > the control of those supporting anonimity, encryptian services etc. is > something that interests me a great bit. A system that can provide truly > secure anon-remailers, because even the sysop deletes records and doesnt > read them, is promising. I myself am trying to start such a system with > some of my freinds throughout the net. Here are some ideas we are > kicking around. Anyone contemplating a "Mom and Pop remailer" should also think about implementing the basic features of an "ideal mix," the remailer mix scheme described by David Chaum in his 1981 "Communications of the ACM" paper. It's been discussed here many times, particularly by Hal Finney and myself, and others, in exchanges about the properties remailers (mixes) should have. I recently wrote a long article on "Remailers: The Next Generation," which you may want to reread. Of course, truly good remailers open up the operators for interesting liability issues, lacking the ability to log users and isolate problem users or recipients. Just so you're ready for this. > My personal opinion is to operate such a crypto-net with a > double-blind, so that we running it cannot know the true addres of the > users, only enuff to bill them if so desired. This way no records could Not as secure as a real mix needs to be. If you can bill them, you can trace them. Unless a form of digital postage is used, so that no billing is needed (and hence no logging, tracing). > protect both the usrs, and suppliers. If billing is needed, then someone > would need to help set up a accounting system that relies simply on > anon-numbers, and such. Well, there's the rub, isn't it? > Also, perhaps providing very secure, well-encrypted, and veryvery > private space on a system would be helpful. maybe charging for a ten meg > box that is fully encrypted with the users key, that only he can acces. The obvious question: why would Joe User want storage space on someone else's system when he could encrypt on his own system? Unless you plan to locate the storage space outside the U.S. legal jurisdiction, which is where things get interesting of course. (I know some folks who've been talking about doing this for years now.) > Not even the system operators could read the contents. Once agin this > protects both parties. And if somehow the telephony bill goes thru, lets > pray it doesnt, than tap-proof storage would be a hot commodity for many > people, but it would raise some serious legal questions for the suppliers. Which is the rationale for multi-jurisdictional sites, to preclude legal actions from succeeding. Then it's between the user and the authorities alone as to what he's doing making a connection and sending encrypted stuff (or not encrypted, if code books and/or zero knowledge approaches are used). > Now after a few of these nets are established, we could provide > various other services. I think perhaps encrypted telnets between them, > or automated chaining of remailers, etc.. Perhaps a large group of such Yes, this is the whole idea, the whole motivation for the existing web or Cyperpunks remailers. Strenght in numbers, really _big_ numbers. > My personal philosophy that guides my actions is that as a > service provider I do not need to know the name etc.. of the user, as > long as I can bill him if needed. There is no need for me to know wht he > is doing, o where he is telnetting to etc. With this in mind, I hope to > be able to set-up a crypto-net, or as us romantic Sci-Fi fans call them, > Data-haven 8) I wish you well. Some fortunes will someday be made by people who actually do provide such services. Many have talked about it, some are playing around with remailers (no insult intended--play is good), but no "commercial services" have yet appeared. Data havens, a la Sterling, or even a la BlackNet, are indeed one such market. Probably not the first, though. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway." From an57322 at anon.penet.fi Thu Mar 10 03:32:52 1994 From: an57322 at anon.penet.fi (T.A.Z.) Date: Thu, 10 Mar 94 03:32:52 PST Subject: chips... Message-ID: <9403101117.AA26246@anon.penet.fi> >> Today I ran into a situation that made me completely nausiated and >> feel like my privacy had been completely invaded... It involves a >> chip which is implanted in animals and used for identification... > >> [....] "Well, if their doing this to animals, how soon will it be >> before they implant the same sort of thing in us?" She said, "Oh, >> I hadn't thought about it like that."... > >Several years ago (like mid or early 80's if I recall), there was >just such a program for marking children. It involved implanting >a "microchip" on the surface of a tooth. > Routine implants of transponder devices into humans are not a question of if, but only of when. I predict that they will become routine before the end of the decade. First they will be voluntary, used primarily in children to facilitate identification in case of abduction, some years later they will become mandatory for all drivers, to combat the use of fake driver licenses, and soon thereafter transponders will become the primary, if not sole accepted form of ID for all business transactions. A generation from now transponders will be mandatory used not only for identification, but for routine tracking of the movements of every citizen. If you think this sounds crazy, go to Germany, where you will find a camera on every major intersection, tracking your every move. -=T.A.Z. ------------------------------------------------------------------------- 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 an57322 at anon.penet.fi Thu Mar 10 03:33:47 1994 From: an57322 at anon.penet.fi (T.A.Z.) Date: Thu, 10 Mar 94 03:33:47 PST Subject: chips... Message-ID: <9403101121.AA26621@anon.penet.fi> >> Today I ran into a situation that made me completely nausiated and >> feel like my privacy had been completely invaded... It involves a >> chip which is implanted in animals and used for identification... > >> [....] "Well, if their doing this to animals, how soon will it be >> before they implant the same sort of thing in us?" She said, "Oh, >> I hadn't thought about it like that."... > >Several years ago (like mid or early 80's if I recall), there was >just such a program for marking children. It involved implanting >a "microchip" on the surface of a tooth. > Routine implants of transponder devices into humans are not a question of if, but only of when. I predict that they will become routine before the end of the decade. First they will be voluntary, used primarily in children to facilitate identification in case of abduction, some years later they will become mandatory for all drivers, to combat the use of fake driver licenses, and soon thereafter transponders will become the primary, if not sole accepted form of ID for all business transactions. A generation from now transponders will be mandatory used not only for identification, but for routine tracking of the movements of every citizen. If you think this sounds crazy, go to Germany, where you will find a camera on every major intersection, tracking your every move. -=T.A.Z. ------------------------------------------------------------------------- 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 an57322 at anon.penet.fi Thu Mar 10 03:33:47 1994 From: an57322 at anon.penet.fi (T.A.Z.) Date: Thu, 10 Mar 94 03:33:47 PST Subject: chips... Message-ID: <9403101121.AA26683@anon.penet.fi> >> Today I ran into a situation that made me completely nausiated and >> feel like my privacy had been completely invaded... It involves a >> chip which is implanted in animals and used for identification... > >> [....] "Well, if their doing this to animals, how soon will it be >> before they implant the same sort of thing in us?" She said, "Oh, >> I hadn't thought about it like that."... > >Several years ago (like mid or early 80's if I recall), there was >just such a program for marking children. It involved implanting >a "microchip" on the surface of a tooth. > Routine implants of transponder devices into humans are not a question of if, but only of when. I predict that they will become routine before the end of the decade. First they will be voluntary, used primarily in children to facilitate identification in case of abduction, some years later they will become mandatory for all drivers, to combat the use of fake driver licenses, and soon thereafter transponders will become the primary, if not sole accepted form of ID for all business transactions. A generation from now transponders will be mandatory used not only for identification, but for routine tracking of the movements of every citizen. If you think this sounds crazy, go to Germany, where you will find a camera on every major intersection, tracking your every move. -=T.A.Z. ------------------------------------------------------------------------- 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 an57322 at anon.penet.fi Thu Mar 10 04:17:54 1994 From: an57322 at anon.penet.fi (T.A.Z.) Date: Thu, 10 Mar 94 04:17:54 PST Subject: chips... Message-ID: <9403101205.AA00832@anon.penet.fi> >> Today I ran into a situation that made me completely nausiated and >> feel like my privacy had been completely invaded... It involves a >> chip which is implanted in animals and used for identification... > >> [....] "Well, if their doing this to animals, how soon will it be >> before they implant the same sort of thing in us?" She said, "Oh, >> I hadn't thought about it like that."... > >Several years ago (like mid or early 80's if I recall), there was >just such a program for marking children. It involved implanting >a "microchip" on the surface of a tooth. > Routine implants of transponder devices into humans are not a question of if, but only of when. I predict that they will become routine before the end of the decade. First they will be voluntary, used primarily in children to facilitate identification in case of abduction, some years later they will become mandatory for all drivers, to combat the use of fake driver licenses, and soon thereafter transponders will become the primary, if not sole accepted form of ID for all business transactions. A generation from now transponders will be mandatory used not only for identification, but for routine tracking of the movements of every citizen. If you think this sounds crazy, go to Germany, where you will find a camera on every major intersection, tracking your every move. -=T.A.Z. ------------------------------------------------------------------------- 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 68954 at brahms.udel.edu Thu Mar 10 05:54:14 1994 From: 68954 at brahms.udel.edu (Grand Epopt Feotus) Date: Thu, 10 Mar 94 05:54:14 PST Subject: The Coming Police State In-Reply-To: <199403100941.BAA17639@mail.netcom.com> Message-ID: On Thu, 10 Mar 1994, Timothy C. May wrote: > Anyone contemplating a "Mom and Pop remailer" should also think about > implementing the basic features of an "ideal mix," the remailer mix > scheme described by David Chaum in his 1981 "Communications of the > ACM" paper. It's been discussed here many times, particularly by Hal > Finney and myself, and others, in exchanges about the properties > remailers (mixes) should have. I recently wrote a long article on > "Remailers: The Next Generation," which you may want to reread. > I myself am very new to the net, and also to crypto, soI have not seen these papers before. Is ther an archive where I could find them? Or could you possibly mail me a copy of your "Remailers: The Next Generation" if it is not already archived someplace I could find it. I do have a fw questions about remailers myself actually. Would I still be able to recieve mail at my account? Just how much attention does it bring? Is it feasible for a student on a conservative system(read fascist) to get away with a low profile one? I know low profile is not the goal, but I do want to help if possbile. > Of course, truly good remailers open up the operators for interesting > liability issues, lacking the ability to log users and isolate > problem users or recipients. Just so you're ready for this. > this is a concern of mine actually. I am really more worried about what would happen to fellow cypherpunks interested in this if the prototypes were quickly attacked by the law, than wether I would get in trouble or not. I myself am rooted in the U.S. as far as the forseeable future goes, so I definetly need to consider these things. What would be the legal implications of me operating a site with a physical location outside the U.S. from a site in the U.S. By telnetting to it or something? Would that system be subject to the laws of my nation, or would the be subject to the nation of there physical location. hehe, actually this may be a good idea, just to add to legal confusion for the lawyers to shovel thru if they want to get to me or the system. This way we could have a foreign IP addres, a US operator and perhaps users from various nations, rendering us a nice thick soup of legalities. > The obvious question: why would Joe User want storage space on someone > else's system when he could encrypt on his own system? Unless you plan > to locate the storage space outside the U.S. legal jurisdiction, which > is where things get interesting of course. (I know some folks who've > been talking about doing this for years now.) > Yeah it would be hairy at the least. Well one reason to allow storage space is for those who do not have a system at home, students using labs, those who only acces is on a company machine, which could easily be watched, or if encryptian becomes illegal, or heavily restricted, it would take pressure off of some people to let someone else hold the evidence so to speak. I never thought of putting it outside US jurisdiction myself, but it's a good idea, hmmm. > > Yes, this is the whole idea, the whole motivation for the existing web > or Cyperpunks remailers. Strenght in numbers, really _big_ numbers. > This reminds me of something, what is the policy towardsreposting letters here to various boards on BBSs where there may be interested people? Like would you mind if I posted your rant there? I have posted a few things from cypherpunks already, like anon-remailerinfo and how to use and set-up one, in the Undergroud Forum on ISCA, which is a very big system. I would think it is welcomed but thought I should check it out. I think that the more people you touch the more people you'll eventually have involved more deeply. > Data havens, a la Sterling, or even a la BlackNet, are indeed one such > market. Probably not the first, though. > gee, can you tell I just finished Islands In The Net 8) hehe. Amazing the power of a meme huh? You're eqipped with a hundred billion nueron brain, that's wired and fired, and it's a reality generating device, but you've got too do it. Free youself ----Tim Leary---- From dwomack at runner.utsa.edu Thu Mar 10 07:04:25 1994 From: dwomack at runner.utsa.edu (David L Womack) Date: Thu, 10 Mar 94 07:04:25 PST Subject: money... Message-ID: <9403100238.AA20964@runner.utsa.edu> I'd appreciate any opinions/info available on whether a rumor I heard is true or not. I just learned that US bills, $20 and above, have a magnetic strip embedded in the bill, on the left hand side. Looking at the front of the bill, under the "U" in United States, it's clearly visible on those bill printed in 1990 and thereafter. Supposedly, bills in the $5 and $10 amounts have started being fixed in such a way. Now...the interesting part. The rumor is that it is possible to detect, at a modest distance, the existance of and the amount of currancy being carried. Thus, if a person boarded an airplane carrying $12,000 in cash in a money belt, it would be possible to detect that fact. The rumor expands that this has in fact already been implemented at one airport (at least). Any thoughts? From 68954 at brahms.udel.edu Thu Mar 10 07:31:08 1994 From: 68954 at brahms.udel.edu (Grand Epopt Feotus) Date: Thu, 10 Mar 94 07:31:08 PST Subject: D.C. meet Message-ID: Could someone possibly be able to direct me on how to get to the EFF building from Union Station? I want to take a trin in from Wilmington and then go to the meet from there, possibly I'll have to catcha metro or something? You're eqipped with a hundred billion nueron brain, that's wired and fired, and it's a reality generating device, but you've got too do it. Free youself ----Tim Leary---- From gtoal at an-teallach.com Thu Mar 10 08:03:02 1994 From: gtoal at an-teallach.com (Graham Toal) Date: Thu, 10 Mar 94 08:03:02 PST Subject: FinCen Message-ID: <199403101602.QAA28777@an-teallach.com> From: Wayne Q Jones The "roadblocks" put up by intelligence is no surprise. Afterall what did happen to the 10 millions of the Iran-Contra drug money? What about the DEA agent who stole several hundred thousand dollars in drug money? FinCen is one way of hiding the illegal drug escapades of the intelligence community. It's precisely because of the CIA's illegal funding of covert activities (ones they can't even get a black budget for) that I posted on eff.talk, the day that Ames was uncovered, that he most likely slipped through the detection-net of overspending precisely *because* agencies like this and the CIA cooperate to hide the illegal income of top CIA agents. It's almost certain that FINCen has tweaked their algorithm specifically to bypass people like Ames. And we still haven't seen the drug connection in that case surface. But don't worry, it will. Head of anti-drugs operations for the last years? Don't kid me... So much for 'checks and balances'. G From nobody at soda.berkeley.edu Thu Mar 10 08:07:24 1994 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Thu, 10 Mar 94 08:07:24 PST Subject: magstripes in $$ Message-ID: <199403101607.IAA00526@soda.berkeley.edu> Someone worries about magnetic strips in U.S. currency... Yeah. I do too. On a slightly related topic, I know of an instance where the Secret Service located a stolen color copier with somewhat greater speed than one might have expected. Is it possible that these machines either: (1) contain transponders or (2) hide a "signature" in their output ??? From hughes at ah.com Thu Mar 10 08:30:49 1994 From: hughes at ah.com (Eric Hughes) Date: Thu, 10 Mar 94 08:30:49 PST Subject: The Coming Police State In-Reply-To: <199403100941.BAA17639@mail.netcom.com> Message-ID: <9403101623.AA19072@ah.com> >The obvious question: why would Joe User want storage space on someone >else's system when he could encrypt on his own system? Reliability in case of disk failure. Disk failure includes disk seizure. My private keys ought well to exist somewhere other than in their usual place of residence and around that physical environs. Likewise, they ought to be stored somewhere other than publically known storage locations like safe deposit boxes. And private keys are ony the first sort of sensitive data whose loss has extremely large consequences. And, as Tim points out, if the data site if offshore, so much the better. Eric From bdolan at well.sf.ca.us Thu Mar 10 08:47:27 1994 From: bdolan at well.sf.ca.us (Brad Dolan) Date: Thu, 10 Mar 94 08:47:27 PST Subject: Ames, Coke, & $$ Message-ID: <199403101647.IAA11416@well.sf.ca.us> qjones at infi.net, I agree with your opinion of Ames' income and the reason why it "wasn't noticed". [See my 2/24 post here.] The interesting question is: what did he do to make them want to bust him? From jim at bilbo.suite.com Thu Mar 10 09:18:05 1994 From: jim at bilbo.suite.com (Jim Miller) Date: Thu, 10 Mar 94 09:18:05 PST Subject: The Coming Police State Message-ID: <9403101712.AA15099@bilbo.suite.com> > - Help to convince companies _not_ to use Clipjacked > phones. Ideally, create a mood in which the use of Clipper > marks one as a stooge of Big Brother and as not having a good > work environment. (This can begin to work as potential > hires ask pointedly, for example, about the Clipper > policy of the company.) > Cypherpunks could be the keepers (and distributors) of a "piss list" of companies that use Clipper/Capstone/Tessera products. Jim_Miller at suite.com From arthurc at crl.com Thu Mar 10 09:19:12 1994 From: arthurc at crl.com (Arthur Chandler) Date: Thu, 10 Mar 94 09:19:12 PST Subject: Who Owns the Words? Message-ID: I realize that a thread similar to this one was debated on this list a month or so ago; but the problem has special urgency for me right now, and so I've made the posited situation much more specific. I'd be much obliged if anyone would post or email me their feelings, or references to legal precedents, on this issue. Many thanks. A dilemma: if you are writing a paper, and you want to quote someone's posted (say, to cypherpunks) remarks, what are the obligations? 1) None: by posting, people make their words public domain. 2) No legal obligations, but it would be polite to ask permission. 3) Whatever is posted is de facto copyright, and the person whose words you took could sue you for breach of copyright. Now let's shift to a MOO or IRC: You keep a log of a conversation. Would the same rules/customs apply if you wanted to include that log in a paper? Does it matter if the conversation was held in a private room or in a public place on the MOO? Does it matter whether the paper is written to fulfill a class assignment or is intended for publication in a for-profit magazine? From mnemonic at eff.org Thu Mar 10 09:36:05 1994 From: mnemonic at eff.org (Mike Godwin) Date: Thu, 10 Mar 94 09:36:05 PST Subject: Who Owns the Words? In-Reply-To: Message-ID: <199403101735.MAA29147@eff.org> Arthur writes: > A dilemma: if you are writing a paper, and you want to quote someone's > posted (say, to cypherpunks) remarks, what are the obligations? > 1) None: by posting, people make their words public domain. > 2) No legal obligations, but it would be polite to ask permission. > 3) Whatever is posted is de facto copyright, and the person whose > words you took could sue you for breach of copyright. (3) is closest to the truth. You can still quote someone within Fair Use guidelines, however. > Now let's shift to a MOO or IRC: > You keep a log of a conversation. Would the same rules/customs apply > if you wanted to include that log in a paper? Yes. > Does it matter if the conversation was held in a private room or in a > public place on the MOO? No. > Does it matter whether the paper is written to fulfill a class > assignment or is intended for publication in a for-profit magazine? Yes. The former poses no copyright problems. --Mike From mg5n+ at andrew.cmu.edu Thu Mar 10 10:24:07 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Thu, 10 Mar 94 10:24:07 PST Subject: The Coming Police State In-Reply-To: <199403100158.RAA27863@mail.netcom.com> Message-ID: > - New systems. I've said it before: we had some early wins with the > Cypherpunks remailers, but follow-ons have been slow in coming. We > often see a spate of good ideas--such as on digital money, or > steganography, or the like--but then these ideas don't become > "standards." This could be for a variety of reasons, so I'm not casting > stones here. But it's a phenomenon we should think about and try to > resolve. Let's find a way to get more "outposts" in cypherspace built, > deployed, and maintained. Voice PGP, as mentioned above, would be > a natural one. > > - Remailer sites in non-U.S. countries. This needs to be a higher > priority. Get a robust remailer, using PGP or ViaCrypt PGP (for > bulletproof legality reasons), in at least a dozen countries. Digital > postage will help incentivize remailer operators to get into the > business, to maintain the systems in a less-lackadaisical way (no > offense, but seeing remailers drop like flies as student accounts > expire or vanish mysteriously is not confidence-building). The > "second generation remailer" stuff needs to be incorporated at least > partly. Just to throw some statistics into the works here. I've been keeping logs of usage of my remailer and my remailer list server... (which I know is horribly uncypherpunkish- unfortunantly I've found it to be necessary. (Originally, I had no logs.) Every few days, someone will toss a screwball message into my mail filter that doesn't have the proper headers and it'll foul things up. For example, today I got a message from "xxx at cosmos". His mailer did not use the FQDN... I get a lot of other crap like that too.) But the logs provide some relevant statistics... In the last two weeks, I've had requests for the remailer list requests from: Unknown country (ie .com .org .edu), probably mostly US, but not necessarily: 77 (breakdown: .com 25 .edu 43 .org 3 .net 6) .gov: 1 (nasa, btw) .ca 9 .uk 6 .de 6 .au 3 .it 1 .se 1 .ch 1 .nl 1 .no 1 ---- Total requests: 107 The problem is not lack of interest, but lack of usage. These stats are just for the last two weeks (2/24-3/10); my software has been operational for more than a month. Probably close to 200 people have requested the info. I think it would be a fair assumption to say that most never used a remailer or just experimented with it once or twice. Probably only a small fraction actually used one of the remailers. I suppose the learning curve is just too steep for most people, or the remailers are just too much trouble, or they're just not useful enuf. Of these 107, only 16 got an anon address from my remailer. Even fewer tried using it. And although I mention where to get the software, exactly zero of my 100+ interested people have actually set up a remailer themselves. And the hacktic.nl never seems to have gotten off the ground either. (And the caltech remailer seems to be gone. :( And I'm using too many ands.:) I agree, we need more remailers outside of the US. But I think we need more than just remailers. We have remailers. We have software. We need a PLAN. From ejohnson at pmip.dist.maricopa.edu Thu Mar 10 10:26:38 1994 From: ejohnson at pmip.dist.maricopa.edu (Eric Johnson) Date: Thu, 10 Mar 94 10:26:38 PST Subject: The Coming Police State Message-ID: <199403101826.LAA08734@pmip.dist.maricopa.edu> : James Bamford has been : quoted as saying that he could fill an entire new book with the machination : of the Surveillance State. Does anyone know what James Bamford is up to these days? Any chance he will write such a book? --Eric From mnemonic at eff.org Thu Mar 10 10:34:33 1994 From: mnemonic at eff.org (Mike Godwin) Date: Thu, 10 Mar 94 10:34:33 PST Subject: D.C. meet In-Reply-To: Message-ID: <199403101834.NAA00782@eff.org> Take the Red Line from Union station to Metro Center. At Metro Center, take the exit that leads up into Woodward & Lothrop's. Enter through the W&L deli, and bear left. Take escalators up to Washington Center atrium. Bear right to doors into Washington center (if you're in the Hyatt, you didn't bear right enough). Enter the lobby (reception desk is to your left, bank of elevators is straight ahead, and hallway takes 45 degree angle to your right). Follow the hallway to your right. At its end is a second bank of elevators. Take those elevators to the ninth floor. When you get off on the ninth floor, go straight ahead past the two receptionist stations, then bear left down a white hallway until you come to a short staircase. Take the stairs down one flight. You're at EFF. --Mike > > Could someone possibly be able to direct me on how to get to the > EFF building from Union Station? I want to take a trin in from > Wilmington and then go to the meet from there, possibly I'll have to > catcha metro or something? > > > You're eqipped with a hundred billion nueron brain, that's > wired and fired, and it's a reality generating device, but > you've got too do it. Free youself ----Tim Leary---- > > > From hughes at ah.com Thu Mar 10 10:35:25 1994 From: hughes at ah.com (Eric Hughes) Date: Thu, 10 Mar 94 10:35:25 PST Subject: Who Owns the Words? In-Reply-To: <199403101735.MAA29147@eff.org> Message-ID: <9403101828.AA19507@ah.com> >> Does it matter whether the paper is written to fulfill a class >> assignment or is intended for publication in a for-profit magazine? >Yes. The former poses no copyright problems. And this brings up fair use, which seems to be mostly absent from Mike's answers. Mike, is not a short quotation considered fair use, in whatever medium, lacking any specific prohibition against it? Eric From klbarrus at owlnet.rice.edu Thu Mar 10 10:56:59 1994 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Thu, 10 Mar 94 10:56:59 PST Subject: MAIL and Coming Police State Message-ID: <9403101856.AA11959@rufous.owlnet.rice.edu> -----BEGIN PGP SIGNED MESSAGE----- > First, we would need a IP connection, preferably one that is from a > rather free, or non-questioning source [...deleted] A connection > that would bewilling to stand up to some pressure from authorities > is desirable Yeah, what you need is to run your own site, or have the explicit permission to run a remailer from whoever owns the site. For example, here on owlnet, the user policy forbids forwarding mail to a non-standard program. I mention this because I have asked and been told repeatedly by an attorney friend of mine that running a remailer on a system where you don't have authorization to do so is a violation of the ECPA. (i.e. access beyond what the system administration intends for you to have). So you definitely need sysadmin approval to withstand even the slightest pressure. So maybe I'm glad all the remailers I set up have expired ;-) As far as other properties, I've tried digital cash and time delay: One remailer I ran used digital cash (a very simple system), another batched mail and sent out once a day. I didn't keep logs so I don't know how popular these two remailers were, but I have a feeling not very popular at all. I also tried num-latency delays, but the remailer which did this wasn't able to run for very long, so I couldn't tell if it was a popular feature or not. Good luck! Karl Barrus -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLX9tIYOA7OpLWtYzAQHpvgP5AclUZUtUmJxlrC+D8XA7d2nbCDKAm3os 1gDVIBFn/KsFk2RrbFdPdhoip1Dj2AUEVk3Zfm3bqkqly5uu3PKwALz0dYZjTDhx C+hdemVNAs1ErwPS9oPKuPA82RSKfM3NqEXejR06oKwRcSO0QNkq1TFTTe8wBpSe zvxtNlYokbM= =qv05 -----END PGP SIGNATURE----- From sdw at meaddata.com Thu Mar 10 11:01:23 1994 From: sdw at meaddata.com (Stephen Williams) Date: Thu, 10 Mar 94 11:01:23 PST Subject: (forward message on privacy) In-Reply-To: <9403090351.AA01505@wps.com> Message-ID: <9403101902.AA03287@jungle.meaddata.com> > > Forwarded message: > >From tomj Tue Mar 8 18:49:17 1994 > From: tomj (Tom Jennings) > Message-Id: <9403090249.AA01170 at wps.com> > Subject: Re: (forward message on privacy) (fwd) > To: flesh at fido.wps.com (Flesh) > Date: Tue, 8 Mar 1994 18:49:15 -0800 (PST) > In-Reply-To: <9403090221.AA01084 at wps.com> from "Flesh" at Mar 8, 94 06:21:38 pm > X-Mailer: ELM [version 2.4 PL23] > Mime-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Content-Length: 897 > > > Today I ran into a situation that made me completely nausiated and feel like > > my privacy had been completely invaded... It involves a chip which is > > implanted in animals and used for identification... My first worry was whether it could be read at a distance, like doorway radar scanners in the Mall. That would impose a privacy problem on the human possibly accompanying the animal. If not (apparantly that's the case now), then I don't have a problem with it. Also, you could always remove it if needed. sdw -- Stephen D. Williams Local Internet Gateway Co.; SDW Systems 513 496-5223APager LIG dev./sales Internet: sdw at lig.net sdw at meaddata.com OO R&D Source Dist. By Horse: 2464 Rosina Dr., Miamisburg, OH 45342-6430 Comm. Consulting ICBM: 39 34N 85 15W I love it when a plan comes together From pmetzger at lehman.com Thu Mar 10 11:51:47 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Thu, 10 Mar 94 11:51:47 PST Subject: money... In-Reply-To: <9403100238.AA20964@runner.utsa.edu> Message-ID: <9403101951.AA13777@andria.lehman.com> David L Womack says: > I'd appreciate any opinions/info available > on whether a rumor I heard is true or not. > > I just learned that US bills, $20 and above, > have a magnetic strip embedded in the bill, on > the left hand side. Looking at the front of > the bill, under the "U" in United States, > it's clearly visible on those bill printed > in 1990 and thereafter. You didn't look very closely. Shine a light through the bill, and you will be able to read on the strip the words "TWENTY USA" on the strip in question. It isn't to my knowledge magnetic -- just non-xeroxable. There is also a second security feature -- look closely at the third ring around Andrew Jackson, and you will see that it is not a ring at all but microprinting reading "The United States of America". Perry From jim at bilbo.suite.com Thu Mar 10 12:18:01 1994 From: jim at bilbo.suite.com (Jim Miller) Date: Thu, 10 Mar 94 12:18:01 PST Subject: anonymous credit? Message-ID: <9403102011.AA18196@bilbo.suite.com> I'm wondering is anonymous electronic credit is possible. At first, it seemed to me to be an unlikely thing. Banks and credit companies usually want to determine if a person is a good risk, before extending them credit. If a person has a bad credit history, they have a hard time getting credit cards and loans. How could a bank determine your credit history if they don't know who you are? Assuming you did get a credit card using an anonymous id, if you abused your credit and lost the use of the credt card, you could just re-apply under a different anonymous id. There would be no continous credit history under a single identity. After thinking about this a little is now seems to me that anonymous credit is possible, but it wouldn't work like current credit cards. A few assumptions... 1) there will be more people who pay their bills than people who don't pay their bills. 2) some people will pay their bills late and be subject to fees and interest. 3) there will always be some people who try to cheat the system by getting an anonymous credit line, spending it, then disappearing. Given these assumptions, I can see anonymous electronic credit working as follows: Anyone can get an anonymous credit line. You purchase an anonymous credit line by forking over some anonymous digital cash up front. The more you fork over, the higher the initial credit line. In return for the upfront cash, you get an anonymous credit id and an credit line to accompany it. Your initial credit line will be equal to the amount of your upfront money, perhaps minus a startup fee. You can increase you credit line by paying your bills on time, thus establishing a mini-credit history with that credit company. The *rate* of increase is the important factor, which I'll get back to later. Instead of working like current credit cards, which give the credit companies a detailed record of what you purchased, where you purchased, and when, anonymous credit will work more like a generic loan. To tap your credit line, you will use your anonymous credit id to make withdraws, converting a portion of your credit line into anonymous cash using a Chaum-ian anonymous cash withdraw protocol. You can then spend the anonymous cash anywhere you like, without revealing the details of your spending habbits to the credit company. The credit company would only by able to track your withdraws and your repayments. The credit company might charge a service fee for each withdraw. They would most likely charge interest, fees for late payment, and perhaps also a yearly fee. Basically, it works much like an anonymous bank account, except you can establish a good repayment history and increase your credit line. The rate at which the credit company increases your credit line will depend upon the credit company's assement of the risks invovled in carrying anonymous credit lines. The credit company knows that you can simply disappear at any time, therefore it won't want to increase your credit line too fast. However, the higher your credit line, the more interest it can earn. Also, competition between different credit companies will affect the rate of increase. If most people repay their credit lines, the credit company will make money. If credit lines don't grow too large, too fast, the credit company will not lose too much money from cheaters. The credit company should be able to determine a rate of increase that will make them a profit. Does any of this sound reasonable? Jim_Miller at suite.com From gtoal at an-teallach.com Thu Mar 10 12:39:38 1994 From: gtoal at an-teallach.com (Graham Toal) Date: Thu, 10 Mar 94 12:39:38 PST Subject: Surveillance cameras Message-ID: <199403102025.UAA16022@an-teallach.com> "T.A.Z." wrote: :Routine implants of transponder devices into humans are not a question of :if, but only of when. I predict that they will become routine before the and wrote, and wrote, and wrote... Marc, when I said "And when you get a new account, remember to post to penet.fi instead of the list directly." I didn't mean for you to take it to heart quite so strongly and post the same thing four times! G PS London has the same degree of camera surveillance as you said Germany has. There's a big centre at Kings Cross Station where all the Railway Police have their monitors (of all the Underground entrances) and another one at New Scotland Yard where all the transport police have theirs. The ones in the underground - which are ostensibly just for mass crowd volume monitoring - have an absolutely deadly killer zoom lens that's centrally steerable. It's *way* overkill for the use it's supposed to be for... From rarachel at edison.poly.edu Thu Mar 10 13:55:49 1994 From: rarachel at edison.poly.edu (Arsen Ray Arachelian) Date: Thu, 10 Mar 94 13:55:49 PST Subject: Mac SecureDrive status report... Message-ID: <9403102155.AA27959@edison> Okay, so far I have all the information I need. The secure drive for the Mac will require the user to have a fairly optimized drive to start off with. Why? Because I've wasted way too much time trying to figure out how to work with the damn extents... I don't have any driver code written yet. The reason for this is that I'm not ready to risk loosing my hard drive until I have two full backups. :-) This is a two part project as you know. The 1st project is a freeware encryption only driver... The 2nd part is an encryption/compression driver. I've written most of the routines for the 2nd project to do the free/full space management and caches. Once I write the freeware program I will have a working driver (I hope) and will be able to implement the compressing driver. I do plan to make some money off of this and give Stacker, X2 and E-disk a bit of competition, so I figure somewhere around the $30-$50 range for the compressing/encrypting driver... I'm going to make the compressing driver have a possibly self-optimizing when idle routine, but I may decide to drop this if it takes too long... Let me know if you have any suggestions/etc. NOTE: DO NOT REPLY TO THIS MESSAGE!!! Send your replies to rarachel at photon.poly.edu. The reason for this is that there's some trouble with Photon right now, and I am using another machine to get my mail :-I Hopefully this will be fixed soon... From mnemonic at eff.org Thu Mar 10 15:01:28 1994 From: mnemonic at eff.org (Mike Godwin) Date: Thu, 10 Mar 94 15:01:28 PST Subject: Who Owns the Words? In-Reply-To: <9403101828.AA19507@ah.com> Message-ID: <199403102301.SAA08221@eff.org> Eric writes: > Mike, is not a short quotation considered fair use, in whatever > medium, lacking any specific prohibition against it? Well, in music it's problematic. In film and TV even more so. But it seems to be okay in text, in general. --Mike From jim at Tadpole.COM Thu Mar 10 17:25:56 1994 From: jim at Tadpole.COM (Jim Thompson) Date: Thu, 10 Mar 94 17:25:56 PST Subject: money... Message-ID: <9403110126.AA11598@chiba.tadpole.com> I posted this several months ago. BTW, I just noticed my first $10. I really doubt they can detect the money from a distance. If you're really carefull, you can pull the little strip out. Jim. From rarachel at photon.poly.edu Thu Mar 10 21:06:50 1994 From: rarachel at photon.poly.edu (Arsen Ray Arachelian) Date: Thu, 10 Mar 94 21:06:50 PST Subject: Clipper: Denning v Barlow Debate on AOL Message-ID: <9403110507.AA08887@photon.poly.edu> This is a captured chat from the Time Magazine, Time Odeon Online Forums. On America Online, my handle is RayDude. I unfortunately didn't get into the confrence in time to catch its begining. However as there's a transcript of every such confrence, I'll post that up as well. As I just go this immediatly after the confrence, there's no *OFFICAL* transcript posted online, however when one becomes available, I will send it here... (In the AOL "audience" you can only chat with those in your own row. All messages preceded by (6) are by those in my row. This is kind of messy, but you can still follow all the simultaneous discussions with a bit of effort.) You can send me internet mail at rarachel at photon.poly.edu if you wish, or RayDude at aol.com, however I prefer the photon machine. Barlow1 : improved traffic analysis. Content is less important than context, and most agents will Barlow1 : support this. Shuddup : (6) I really don't accept the traffic analysis argument. That's too much work! COUNTMINDO : (6) i just don't like having a product forced on me, we don't all have to buy FORD's if we want to COUNTMINDO : (6) deal with the government RPTime : Another question from the audience. JCMaille asks... Barlow1 : By the way, I'm not seeing my responses. Am I still online? Question : Does the government have a constitutional right of access to my personal communications? RPTime : Yes, John you are! RayDude : (6) RE: Traffic analysis: bet on it. It can be done and very easily over the internet as is. Kyrahn : (6) or as if gun controll has taken semi automatic guns and or automatics RayDude : (6) It will be much easier when the cable companies give you a net-feed. RPTime : Dr. Denning, why don't you go first? Barlow1 : hello? Shuddup : (6) But why bother with TA? Cost high, payoff low. Most of us are not evil! MegSaint : (6) Shuddup, since when has inefficency ever stopped the governmnt from doing something? Barlow1 : hello? DDenning : The Supreme Court ruled that wiretaps with a court order are Constitutional. Barlow1 : hello? DDenning : At one time, communications were not even protected under the RayDude : (6) To cite an example, my girlfriend went on vacation to HK. I'm not Chinese, but because I called HK, COUNTMINDO : (6) JPB is having troubles DDenning : 4th Amendment. The government could wiretap without a court order! Shuddup : (6) Right, but there;s almost always a reason - even if it is just to prove that we can... DDenning : Now a court order is required. RayDude : (6) AT&T sent me an offer to call HK for much less. This was half a year AFTER I called Hong Kong!!! Kyrahn : (6) crazy RayDude : (6) AT&T keeps track of EVERY call you make. If telephones have this much traffic analysis, PhilipED : To put the question another way, do citizens have a right to use powerful encryption? RayDude : (6) so will the info highway! Shuddup : (6) Sure, but again - why? DDenning : Right now there are no laws preventing the use of any encryption. Shuddup : (6) AT&T sells phone time. They have a reason. DDenning : Clipper is voluntary. You can still use something else. RPTime : We have to apologize. John Barlow has temporaily lost his connection... MegSaint : (6) I think we lost JPB! Shuddup : (6) BIG BROTHER! PARANOIA! RayDude : (6) No, they are REQUIRED to keep records by the FCC, another branch of the government. Kyrahn : (6) I've lost my mind :> Shuddup : (6) :-) PhilipED : Dr. Denning, in your opinion... COUNTMINDO : (6) they got him RayDude : (6) hehehe! PhilipED : would a law outlawing powerful encryption be unconstiotutional? Shuddup : (6) >:-( Kyrahn : (6) it's not paranoia when they really plan to do it Shuddup : (6) The problem is to figure out why. Never ascribe to malice what can be explained by stupidity! MegSaint : (6) Or beauracracy, which may be the same thing DDenning : I don't think so. But that doesn't mean it will happen. Shuddup : (6) Right.. COUNTMINDO : (6) they want to keep the status quo, but who's to say that that is right? PaulR42 : (6) Can Clipper break PGP2.3? RayDude : (6) Keep in mind that the NSA no longer have the Russians to spy on. So they need new targets. Us! RPTime : John Barlow is back with us. Sorry for the interruption! MegSaint : (6) Did she mean she doesn't think there will be a law or she doesn't think it will be unconst.? Shuddup : (6) Yeah, but why? What do we got? RayDude : (6) They need to be entertained, so they'll spy on everyone they can citing all sorts of rants PaulR42 : (6) Welcome back, John. COUNTMINDO : (6) hooray back from the beyond Shuddup : (6) ;-) PhilipED : Barlow, Denning just said she didn't think a law banning powerful encryption would be unconstitutional RayDude : (6) about "What if the drug dealers, terrorists, child molesters, and pornographers" get strong crypto? PhilipED : What do you say? Barlow1 : Hi folks. Don't know what happened. Gald to be back Kyrahn : (6) kinda like algebra let stupidity=Beauracracy PhilipED : Gald indeed! MegSaint : (6) Crooks already *have* strong crypto! RayDude : (6) Nope, as far as the cypherpunks can tell PGP is still strong. DES has been broken. Kyrahn : (6) multiply by x agencies PaulR42 : (6) Use the RSA scheme? Barlow1 : Actually, I believe that our current export embargoes are a violation of the 1st Amendment RayDude : (6) That's the point. Crooks already have strong crypto, but the rest of us wont if UncleSam gets his w RayDude : (6) way Barlow1 : which specifically speech without regard to the manner of speech. If we could restrict manner COUNTMINDO : (6) and the crowd began chanting CANTWELL CANTWELL CANTWELL Kyrahn : (6) I am Not a Crook Barlow1 : of speech, it would be constitutional to require that everyone speak English. Which of course it isn't MegSaint : (6) Cantwell? Explain please PaulR42 : (6) BTW, PGP is classified as munitions. RayDude : (6) Neither am I. But face it, the NSA doesn't want anyone to have strong crypto except themselves. PhilipED : John, can you make the case why ordinary law-abiding citizens need powerful encryption? Kyrahn : (6) so is any encryption program COUNTMINDO : (6) CANTWELL is the rep. who is trying to pass a bill to do away with the export law on encryption RayDude : (6) Yet, you can FTP PGP from Finland. You can import IDEA from outside the country too. Munitions indee COUNTMINDO : (6) classifying it as a munition Kyrahn : (6) importing is o.k. Barlow1 : Because it is in the nature of digitally networked communications to be quite visible. Everytime MegSaint : (6) Thanks, good informtation. Where have I been? Kyrahn : (6) just don't try to send it Barlow1 : we make any sort of transaction in a digital environment, we smear our fingerprints all over Barlow1 : Cyberspace. RayDude : (6) If you guys want, you can subscribe to the cypherpunks mailing list Kyrahn : (6) 'cause they can throw you in jail COUNTMINDO : (6) no thanks COUNTMINDO : (6) heavy traffic RayDude : (6) by sending a message to cypherpunks-requests at toad.com with subscribe in the subject and body. PaulR42 : (6) What's the address? Barlow1 : If we are to have any privacy in the future, we will need virtual "walls" made of cryptography. MegSaint : (6) RayDude, what's the address? RayDude : (6) Beware, that you'll get over 70 messages a day! Kyrahn : (6) black "ice" PaulR42 : (6) And the NSA on your tail. RayDude : (6) Do you guys know about "SecureDrive?" COUNTMINDO : (6) holy gibson batman Kyrahn : (6) nope Kyrahn : (6) flatman RPTime : Another audience question... Question : isn't like the gun argument? if guns are outlawed only criminals will have guns, well if Question : clipper is standardized, won't criminals be the ones NOT using it? RayDude : (6) SecureDrive is a DOS program that will give you an encrypted hard drive using the IDEA cypher. Very RayDude : (6) secure. RPTime : Dr. Denning? COUNTMINDO : (6) hey that's my question Kyrahn : (6) not grock dos MegSaint : (6) Wow! Kyrahn : (6) am on mac RayDude : (6) I sent about 6 questions so far.. haven't seen any yet.. must be slow.. Kyrahn : (6) patience DDenning : If Clipper becomes the de facto standard, then it will be the chief method RayDude : (6) Re: MAc Secure drive: no worries, I'm writing one for the Mac. Send me a message in two monts. MegSaint : (6) There are over a hundred people here Kyrahn : (6) cool RayDude : (6) two months... sorry PaulR42 : (6) Is it my imagination, but are the main participants fading out....? DDenning : of encryption. That would be what you'd get at Radio Shack. What criminals RayDude : (6) Cool, but very hard to write... Re: fading out, no, were just talking too fast. :-) DDenning : use will depend on what is readily available and what their cohorts are using. MegSaint : (6) Do we have better connections than the net heavies? COUNTMINDO : (6) such as PGP Kyrahn : (6) Raydude-> at AOL? RayDude : (6) As cypherpunks we are planning to give out free disks with crypto at the next PC Expo in NYC. If DDenning : Both parties of a conversation have to use the same thing. Criminals also talk to PaulR42 : (6) Cool, RayDude! RayDude : (6) any of you dudes are in NYC at the time, look us up. :-) (RayDude at aol, or rarachel at photon.poly.edu DDenning : a lot of people outside their immediate circle - e.g., to buy goods and services. Kyrahn : (6) cool DDenning : Also, they can be quite stupid at times. But the main thing is that criminals will Kyrahn : (6) you can reach me here on AOL COUNTMINDO : (6) cypherpunks mbone conference, watch for it soon DDenning : not be able to take advantage of the SKIPJACK algorithm as a way of concealing DDenning : their conversations. This is the whole point. It is not to catch criminals. It is DDenning : to allow people access to a really high quality algorithm in a way that someone COUNTMINDO : (6) what bullshit! MegSaint : (6) Countmindo, "cypherpunks *mbone* conference? I don't get it. DDenning : cannot use it to conceal criminal activity. Kyrahn : (6) it gets deeper all the time Barlow1 : The gun analogy is excellent up to a point. I can't for the life of me imagine why we would think that PaulR42 : (6) Where's the shovel? COUNTMINDO : (6) cypherpunks are putting together an mbone conference, video and audio over the net Barlow1 : even a stupid criminal would use Clipper if something else were available. And when I talk MegSaint : (6) In other words, anyone not using Clipper will be, de facto, a crook. Barlow1 : to people in the administration their big hobgoblin is the *nuclear-armed" terrorist. Any fanatic Kyrahn : (6) that's it RayDude : (6) In other words, crypto except for clipper will be illegal! Barlow1 : smart enough to assemble and detonate a nuclear device is going to be smart enough to download COUNTMINDO : (6) yeah de-facto illegal Barlow1 : PGP from a bulletin board somewhere. RayDude : (6) I wish I had a sparc station to join the mbone conf.. hope one of you will have transcripts. Kyrahn : (6) red flags for anyone not using clipp you wings PaulR42 : (6) Right on, John! Barlow1 : Also, I'd like to point out that the gun analogy doesn't go the whole distance. Crypto is by its RayDude : (6) Fuck clipper, we have to spread PGP far and wide making it tough to outlaw it. COUNTMINDO : (6) cool he kicks dennings ass off my question!! Barlow1 : nature a purely *defensive* technology. You can't shoot people with it. RayDude : (6) Yeah! Barlow!!! Go, Go, Go!!!! PhilipED : Speaking of PGP, Dr. Denning, is that encryption system secure, in your opinion? COUNTMINDO : (6) ooo good one. PaulR42 : (6) Here it is... RayDude : (6) hahahah! RayDude : (6) Lets see if the NSA cracked PGP yet!! PaulR42 : (6) she'll sidestep it. COUNTMINDO : (6) that gets my bet DDenning : I don't know of anyone who's been able to break the IDEA algorithm that it uses. RayDude : (6) Time to pull a Ronnie Reagan, for Denning... Kyrahn : (6) they are working on it COUNTMINDO : (6) oh she said it!!! RayDude : (6) Bullshit! PGP uses RSA and IDEA! RPTime : Back to the audience for a question from Steve HW.. COUNTMINDO : (6) wake up the neighbors MegSaint : (6) Wait, I thought PGP was RSA PaulR42 : (6) What's the diff? Question : This is for Dr. Denning. What is the evidence of harm if the Clipper proposal is not Question : adopted? RayDude : (6) RSA uses public/private keys meaning you can publish your key and anyone can send you a 100% RayDude : (6) private message Kyrahn : (6) the trick is to have something that mutates when someone attemps to "illegally" break it PaulR42 : (6) And IDEA? DDenning : The harm would be to the government. They would not be able to use it and would RayDude : (6) With idea, you can't spread your key. It's the only thing that protects your code. Kyrahn : (6) call it BackFire DDenning : have to resort to something less secure. Also, Clipper is part of a larger COUNTMINDO : (6) awwww poor government RayDude : (6) IDEA uses only one password. PGP gives you a public & private. Your can only read your mail DDenning : project to make hardware available for encryption and digital signatures. This RayDude : (6) if you decrypt it with your private key when someone scrambles it with your public key. MegSaint : (6) So what was Denning talking about then? RayDude : (6) Hence anyone can send you 100% private mail without knowing your secret keyword. Kyrahn : (6) RipemMac use dual components DDenning : will be used, for example, in the Defense Message System. The goverment DDenning : needs a new standard. PaulR42 : (6) OK, I get it now. Kyrahn : (6) but is still under developement :< RayDude : (6) A bit of trivia, did you guys know that our contries founding fathers were crooks? COUNTMINDO : (6) then let the government use what they want and let us use what we want Kyrahn : (6) of course! DDenning : I personally believe that making really powerful encryption like SKIPJACK available RayDude : (6) Thats right, they were sumglers, trying to evade Englands taxes. Hence for the constitution COUNTMINDO : (6) god bless 'em ;) PaulR42 : (6) Explain, RayDude, that can't possibly be true. RayDude : (6) having lots of protections against abuse! DDenning : without key escrow could be harmful to society. Wiretaps have been essential Kyrahn : (6) same thing with most "city" Fathers RayDude : (6) Too bad they didn't put in privacy protection too. :-I Shuddup : (6) Right. Cops got search warrants, I got a door lock; cops make mistakes, but I'm worried about crooks PaulR42 : (6) So even Geo. Washington said "I am not a crook?" RayDude : (6) Their idea was to have a tiny government, only to serve, not to rule. Shuddup : (6) I just want to pick my own size and cost of doorlock! DDenning : for preventing and solving many serious crimes and terrorist activities. Barlow1 : Why on earth would the government have to use something else if they failed to get the rest of Kyrahn : (6) I am Not A Crook!! RayDude : (6) It's a matter of view point. To the Brits he was a crook & traitor. To us a hero. But the Barlow1 : rest of us to buy into this folly? COUNTMINDO : (6) but she said it wasn't to stop criminals RayDude : (6) smuggling was not a publicised thing. PaulR42 : (6) One man's revolutionary is another man's freedom fighter. Barlow1 : Hey, they are already using SKIPJACK. It's a government algorithm and has been in use for a Kyrahn : (6) besides the rest of the world will not use clipper Shuddup : (6) I think she DID say that clipper was to stop illegal wiretaps, or at least that it could. DDenning : CPSR and others are asking the government to drop Clipper. Barlow1 : long time. There are plenty other algorithms which we can use which are truly protected... unless of PaulR42 : (6) And it's a good thing too, Dorothy! Kyrahn : (6) so it stands to reason that the crooks you worry about will use some exotic Shuddup : (6) Right! RayDude : (6) BTW: Over the internet we have an 80% petition rate!!! 80% of the internet opposes clipper! Barlow1 : course, this is only the first step in a process which will outlaw other forms of crypto. And I Kyrahn : (6) and over 100 major companies COUNTMINDO : (6) i signed my electro petition Barlow1 : believe that it must be. Makes absolutely no sense otherwise. MegSaint : (6) I'll be sending in my petition soon. Just got the latest CPSR Alert with the address. RayDude : (6) I put my name on Satan's list, yeah baby I did.. :-) Barlow1 : EFF is not asking the Government to drop Clipper, though we would vastly prefer they did. We're PaulR42 : (6) But most Americans have no idea what the NSA is trying to do with Clipper. And is has such a nice na PaulR42 : (6) me Barlow1 : merely asking that no steps be taken to require it either by law or practice...as, for example, would RayDude : (6) That's why I'm going to give out free disks at PCExpo... If we can raise some Barlow1 : be the case if you had to use a Clipper chip to file your tax return. RayDude : (6) eyebrows from big businesses, we can raise everyone's eyebrows eventially PhilipED : Dr. Denning, do you think this is the "first step in a process to outlaw crypto"? RayDude : (6) eventually. (sorry) COUNTMINDO : (6) no, no way, yeah that's the ticket... DDenning : No I do not. The government has not been using SKIPJACK to my knowledge. Kyrahn : (6) well I got to go/ But keep in touch! DDenning : The Clipper initiative represents the first time that the government has put PaulR42 : (6) Can a MacPGP encrypted message be decyphered by a PC user, and vice versa? Is there PGP for PCs? Kyrahn : (6) :-> MegSaint : (6) Bye Kyrahn Shuddup : (6) bye COUNTMINDO : (6) bye PaulR42 : (6) See ya! RayDude : (6) Oh, DDenning has knowledge about what the gov has been using???? RayDude : (6) Bye K. DDenning : one of their really good algorithms out there in the unclassified arena. They COUNTMINDO : (6) bet your ass she does RayDude : (6) BTW: Which of you wanted the Mac or PC Secure drive? I can send'em to you? HotRodKart : (6) Being that this my first rodeo on the E/F I wonder if this damn thing really works? MegSaint : (6) Paul, I believe the answer to bothe or your questions is "Yes" DDenning : are trying to do this in a way that won't backfire against the public. Other PaulR42 : (6) Thanks, Meg MegSaint : (6) Ray, I would be interested in the Mac Secure Drive DDenning : NSA developed algorithms are not available for purchase by the public. Barlow1 : I appreciate their willingness to make some of that COUNTMINDO : (6) more audience questions, c'mon! Barlow1 : crypto research available to a public which has paid so much for it, but I'm afraid that I would RayDude : (6) I'm here on AOL.. Just send mail to RayDude. :-) MegSaint : (6) Heck, the government developed these algorithims with OUR money! Yes John! RayDude : (6) Or if you have internet access, it'll be faster to send me mail to rarachel at photon.poly.edu Barlow1 : never trust an algorithm which was given to me by any government. And I certainly don't trust PaulR42 : (6) Is Barlow1 JPB's aol address? MegSaint : (6) Will do, RayDude. Barlow1 : a classified algorithm like Skipjack, even without PaulR42 : (6) Right on John!!!! Barlow1 : a back door which everyone can see. I think I'll stick to systems which have been properly vetted MegSaint : (6) Barlow1 may be a temporary address. Barlow1 : to be clear of such compromises, like RSA. I hope others will do likewise and that RSA will become PaulR42 : (6) uh huh Barlow1 : the standard which Clipper shouldn't be. MegSaint : (6) I find it hard to believe that Denning hangs out on AOL RPTime : Time for one more question from our audience... Question : To John Barlow. Isn't society becoming increasingly vulnerable to concerted Question : criminal/terrorist disruption, requiring *stronger* law enforcement tools? RayDude : (6) Meg, gotcha in my address book... will send a copy when it's done. Want a beta, or want to wait? COUNTMINDO : (6) holy right winger, batman PaulR42 : (6) I wonder if Denning listens to the Dead? PaulR42 : (6) Dumb question, sorry COUNTMINDO : (6) naw, funny one MegSaint : (6) I'll take beta. What's life with out a little risk? Barlow1 : Gee. I don't know. It's a scary world. However, I'm willing to take my chances with the few terrorists COUNTMINDO : (6) life without risk = disneyland RayDude : (6) booooo.... stupid question! I've sent so many good ones, why take that one? MegSaint : (6) Some might consider Barlow a terrorist Barlow1 : and drug lords there are out there rather than trusting government with the kind of almost unlimited PaulR42 : (6) I'll bet she hasn't eaten as many shrooms at Dead concerts as JPB RayDude : (6) disneyland=lawyers, lawsuits, cops, big-mickey-brother, etc... bad, bad bad! Barlow1 : surveillance power which Clipper and Digital Telephony would give them. It's a touch choice. But MegSaint : (6) So why did you send the stupid one, RayDude :) Barlow1 : when you look at the evil perpetrated by government over this century in the name of stopping crime, RayDude : (6) That wasn't mine Meg.. But I should have sent a stupid one.. them's the only ones accepted... RayDude : (6) it seems... Barlow1 : it far exceeds that done by other organized criminals. COUNTMINDO : (6) hey mine was accepted :( PhilipED : Dr. Denning, hasn't remote listening technology enhanced police abilities to eavesdrop to the point... RayDude : (6) Sorry :-) MegSaint : (6) Oops, misunderstood your comment. PhilipED : where the loss of a few wire taps won;t mean much? PaulR42 : (6) Hasn't Time Mag cooperated with the CIA and helped them obtain info in the sixties? Shuddup : (6) It wouldbe interesting to know how many questions where sent up! RayDude : (6) Sorry Count... didn't mean it like that... DDenning : No. They need to get the cooperation of the service providers to implement MegSaint : (6) Do they *have* to or are they just supposed to ? COUNTMINDO : (6) is this thing over at 10? HotRodKart : (6) TIME = LEFT RayDude : (6) More like cooperation of the service providers or the service providers will be fined $10K a day!!! DDenning : a wiretap. The loss of some wiretaps could be costly indeed. As an example, RayDude : (6) The FBI digital telephony bill requires that all networks have a spy line or they pay $10K a day! RayDude : (6) if the damn thing passes! DDenning : wiretaps were used to help solve a case that involved plans by a Chicago DDenning : gang from shooting down a commercial airliner. There have been 2 cases where COUNTMINDO : (6) Cub, White Sock, Bull? DDenning : they helped save the lives of kids who were going to be kidnaped for the making DDenning : of a snuff murder film. They helped solve a case where a man's house was going COUNTMINDO : (6) c'mon boss, who's going to use voice encryption anyways? RayDude : (6) Oh yeah, right, surrrre... good ones... PaulR42 : (6) Gag me, Dorothy. DDenning : to be bombed. I could go on. If we take John's arguments about law enforcement DDenning : to their logical conclusion, we'd just get rid of law enforcement. I think it's better RayDude : (6) Why should we as tax payers pay $10Billion a year for Clipper when only 10-15 wiretap warrants are DDenning : to have it. The people in law enforcement hate it as much as the rest of us when RayDude : (6) actually given out to law enforcement agents per year? RayDude : (6) Is $10Billion the cost of 10 or so wire taps a year???? I think not! DDenning : some member of the community does something wrong. And they correct it, RayDude : (6) It's only for spying on us! DDenning : design new procedures and laws where necessary, and go on. Barlow1 : Oh, please. I'm not proposing eliminating police. I'm opposing giving them unlimited powers. COUNTMINDO : (6) foreign countries will laugh at this Barlow1 : Also,these are the same cases cited over and over by everyone from you to Judge Freeh.Surely, we RayDude : (6) BTW: They plan on exporting clipper. What country would be stupid enough to use a chip that will le RayDude : (6) the USA spy on their private stuff? Barlow1 : aren't going to fundamentally change the balance of Barlow1 : power in this country because of these two (undocumented, to my knowledge) stories. RayDude : (6) BTW: there's talk that the recent espionage case is simply media fodder incited by the NSA so that COUNTMINDO : (6) guess it doesn't end at 10... RayDude : (6) they can say "Look, with encryption we wouldn't have been able to catch'em!" DDenning : Clipper is not going to change the balance of power. It does not give RayDude : (6) "So we need clipper and we need to ban all other encryption" RayDude : (6) Ohhh, yeah, clipper isn't going to change the balance... pure raw, grade A-bull$#it! DDenning : law enforcement any additional authority to do wiretaps. Barlow1 : Well, this is where we basically disagree, Dorothy. If we could continue the same level of LE capacity PaulR42 : (6) But it gives them the capability to do so. MegSaint : (6) Does Denning think we're all stupid? Barlow1 : we presently have, I'd have no objection. But I believe, for reasons I'm not sure we have the RayDude : (6) yes HotRodKart : (6) I cant believe she said that HELLOOOOOO any gray matter Barlow1 : bandwidth to discuss here, that we are talking about RayDude : (6) She thinks that since she has a degree in crypto that everyone else is stupid and shouldn't MegSaint : (6) I'm feeling very patronized. RayDude : (6) be allowed to think about crypto Barlow1 : dramatically enhancing their abilities. For one thing, we would greatly reduce the bureaucratic MegSaint : (6) I came with something of an open mind. She isn't helping her cause any. not with me, anyway. Barlow1 : overhead involved in wiretap, which is what keeps it under 900 cases nationwide at the present. RayDude : (6) She's good with crypto, but a real idiot when it comes to anything about the gov't. RayDude : (6) Or maybe they just pay her well... RPTime : And that will have to be the last word on the matter for tonight... DDenning : The overhead of a wiretap is more likely to increase, not decrease. RayDude : (6) booo! COUNTMINDO : (6) oh c'mon COUNTMINDO : (6) just getting fun PhilipED : Not quite! RPTime : Maybe not! ;-) RPTime : THAT will be the final word! RayDude : (6) Why didn't they throw my questions in!!! :-( I had some real Denny-friers in there... COUNTMINDO : (6) thpppppt! Barlow1 : Well, let's get together and talk, Dorothy. RayDude : (6) ;-) RPTime : TIME thanks Dr. Dorothy Denning and John Perry Barlow for being with us tonight... RayDude : (6) Oooh, he's asking her out!!! Maybe he'll ditch her at the curb.. MegSaint : (6) Myabe they decided to shut her up before she did more damange to the adminstraion position RPTime : along with Philip Elmer-DeWitt. Thank you all, and goodnight! RayDude : (6) heheh PhilipED : Thank you both. This was very interesting. RayDude : (6) Oh quit thanking DDenning : Thank you for the opportunity to be here! COUNTMINDO : (6) butt kisser PaulR42 : (6) Well, it's been nice, bye all! And write your congressperson about Clipper! RayDude : (6) each other and give some real issues a thought! MegSaint : (6) Good Night, all. It was fun sitting with you. PaulR42 : (6) Bye JPB, say hi to Jerry for me! RayDude : (6) Well folks, see you whenever... it was fun. :-) RayDude : (6) Hope some of you will join the cypherpunks if you can stand to read that much email a day... COUNTMINDO : (6) futureculture is enough for me thanks MegSaint : (6) Already on a list that nets me 60 letters a day. Don't know if I can afford the airtime DDenning : spelling errors? MegSaint : (6) What? RayDude : (6) Well at least do me a favor and give out PGP to all the folks you know who have PC's or Macs.. COUNTMINDO : (6) huh? RayDude : (6) huh??? RayDude : (6) looks like Denny slipped... MegSaint : (6) Will spread the gospel, at least as far as Kyrahn HotRodKart : (6) PGP? RayDude : (6) Pretty Good Privacy. Excellent crypto program... RayDude : (6) Let me know if you want a copy... Mac or PC... HotRodKart : (6) Thank you HotRodKart : (6) where do you get it? COUNTMINDO : (6) guess this is really over, i was hoping JPB would keep going RayDude : (6) I get off the internet... but... I guess AOL doesn't give access to that... I can mail it to you HotRodKart : (6) PC RayDude : (6) Actually Barlow hit Denning before on the internet.. that's how this got started... Barlow1 : it be too long? RayDude : (6) Hot: where do you live? If you're in NYC, I can just give you a disk... MegSaint : (6) Well, I really should go this time...(What do you suppose they're doing, still in there? HotRodKart : (6) San Diego COUNTMINDO : (6) it be too long hehehehe that's what she said RayDude : (6) Oh well. :-) Want me to mail you a disk or upload it? (It'd be way too long an upload..) HotRodKart : (6) Mail wood b ok RayDude : (6) okay, send me your address in email... HotRodKart : (6) To RayDude? RayDude : (6) Yep... to RayDude... HotRodKart : (6) I think I know how to use it I'll give it my best shot RayDude : (6) Just go up to the Mail menu and hit Compose Mail, then type in RayDude in the "To:" field. COUNTMINDO : (6) well, gone, seeya, nice talking... HotRodKart : (6) got it thanks RayDude : (6) Welp, I guess, that's it for tonight.. :-) Goodnight folks. RayDude : (6) Last words: "Die Clipper, Die, Die Die!! Die Digital Telephony Act, Die, Die, Die!!!" From boldt at math.ucsb.edu Thu Mar 10 21:15:04 1994 From: boldt at math.ucsb.edu (Axel Boldt) Date: Thu, 10 Mar 94 21:15:04 PST Subject: Improvement of remailer security Message-ID: <9403110511.AA13627@emile> I think the recent death-threat-to-Clinton desaster has made clear that the remailers we have are not very secure, mainly because incoming and outgoing mail seems to be monitored at many sites. Even the current pgp encryption scheme offered by some remailers doesn't help much, once the incoming and outgoing messages are known: just take the outgoing message from the remailer, encrypt it with the remailer's public key, compare this to the incoming messages and you know who sent this message (repeat if a chain of remailers was used). Here's a proposal which could close this hole: remailers should allow for a new header 'Encrypt-with:' which takes as argument a public pgp key. This is used just like the 'Request-Remailing-To:' header, i.e. using the '::' construct in the body of the pgp encrypted mail. ('Encrypt-with:' offers no additional security if no pgp encryption is used in the first place.) The semantics is that the remailer, just before passing the message along (and after having decrypted it, of course) encrypts the message using this public key and adds an 'Encrypted: pgp' header to it. To make sure that no remailer on the way knows the contents of the message, we should add one more mechanism: Whenever a remailer encounters a message with an 'Encrypted:' header, and the decrypted message contains another 'Encrypted:' header, the remailer decrypts it again. (Perhaps this feature exists already?) In this way, even if someone knew the contents of every incoming and outgoing mail of the remailer, they couldn't tell which incoming message produced which outgoing message. To trace a message back to its origin through a chain of remailers, one would have to know in addition all the secret keys on the way (except the first one). Axel From rperkins-remailer at nyx.cs.du.edu Thu Mar 10 21:37:23 1994 From: rperkins-remailer at nyx.cs.du.edu (rperkins-remailer at nyx.cs.du.edu) Date: Thu, 10 Mar 94 21:37:23 PST Subject: Delays & random message order? Message-ID: <9403110537.AA00413@nyx.cs.du.edu> Is it just me or is toad.com delaying messages and sending them out in random order? For example, I noticed one post dated 18:00 EST got here at 19:30 EST. The next post, however, was timestamped just before noon (with a received header confirming it was actually received by toad.com at 11:52 PST)... Two posts later there is one from 10:30 PST... My last post took nearly 10 hours to appear on the list, while other posts are getting thru almost immediately. I hope Eric hasn't been experimenting with his no-PGP-sig=delay software; it seems to be stuck in a time-warp... Now if we could only get our anonymous remailers to send messages in this fashion we'd give the NSA a real headache trying to track the messages. :) Sorry to nit-pick...(I'm sure Eric has had enough problems with the list and doesn't need any more) but I thought I was going crazy when I started seeing responses to posts that hadn't been made yet (the person had emailed the message to someone, CC: cypherpunks and the response appeared on the list before the original!) From avalon at coombs.anu.edu.au Thu Mar 10 21:42:15 1994 From: avalon at coombs.anu.edu.au (Darren Reed) Date: Thu, 10 Mar 94 21:42:15 PST Subject: Surveillance cameras In-Reply-To: <199403102025.UAA16022@an-teallach.com> Message-ID: <9403110541.AA11095@toad.com> [...] > G > PS London has the same degree of camera surveillance as you said > Germany has. There's a big centre at Kings Cross Station where > all the Railway Police have their monitors (of all the Underground > entrances) and another one at New Scotland Yard where all the > transport police have theirs. The ones in the underground - which > are ostensibly just for mass crowd volume monitoring - have an > absolutely deadly killer zoom lens that's centrally steerable. > > It's *way* overkill for the use it's supposed to be for... Do the station staff ever use them ? Here in Melbourne, all the underground railway stations have cameras pointing at escalators, up and down the platforms, etc, but if you're doing something silly like riding around on a chair that the ticket guys usually sit upon, you can expect an announcement :) There is also a window that looks into a `monitor' room from a public walkway at one. Oh, and one of the cameras looking up a platform has gum fixed to part of the cover in front of the lens :) From nates at netcom.com Thu Mar 10 21:43:45 1994 From: nates at netcom.com (Nate Sammons) Date: Thu, 10 Mar 94 21:43:45 PST Subject: The Coming Police State Message-ID: <199403110544.VAA11384@netcom10.netcom.com> I cannot help but think that having the gov looking in on us will be good. I know, get my head shrunk, but look: It gives us something to fight for. Look at me: Somewhat of a slacker who for a long while thought there was nothing worth fighting for... now there's the government to fight! What better entity to wage war against? It's the classic "valiant fight" the "good guys against the bad guys" fight. It's the kind of fight you may even feel yourself _wanting_ to fight. I can't help thinking what a kick I'll get out of seeing my kids in the future saying, upon them finding my "Cypherpunk Criminal" T-Shirt in the attic, "Gosh! Dad was a Cypherpunk! Wow!" I'm not (obviously, look at my track record) advocating the Clipper/Capstone/ blah/blah/blah standards or the new draconian legislation proposals... I'm just saying that it's easier to fight when there's something tangible to fight... it's hard now, since there are no laws keeping me from having a copy of PGP on my Mac (yet), to see what we're fighting. Maybe in a year or two there will be. Who knows. This National ID Card *really* scares me. It floods my mind with images of me standing in line to buy a CD (or whatever) and getting to the front of the line, being asked for my National ID card (So the proper taxes can be assesed, and since they cannot sell to non-citizens... blah blah blah) and me saying "Gosh... I must have left it in my other pants" or me pulling out a card with a very obvious blowtorch hole in the center (imagine little semi-toasted copper wires hangin out from behind the melted plastic case) and saying "I had a little accident" To be honest, if given the chance to get a job after I graduate (blessed be that day) that involves me moving to some non-USA (or non-Police State) location, I would be inclined to take it... fast. I have been leaning towards the "Let's overthrow the government!" crowd lately, what with reading all this shit from the FBI, etc... but it's rather pointless to want to overthrow a government as vast and powerful as our own, so I think it's best to just plot a guerilla underground haven for myself. Sorry to waste the bandwidth, but I had to get this off my chest... (Oh, and sorry for not making it to the last Colorado CPs meeting, all hell broke loose at work and I had to fix just about everything...) -nate -- +--------- | Nate Sammons PGP Key and fingerprint via finger. | Clipper == Big Brother Inside. Question Authority. Encrypt everything. +--------- From tcmay at netcom.com Thu Mar 10 22:00:40 1994 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 10 Mar 94 22:00:40 PST Subject: Clipper: Denning v Barlow Debate on AOL In-Reply-To: <9403110507.AA08887@photon.poly.edu> Message-ID: <199403110601.WAA28602@mail.netcom.com> RayDude writes: > This is a captured chat from the Time Magazine, Time Odeon Online Forums. > On America Online, my handle is RayDude. ... > Barlow1 : improved traffic analysis. Content is less important > than context, and most agents will > Barlow1 : support this. > Shuddup : (6) I really don't accept the traffic analysis > argument. That's too much work! > COUNTMINDO : (6) i just don't like having a product forced on me, > we don't all have to buy FORD's if we want to > COUNTMINDO : (6) deal with the government > RPTime : Another question from the audience. JCMaille asks... ... > PaulR42 : (6) Cool, RayDude! K00L, RayDewd! Like, I'm glad dewdz like you can , like, _follow_ this stuff. Maybe you can translate it into ordinary prose for old farts like me, who favore multi-sentence paragraphs and even reasonably thorough explications of ideas that don't fit into a single line of repartee! No insult to Arsen Ray is meant, and there may even be some nuggets in there I missed. But it sure does reinforce my hatred for "IRC" and similar fora for the attention-challenged. From what I could see scrolling by from Ms. Denning, she wasn't getting into the "dewd repartee" either, showing that we have at least one thing in common. Repartee has its place, and we all do it. But the format here is not conducive to getting views exchanged and coherent thoughts developed. What a waste. Me, I'm not as polite as Ms. Denning. About one minute into this I woulda said "Fuck this shit, I'm outta here!" --Tim May From mg5n+ at andrew.cmu.edu Thu Mar 10 22:02:24 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Thu, 10 Mar 94 22:02:24 PST Subject: Improvement of remailer security In-Reply-To: <9403110511.AA13627@emile> Message-ID: <0hU0Y5y00awMF4PmwP@andrew.cmu.edu> boldt at math.ucsb.edu (Axel Boldt): > Even the current pgp encryption scheme offered by some remailers > doesn't help much, once the incoming and outgoing messages are > known: just take the outgoing message from the remailer, encrypt > it with the remailer's public key, compare this to the incoming > messages and you know who sent this message (repeat if a chain > of remailers was used). Nope... PGP encrypts the message with a random IDEA key, and then encrypts the IDEA key with RSA. You'd have to guess which IDEA key was used, and encrypt that with RSA. The SS couldn't guess 2^128 possible IDEA keys in a hundred years, even with 10 cray supercomputers... (of course, they might be able to do it a hundred years from now... but by then nobody would care about some stupid 20th century email message.) Karl Barrus's latent-num and truncate-line features on his former tree-remailer handled all of the traffic-analysis problems rather nicely, however... > Here's a proposal which could close this hole: remailers should > allow for a new header 'Encrypt-with:' which takes as argument > a public pgp key. This is used just like the 'Request-Remailing-To:' > header, i.e. using the '::' construct in the body of the pgp encrypted > mail. ('Encrypt-with:' offers no additional security if no pgp > encryption is used in the first place.) The semantics is that the > remailer, just before passing the message along (and after having > decrypted it, of course) encrypts the message using this public key > and adds an 'Encrypted: pgp' header to it. JPP's remailer does this, except it only posts to alt.test. Maybe you could convince him to allow it to also forward to remailers when a remailer public key is specified... :) From tcmay at netcom.com Thu Mar 10 22:11:27 1994 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 10 Mar 94 22:11:27 PST Subject: Surveillance cameras In-Reply-To: <9403110541.AA11095@toad.com> Message-ID: <199403110612.WAA29822@mail.netcom.com> Darren Reed writes: > > entrances) and another one at New Scotland Yard where