From wcs at anchor.ho.att.com Tue Feb 1 00:30:29 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Tue, 1 Feb 94 00:30:29 PST Subject: 2-way anonymous via SASE Message-ID: <9402010825.AA26310@anchor.ho.att.com> Hal Finney writes: > From: "Jon 'Iain' Boone" > > So, you use a chain of anonymous-id's to set up your return-path? > > Unfortunately, return-paths are not exactly the strong point of the > current cypherpunks remailers :-). That is what much of the discussion > in this thread has discussed: how to best allow for convenient but secure > return paths. Yeah; the only solutions I've seen so far either give you some persistence, like anon.penet.fi, or no replies, or have generally been pretty ugly, requiring rapidly-increasing numbers of messages to set up chains of anonymous IDs, or use broadcast, like the Blacknet "post to Usenet" or DCnets. AIR-MAIL may be a start. It seems to need something that supports a small but >1 number of replies to make a non-ugly system, which means either some kind of Time-To-Live or destruct messages from one or both ends need to be supported. Bill From wcs at anchor.ho.att.com Tue Feb 1 00:45:25 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Tue, 1 Feb 94 00:45:25 PST Subject: PGP keyid collisions? Message-ID: <9402010844.AA26415@anchor.ho.att.com> I had discussed the benefit of putting PGP keyID or fingerprint in signatures to reduce spoofing for people who distribute by finger or unreliable keyservers, though obviously signatures are what gives you the confidence that a key is valid. Hal points out that brute-forcing a 24-bit Key-ID isn't all that hard; the usual formulas tell you what fraction of numbers are prime in the desired range, though without looking them up I'd expect it would take around 2**30 - 2**35 tries to find a specific one; I suppose this means the NSA has already done it :-) > I understand there is already at least one 24-bit collision on the > public key servers, not unexpected given a few thousand keys. I assume PGP does the right thing, except in cases of pilot error (e.g. doing key lookup by KeyID) ? Even if it does, this has some design impact on systems using random public-private key generation for meet-me remailer cutouts. Bill # Bill Stewart AT&T Global Information Systems, aka NCR Corp # 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204 # email bill.stewart at pleasantonca.ncr.com billstewart at attmail.com # ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465 From franz at cs.ucdavis.edu Tue Feb 1 00:55:25 1994 From: franz at cs.ucdavis.edu (Roy Franz) Date: Tue, 1 Feb 94 00:55:25 PST Subject: BlackNet - what is it? Message-ID: Hi, I have seen BlackNet referred to several times. Could someone say a few words about it? Thanks, Roy ----------------------------------------------------------- Roy B. Franz rbfranz at ucdavis.edu Software Engineer Viewgraphics, Inc From wcs at anchor.ho.att.com Tue Feb 1 01:20:29 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Tue, 1 Feb 94 01:20:29 PST Subject: BlackNet - what is it? Message-ID: <9402010919.AA26665@anchor.ho.att.com> Blacknet wasn't real; it was a posting Tim May anonymously posted advertising network support for various illegal services, including where to send your digicash blackmail or ransom payments and the like. Basically to try to get us to think about the implications of the technologies we're developing and potential for abuse and paranoia. On the other hand, maybe it wasn't *really* Tim May anonymously posting it, and the Tentacles of Detweiler will be posting GIFs of you and your friends talking to notorious politicians to alt.your.mother and releasing that new virus with your name on the banner page unless you help Eric start a digibank to deposit some ransom money in. :-) Bill,or someone like him From wcs at anchor.ho.att.com Tue Feb 1 02:00:29 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Tue, 1 Feb 94 02:00:29 PST Subject: 4th ammendment and Cryptography Message-ID: <9402010955.AA26853@anchor.ho.att.com> I'll second Phil Karn's recommendation of Caroline Kennedy's book, though I do remember it having somewhat of a liberal "Government is Good" bias. Unless I'm mixing it up with another book I read around the same time, it's also the one place where I've seen a recent 3rd Amendment case. The case was interesting largely because 3rd Amendment cases are very rare; the U.S. government hasn't quartered troops in people's homes except during the War Between The States, when it was ignoring the Constitution and Bill of Rights anyway. The issue was a prison guard strike, in which the National Guard was brought in to replace striking guards until the contract dispute was settled. Guards at the prison had rooms there for sleeping and off-duty use, and the National Guard, which is part of the military, used them during the strike. The guards contended that this was quartering troops in their homes. I think the government won the case rather than the prison guards, since it was really stretching the point. Phil's concerns about not freaking people out by emphasizing that the Second Amendment is designed to make overthrowing governments possible are well-placed (notwithstanding the fact that it's true.) It may be good rhetoric to use at a pro-gun meeting, though a lot of the NRA people I've met tend to get upset by the word "anarchy", but the general public just barely tolerates duck hunting and really has no desire for violent revolution, and frankly, neither do I. We're trying to go for their hearts and minds here, and issues like privacy, freedom of speech, and Big Brother tapping your phone are a lot more attractive to most people. Even the ideas that private communications can make government obsolete and that obsolete institutions can fail are pretty scary to people who've been educated in government schools, and associating crypto-privacy with the more extreme radically-correct side of the Gun Nuts will lose them - especially when there *are* legitimate concerns about use of anonymity and digicash for blackmail, ransom, and funding of real terrorists, plus the government's favorite drug dealer scare. Besides, walking around making unattributed quotations from the writings of the Founding Fathers tends to get you treated like David Koresh or at the very least Michael Milken.... Bill # Bill Stewart AT&T Global Information Solutions, aka NCR Corp # 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204 # email bill.stewart at pleasantonca.ncr.com billstewart at attmail.com # ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465 From MILKA%PLSZUS11.BITNET at SEARN.SUNET.SE Tue Feb 1 04:05:27 1994 From: MILKA%PLSZUS11.BITNET at SEARN.SUNET.SE (Doodeck) Date: Tue, 1 Feb 94 04:05:27 PST Subject: PGPkeys (ftp access) Message-ID: <9402011203.AA14567@toad.com> > Subject: PGPTools > From: m at BlueRose.com (M Carling) > I don't have ftp access here. Could some kind person please email it > to me? I don't have ftp (or Internet) access either. Try using one of BITFTP (BITnet FTP I think) services. Automated info response will be send to you upon sending mail with message body containing word "help" (without quotes) to one of the following addresses: bitftp at pucc.princeton.edu or bitftp at pucc.bitnet (located in USA) bitftp at plearn.edu.pl or bitftp at plearn.bitnet (located in Central Europe) Just before onset of twenty first century such ftp 'access' may seem ridiculous but it really works as I have transferred megabytes of data this way. Good Luck ! Doodeck. From m5 at vail.tivoli.com Tue Feb 1 06:00:34 1994 From: m5 at vail.tivoli.com (Mike McNally) Date: Tue, 1 Feb 94 06:00:34 PST Subject: Matsui-san Attack In-Reply-To: <9401312111.AA15451@atlanta.wti.com> Message-ID: <9402011356.AA06070@vail.tivoli.com> Huh? Two years of breathing space? I don't think so. Networks of many fast workstations (snakes, SPARC-10's, Alphas, whatever) aren't exactly rare; I'm sure I could equal that mflop horsepower here, and I'm double sure I could have done it while at DEC. I frequently ran a home-grown distributed fractal image generator at DEC harnessing 75 workstations, about 20 of them Alphas. The real question is whether this new attack is bogus. -- | 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 dmandl at lehman.com Tue Feb 1 06:45:28 1994 From: dmandl at lehman.com (David Mandl) Date: Tue, 1 Feb 94 06:45:28 PST Subject: Cypherpunk article in NY Newsday Message-ID: <9402011442.AA09401@disvnm2.lehman.com> There's a decent cypherpunk piece in today's New York Newsday. It was written by Joshua Quittner, who apparently attended the most recent meeting out in CA. It's more or less the usual, very upbeat and supportive, with some quotes from Eric H. and remarks on digibanking basics, Clipper, etc. --Dave. From boone at psc.edu Tue Feb 1 07:10:34 1994 From: boone at psc.edu (Jon 'Iain' Boone) Date: Tue, 1 Feb 94 07:10:34 PST Subject: 2-way anonymous via SASE In-Reply-To: <199402010131.RAA05280@jobe.shell.portal.com> Message-ID: <9402011510.AA03122@igi.psc.edu> Hal writes: > > From: "Jon 'Iain' Boone" > > > What if you have a remailer that only assigns you an id for that message > > so that your id is equivalent to (say) the Message-ID (or some portion > > thereof)? How do you return-path without specifying? > > Your syntax is a bit hard to follow here, but I'm guessing that you are > proposing such a remailer as a way of providing for return paths. The > remailer would remember the message-id's of outgoing messages, and would > remember where those messages came from. Then if a reply came back for > one of those message-id's it could send it to that remembered address. > > There were some proposals along these lines made last year, or maybe back > in 1992. This scheme doesn't seem to generalize well to multi-remailer > paths. Also, I think people would be nervous about having remailers keep > this kind of out-to-in mapping information. I think that I am confused. Please bear with me. Jim Miller writes: > > The general idea is that each anonymous messages will include a SASE that > can be used to reply to the sender, without revealing the identity of the > sender to the message recipient. To reply, the recipient will copy the > SASE from the original message and past it into a special section of the > reply message. Remailers will examine this section of the reply message > and use its contents to route the message back to the sender of the > original message. Now, what is this SASE? Apparently it is either a) a fully-specified return-path (presumably a chain of anonymous ids at various remailers), b) a next-hop address (anonymousid at the next remailer that "knows" where to send the message), or c) some combination of the previous two. Is there another possibility that I have missed? Let's assume that the SASE is of type-a. Let's assume three remailers (and my accounts on them) named: anon1+ at foo.bar.edu anon2+ at biff.bam.com anon3+ at fred.barney.org Then, if I want to anonymously send mail to you ( ) , I need to specifiy your address as normal, but specifiy some optional header (X-Anonymous-Sender-Path) like this: which says to my mailer that, while the ultimate destination is , it should first mail it to the X-Anonymous-Sender-Path address. HOST: fred.barney.org Account: anon3+ This anon3+ at fred.barney.org account will accept the mail (it accepts anything like anon3+*@fred.barney.org, so it doesn't matter about the stuff in quotes) It then strips off the anon3+ at fred.barney.org section, and re-writes the X-Anonymous-Sender-Path to read like this: It would then instantiate another optional header (X-Anonymous-Return-Path) like this: It would change the Sender: header to say "Anonymous User 3" or whatever it would normally say, and mail it to biff.bam.com. HOST: biff.bam.com Account: anon2+ This account accepts the mail and re-writes the headers like this: X-A-S-P: X-A-R-P: Sender: "Anonymous User 2"@biff.bam.com and mails the mail to anon1+ at foo.bar.edu HOST: foo.bar.edu Account: anon1+ This account accepts the mail and re-writes the headers like this: X-A-R-P: Sender: "Anonymous User 1"@foo.bar.edu Notice that it leaves off the X-Anonymous-Sender-Path: header since it is empty. It then mails it to hfinney at shell.portal.com. You receive the mail and read the message. Now, the sender indicates that it is from "Anonymous User 1"@foo.bar.edu, but the X-A-R-P: indicates that it is really from anon3+ at fred.barney.org! So, as long as fred.barney.org can be trusted, no one can tell who I am, right? And, except for anon3, none of the others needs to be my account! This requires changing the mail agent on my end, though, and possibly yours. Replying follows the same sort of path, except in reverse. Of course, you could also allow for a Return-Path header which was not re-writeable, to force a seperate path to get back to me. And, you can also change the software so that I initially send to hfinney%shell.portal.com at fred.barney.org, which would *not* require any rewriting of mail-agent software. Is this at all coherent? If the return-path is type B, I don't see how you can avoid having the ID-mapping which makes the overall scheme weaker. I don't have a good handle of the type c. > I understand there is already at least one 24-bit collision on the > public key servers, not unexpected given a few thousand keys. Hmm... I'm not sure I followed all of the math, but how's this for a signature? Jon Boone | PSC Networking | boone at psc.edu | (412) 268-6959 PGP Public Key fingerprint = 23 59 EC 91 47 A6 E3 92 9E A8 96 6A D9 27 C9 6C From f_griffith at ccsvax.sfasu.edu Tue Feb 1 07:15:28 1994 From: f_griffith at ccsvax.sfasu.edu (Reynolds Griffith) Date: Tue, 1 Feb 94 07:15:28 PST Subject: Privacy As Roadkill Message-ID: <9402011513.AA16876@toad.com> >Date: Mon, 31 Jan 1994 12:37:12 -0800 (PST) >From: Dave Wren >Subject: Privacy As Roadkill >To: "libernet at Dartmouth.edu" >Errors-To: owner-libernet at Dartmouth.EDU >Sender: owner-libernet at Dartmouth.EDU >Reply-To: libernet at Dartmouth.EDU >Precedence: bulk >X-Mailing-List: libernet at Dartmouth.EDU > > >---------- Forwarded message ---------- >Date: Sun, 30 Jan 1994 21:00:50 -0800 >From: "Brock N. Meeks" >To: com-priv at psi.com >Subject: Privacy As Roadkill > > > >Jacking in from a "Private No More" Port: > >Washington, DC -- If privacy isn't already the first victim of >roadkill along the information superhighway, then it's about to be. > >A law enforcement panel addressing the Administration's Information >Infrastructure Task Force Working Group on Privacy told a public >meeting here last week that it wanted to "front load" the National >Information Infrastructure with trap door technologies that would >allow them to easy access to digital conversations; eavesdropping >on any conversation or capturing electronic communications >midstream. > >But only for "the bad guys." Us honest, hard working, law abiding >citizens have nothing to fear from these law enforcement agencies >selling out our privacy rights to make their jobs easier. Nope, we >can rest easy, knowing that child pornographers, drug traffickers >and organized crime families will be sufficiently thwarted by law >enforcement's proposed built-in gadgetry for the national >information infrastructure. > >There's just a small problem: Law enforcement agencies, any law >enforcement agency, has yet to prove it needs all these proposed >digital trap doors. In fact, according to a U.S. Assistant >Attorney appearing on the panel, "Right now most law enforcement >personnel don't have any idea what the NII is." > >Gore Gives Go Ahead >=================== > >Panel members, representing the Justice Dept., FBI and U.S. >Attorney's office, said that they took Vice President Gore's >promise that the White House would work to ensure that the NII >would "help law enforcement agencies thwart criminals and >terrorists who might use advanced telecommunications to commit >crimes," as tacit approval of their proposals to push for digital >wiretap access and government mandated encryption policies. > >Gore buried those remarks deep in a speech he made in Los Angeles >earlier this month when the Administration first fleshed out how it >planned to rewrite the rules for communications in a newer, perhaps >more enlightened age. Those remarks went unnoticed by the >mainstream press. But readers here were forewarned. > >Fuck Ross Perot's NAFTA-induced "giant sucking sound." That >"thump" you just heard was Law Enforcement running over the privacy >rights of the American public on its way to the information >superhighway. The real crime is that the collision barely dented >the damn fender. > >This cunning and calculated move by law enforcement to install >interception technologies all along the information superhighway >was blithely referred to as "proactive" law enforcement policy by >Assistant U.S. Attorney, Northern Dist. of California Kent Walker. >Designing these technologies into future networks, which include >all telephone systems, would ensure that law enforcement >organizations "have the same capabilities that we all enjoy right >now," Walker said. > >With today's wiretap operations, the Feds must get a court to >approve their request, but only after supplying enough evidence >warrant one. But Walker seemed to be lobbying for the opposite. >Giving the Feds the ability to listen in first and give >justification later was "no big difference," he said. Besides, "it >would save time and money." > >It's Us vs. Them >================= > >For Walker privacy issues weighed against law enforcement needs are >black and white, or rather "good guys" vs. "bad guys." For >example, he said the rapid rise of private (read: non-government >controlled) encryption technologies didn't mean law enforcement >would have to work harder. On the contrary, "it only means we'll >catch less criminals," he said. > >But if law enforcement is merely concerned with the task of "just >putting the bad guys in jail," as James Settle, head of the FBI's >National Computer Crime Squad states, then why are we seeing an >unprecedented move by government intelligence agencies into areas >they have historically shied from? Because law enforcement >agencies know their window of opportunity for asserting their >influence is right now, right at the time the government is about >to take on a fundamental shift in how it deals privacy issues >within the networks that make up the NII, says David Sobel, general >counsel for Computer Professionals for Social Responsibility >(CPSR), who also spoke as a panel member. > >"Because of law enforcement's concerns (regarding digital >technologies), we're seeing an unprecedented involvement by federal >security agencies in the domestic law enforcement activities," >Sobel said. > >Sobel dropped-kicked this chilling fact from behind the closed >doors of the Clinton Administration into the IITF's lap: For the >first time in history, the National Security Agency (NSA) "is now >deeply involved in the design of the public telecommunications >network." > >Go ahead. Read it again. > >Sobel backs up his claims with hundreds of pages of previously >classified memos and reports obtained under the Freedom of >Information Act. The involvement of the NSA in the design of our >telephone networks is, Sobel believes, a violation of federal >statutes. > >Sobel's also concerned that the public might soon be looking down >the throat of a classified telecommunications standard being >created. Another move he calls "unprecedented," is that if the >NSA, FBI and other law enforcement organizations have their way, >the design of the national telecommunications network will end up >classified and withheld from the public. > >Sobel is dead bang on target with his warnings. > >The telecommunications industry and FBI have set up an ad hoc >working group to see if a technical fix for digital wiretapping can >be found to make the Bureau happy. That way, legislation doesn't >need to be passed that might mandate such FBI access and stick the >Baby Bells with eating the full cost of reengineering their >networks. > >This joint group was formed during a March 26, 1992 meeting at >FBI's Quantico, Va., facilities, according previously classified >FBI documents released under Freedom of Information Act. The group >was only formalized late last year, working under the auspices of >the Alliance for Telecommunications Industry Solutions (ATIS). The >joint industry-FBI group operates under the innocuous sounding name >of the Electronic Communications Service Provider Committee >(ECSPC). > >The ECSPC meets monthly with intent of seeking a technological >"solution" to the FBI's request for putting a trap door into >digital switches that would allow them easy access to those >conversations. To date, no industry solution has been found for the >digital wiretap problem, according to Kenneth Raymond, a Nynex >telephone company engineer, who is the industry co-chairman of the >group. > >Oh, there's also a small, but nagging problem: The FBI hasn't >provided a concrete basis that such solutions are needed, Raymond >said. CPSR's Sobel raised these same points during the panel >discussion. > >The telecommunications industry is focused on "trying to evaluate >just what is the nature of the [digital access] problem and how we >can best solve it in some reasonable way that is consistent with >cost and demand," Raymond said. One solution might be to write >digital wiretap access into future switch specifications, he said. > >If and when the industry does find that solution, do you think the >FBI will put out a press release to tell us about it? "I doubt it >very much," said FBI agent Barry Smith with the Bureau's >Congressional Affairs office. "It will be done quietly, with no >media fanfare." > >Is it just me or are these headlights getting REALLY close? > >The FBI's Settle is also adamant about trap door specifications >being written into any blue prints for the National Information >Infrastructure. But there's a catch. Settle calls these "security >measures," because they'll give his office a better chance at >"catching bad guys." He wants all networks "to be required to >install some kind of standard for security." And who's writing >those standards? You guessed it: The NSA with input from the FBI >and other assorted spook agencies. > >Settle defends these standards saying that the "best we have going >for us is that the criminal element hasn't yet figured out how to >use this stuff [encryption and networks in general]. When they do, >we'll be in trouble. We want to stay ahead of the curve." > >In the meantime, his division has to hustle. The FBI currently has >only 25 "net literate" personnel, Settle admitted. "Most of these >were recruited 2 years ago," he said. Most have computer science >degrees and were systems administrators at time, he said. > >You think that's funny? Hell, the Net is a still small community, >relatively speaking. One of your friends is probably an FBI Net >Snitch, working for Settle. Don't laugh. > >Don't Look Now, Your Privacy Is Showing >======================================= > >The law enforcement establishment doesn't think you really know >what you expect when it comes to privacy. > >U.S. Attorney Walker says: "If you ask the public, 'Is privacy >more important than catching criminals?' They'll tell you, 'No.'" > >(Write him with your own thoughts, won't you?) > >Because of views like Walker's, the Electronic Communications >Privacy Act (ECPA) "needs to be broader," said Mike Godwin, legal >services counsel, for Electronic Frontier Foundation, speaking as >a panel member. The ECPA protects transmitted data, but it also >needs to protect stored data, he said. "A person's expectation of >privacy doesn't end when they store something on a hard disk." > >But Walker brushed Godwin aside saying, "It's easy to get caught up >in the rhetoric that privacy is the end all be all." > >Do you have an expectation of privacy for things you store on your >hard disk, in your own home? Walker says that idea is up for >debate: "Part of this working group is to establish what is a >reasonable expectation of privacy." > >That's right. Toss everything you know or thought you knew about >privacy out the fucking window, as you cruise down the fast lane of >the information superhighway. Why? Because for people like >Walker, those guardians of justice, "There has to be a balance >between privacy needs and law enforcement needs to catch >criminals," he says. > >Balance, yes. Total abrogation of my rights? Fat chance. > > >Meeks out... > > > > > > From jazz at hal.com Tue Feb 1 07:35:28 1994 From: jazz at hal.com (Jason Zions) Date: Tue, 1 Feb 94 07:35:28 PST Subject: Archiving mail-lists... Message-ID: <9402011530.AA13741@jazz.hal.com> I would be interested in a discussion on the mail-list on this issue. Please refrain from sending personal mail. In particular do you think such a archive without every members permission is un-ethical? Unethical, hell; illegal is closer to it. I retain the copyright to everything I post; although implicit permission to redistribute to the mailing list is granted when I send to cypherpunks at toad.com, I have granted no permission to anyone else to use my intellectual property (i.e. my posts, valuable or not) for any other purpose. Would a archivist necessarily need the permission of the mail-list sponser? In an actively-moderated group (i.e. where the moderator chooses which messages to forward, constructs digests, etc.) the moderator possesses a copyright on the collection of material (but not on the material itself); if you were republishing a substantial part of the collection (in your case, all of it) you'd need rights to the collection copyright also. Study copyright law (including the Berne Convention, to which most nations having Usenet sites are signatories). Understand what you're getting yourself into. Jason From frissell at panix.com Tue Feb 1 07:55:27 1994 From: frissell at panix.com (Duncan Frissell) Date: Tue, 1 Feb 94 07:55:27 PST Subject: 4th ammendment and C Message-ID: <199402011550.AA14431@panix.com> W >it's also the one place where I've seen a recent 3rd Amendment case. The Third Amendment. Answer to the question "What Amendment of the Bill of Rights *doesn't* the US Government violate thousands of times a day?" W >but the general public just barely tolerates duck hunting and W >really has no desire for violent revolution, and frankly, neither do W >I. Not violent revolution. Just an alternative source of authority or defense. A reality check on tyranny. A badge of sovereignty. You can't be sovereign without weapons. W >We're trying to go for their hearts and minds here, and issues like W >privacy, freedom of speech, and Big Brother tapping your phone W >are a lot more attractive to most people. The whole point of this list is that we can achieve a technological fix for the "problems of human interaction." We can free ourselves and others without changing anyone's mind. That changes of ideology can follow new technologies and the social institutions they spawn. W >Even the ideas that private communications can make government obsolete W >and that obsolete institutions can fail are pretty scary to people W >who've been educated in government schools, and associating W >crypto-privacy with the more extreme radically-correct side of the Gun W >Nuts will lose them. Then the bulk of the population has a lot of frights coming and we are providing a public service by letting them confront their fears early in the game. What we are doing is predicting not advocating. If social changes increase people's personal liberties, their liberties are increased whether we point them out or not. In any case, our sort of analysis is creeping into the straight business press (particularly Forbes) and when C. Wright Wriston (former Citibank CEO) writes a book like "The Twilight of Sovereignty" how off the wall can we be? W >especially when there *are* legitimate concerns about use of W >anonymity and digicash for blackmail, ransom, and funding of real W >terrorists, plus the government's favorite drug dealer scare. These people could use existing techniques but mostly don't. Can you *believe* the WTC bombers getting their dough by an open wire transfer from the BRD? W >Besides, walking around making unattributed quotations from the W >writings of the Founding Fathers tends to get you treated like W >David Koresh or at the very least Michael Milken.... I don't remember Mike quoting the Founding Parents. His only mistake was copping a plea. DCF Western Civilization didn't invent tyranny, slavery, racism, or the oppression of women. What it did do is eliminate those evils (to the extent they have been eliminated). The rest of the world should be damn grateful and if they're not we should return them to the ancient tyrannies from which we so recently rescued them. Would serve them right. --- WinQwk 2.0b#1165 From jazz at hal.com Tue Feb 1 08:05:27 1994 From: jazz at hal.com (Jason Zions) Date: Tue, 1 Feb 94 08:05:27 PST Subject: archiving on inet Message-ID: <9402011601.AA13762@jazz.hal.com> So if I sell (at a profit) a netnews feed to subscribers via modem, it is not copyright infringement, but if I sell the same data on a CDROM, you cliam copyright infringement. Yep. When you're providing a netnews feed, you're acting as a node in a store-and-forward network. A CD-ROM is not a part of a store-and-forward network; it is a permanently fixed repository of information. You can't hold up a netnews feed in a courtroom and point at it saying "there it is"; you *can* do so with a CD-ROM. So I suppose you want to give some kind of list of what types of media are acceptable for transmitting netnews feeds, and which are not? A CD-ROM isn't a medium for transmitting netnews feeds; it's a permanently fixed copy of the contents of such a feed. Static versus dynamic; permanent, ephemeral. Is this hard to understand? The plain and simple fact is: When you post a message to usenet, you do so with the expectation that others will receive it. You can have no way of knowing or limiting who may get it; that is given by the nature of the network. Usenet news is, and is intended to be, publicly accessable information. If there is something you don't want distributed, then DON'T POST IT! Learn a little about law; while you're at it, learn a little about usenet. When you post a message to usenet, you have tossed it into a flood-routed store-and-forward network. You implicitly give permission for copying appropriate to the propagation of messages in that network. You neither grant permission nor withhold permission for Fair Use. Everything else, though, is not granted unless explicitly granted. If I post a message, under the terms of the Berne Convention and current US copyright law, a recipient was not granted the right to print a copy and publish it in a book. What makes you think I granted them permission to publish a copy in a CD-ROM? The only permission I granted was that they could (a) read it and (b) forward it via usenet protocols. Jason From hfinney at shell.portal.com Tue Feb 1 08:10:34 1994 From: hfinney at shell.portal.com (Hal) Date: Tue, 1 Feb 94 08:10:34 PST Subject: PGP keyid collisions? Message-ID: <199402011607.IAA22359@jobe.shell.portal.com> From: wcs at anchor.ho.att.com (bill.stewart at pleasantonca.ncr.com +1-510-484-6204) > Hal points out that brute-forcing a 24-bit Key-ID isn't all that hard; > the usual formulas tell you what fraction of numbers are prime in the > desired range, though without looking them up I'd expect it would take > around 2**30 - 2**35 tries to find a specific one; I suppose this > means the NSA has already done it :-) Right, but the point is that you have to search for a prime q anyway; PGP's algorithm is basically to repeat q += 2 until you find a q which is prime. It uses a sieve to speed this up a lot. I was pointing out that you can basically change the 2 to a 2^24, still use a sieve, and find a key just about as fast. So matching an existing key ID should not take much if any longer than just generating a PGP key in the first place. > > I understand there is already at least one 24-bit collision on the > > public key servers, not unexpected given a few thousand keys. > > I assume PGP does the right thing, except in cases of pilot error > (e.g. doing key lookup by KeyID) ? Even if it does, this has > some design impact on systems using random public-private key generation > for meet-me remailer cutouts. > Bill PGP actually uses a 64-bit key ID internally, only displaying the lower 24 bits for conciseness. It would be practically impossible to get a 64-bit key ID collision by accident (well, almost impossible, anyway). However, the technique I mentioned could easily generate such collisions. PGP does check for the case of matching key ID and does something, but I forget what. 24-bit key ID matches shouldn't have any effect except for, as Bill says, extracting/deleting keys based on key ID. Hal From wex at media.mit.edu Tue Feb 1 08:45:27 1994 From: wex at media.mit.edu (Alan (Miburi-san) Wexelblat) Date: Tue, 1 Feb 94 08:45:27 PST Subject: Archiving mail-lists... In-Reply-To: <9402011530.AA13741@jazz.hal.com> Message-ID: <9402011645.AA04676@media.mit.edu> Ah, the old I'm-not-a-lawyer-but-I-play-one-on-the-net. Problem with Jason Zions' position: - Not at all clear that Berne applies to electronic mail, even of a personal nature - Not at all clear that postings to a publicly-read list like this are not equivalent to speech in a public place (ie not necessarily copyrighted) - Not at all clear what the status of private communications is vis a vis publication. The courts in the US seem to be flip-flopping all over the place in a couple of recent cases involving correspondence used to write biographies (one of L Ron Hubbard sticks in my mind and I forget who the other was about). You can't just wave your hand and say the magic word "Berne" and thereby prevent someone from archiving, reposting etc your messages to this list. --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 an53607 at anon.penet.fi All the world's a stage and most of us are desperately unrehearsed. From mnemonic at eff.org Tue Feb 1 09:05:27 1994 From: mnemonic at eff.org (Mike Godwin) Date: Tue, 1 Feb 94 09:05:27 PST Subject: Archiving mail-lists... In-Reply-To: <9402011645.AA04676@media.mit.edu> Message-ID: <199402011701.MAA08013@eff.org> Alan Wexelblat writesK > Ah, the old I'm-not-a-lawyer-but-I-play-one-on-the-net. > > Problem with Jason Zions' position: > - Not at all clear that Berne applies to electronic mail, even of a > personal nature Hey, it's clear to me. > - Not at all clear that postings to a publicly-read list like this > are not equivalent to speech in a public place (ie not necessarily > copyrighted) That's not the measure of copyright. It's whether the expression has been instantiated in a tangible medium. > - Not at all clear what the status of private communications is vis > a vis publication. The courts in the US seem to be flip-flopping all over > the place in a couple of recent cases involving correspondence used to write > biographies (one of L Ron Hubbard sticks in my mind and I forget who the > other was about). They flipflop because of the trickiness of Fair Use--there's no hard-and-fast rule as to what qualifies. > You can't just wave your hand and say the magic word "Berne" and thereby > prevent someone from archiving, reposting etc your messages to this list. True, but you can say "Berne" and settle the issue of copyright. --Mike From jazz at hal.com Tue Feb 1 09:05:34 1994 From: jazz at hal.com (Jason Zions) Date: Tue, 1 Feb 94 09:05:34 PST Subject: Archiving mail-lists... In-Reply-To: <9402011645.AA04676@media.mit.edu> Message-ID: <9402011704.AA13796@jazz.hal.com> Alan - - Not at all clear that Berne applies to electronic mail, even of a personal nature Copyright exists from the moment the work is set down in concrete form. Are you arguing that email is not concrete? - Not at all clear that postings to a publicly-read list like this are not equivalent to speech in a public place (ie not necessarily copyrighted) Ah. The old "if the NFL has to remind us that its broadcast of the superbowl is copyrighted, so do you" argument. Okay, let's try this on for size. Copyright 1994 Jason Zions. Permission to copy and transmit for the purpose of propagation of the Cypherpunks mailing list in email or local-newsgroup (usenet) forms is granted; all other rights are reserved. - Not at all clear what the status of private communications is vis a vis publication. But this isn't private communication. You can't just wave your hand and say the magic word "Berne" and thereby prevent someone from archiving, reposting etc your messages to this list. Law is a complex thing, isn't it. I'd better go back and reread the code and current decisions. I'm spending more of my time tracking the CompuServe MIDI copyright actions, though. Jason From kshep at netcom.com Tue Feb 1 09:10:34 1994 From: kshep at netcom.com (Kirk Sheppard) Date: Tue, 1 Feb 94 09:10:34 PST Subject: archiving on inet In-Reply-To: <9402011601.AA13762@jazz.hal.com> Message-ID: Dear Jason, I don't think you are neccissarily correct about making an archive of the usenet. You may be correct, but I don't believe this point has been litigated yet. Furthermore, just because something is forwarded and something is archived I don't believe is expressly covered in copyright law. Others could argue that postings by their very nature, when posted become "public domain", and thus not copyrightable. I practice law, but am not a copyright/trademark specialist. Also, as was posted earlier someone is already making an archive of the usenet. See earlier postings. Finally what is the tangible difference between storing usenet postings on a hard disk for an indefinite time, or on a cd-rom, or a cd that is re-writable, or tape or any other storage device? Not very much I would argue. Kirk Sheppard kshep at netcom.com P. O. Box 30911 "It is Better to Die on Your Feet Than to Bethesda, MD 20824-0911 Live On Your Knees." U.S.A. - Emiliano Zapata On Tue, 1 Feb 1994, Jason Zions wrote: > So if I sell (at a profit) a netnews feed to subscribers via modem, it > is not copyright infringement, but if I sell the same data on a CDROM, > you cliam copyright infringement. > > Yep. When you're providing a netnews feed, you're acting as a node in a > store-and-forward network. A CD-ROM is not a part of a store-and-forward > network; it is a permanently fixed repository of information. You can't hold > up a netnews feed in a courtroom and point at it saying "there it is"; you > *can* do so with a CD-ROM. > > So I suppose you want to give some > kind of list of what types of media are acceptable for transmitting > netnews feeds, and which are not? > > A CD-ROM isn't a medium for transmitting netnews feeds; it's a permanently > fixed copy of the contents of such a feed. Static versus dynamic; permanent, > ephemeral. Is this hard to understand? > > The plain and simple fact is: When you post a message to usenet, you do > so with the expectation that others will receive it. You can have no > way of knowing or limiting who may get it; that is given by the nature > of the network. Usenet news is, and is intended to be, publicly > accessable information. If there is something you don't want > distributed, then DON'T POST IT! > > Learn a little about law; while you're at it, learn a little about usenet. > When you post a message to usenet, you have tossed it into a flood-routed > store-and-forward network. You implicitly give permission for copying > appropriate to the propagation of messages in that network. You neither > grant permission nor withhold permission for Fair Use. Everything else, > though, is not granted unless explicitly granted. > > If I post a message, under the terms of the Berne Convention and current US > copyright law, a recipient was not granted the right to print a copy and > publish it in a book. What makes you think I granted them permission to > publish a copy in a CD-ROM? The only permission I granted was that they > could (a) read it and (b) forward it via usenet protocols. > > Jason > From wex at media.mit.edu Tue Feb 1 09:35:27 1994 From: wex at media.mit.edu (Alan (Miburi-san) Wexelblat) Date: Tue, 1 Feb 94 09:35:27 PST Subject: Archiving mail-lists... In-Reply-To: <9402011704.AA13796@jazz.hal.com> Message-ID: <9402011731.AA09417@media.mit.edu> > Are you arguing that email is not concrete? Ayup. If it was, we wouldn't need digital signatures on clear-text msgs, no? Mike Godwin says it's clear to him; I'd say that he represents a vanguard of progressive thinkers applying the law to new areas. I'd also bet that vanguard is about a 10% minority at the moment. --Alan From ravage at wixer.bga.com Tue Feb 1 09:40:35 1994 From: ravage at wixer.bga.com (Jim choate) Date: Tue, 1 Feb 94 09:40:35 PST Subject: Archiving mail-lists... In-Reply-To: <9402011530.AA13741@jazz.hal.com> Message-ID: <9402011727.AA04285@wixer> > > > I would be interested in a discussion on the mail-list on this > issue. Please refrain from sending personal mail. In particular do you > think such a archive without every members permission is un-ethical? > > Unethical, hell; illegal is closer to it. I retain the copyright to > everything I post; although implicit permission to redistribute to the > mailing list is granted when I send to cypherpunks at toad.com, I have granted > no permission to anyone else to use my intellectual property (i.e. my posts, > valuable or not) for any other purpose. > > Would a archivist necessarily need the permission of the mail-list > sponser? > > In an actively-moderated group (i.e. where the moderator chooses which > messages to forward, constructs digests, etc.) the moderator possesses a > copyright on the collection of material (but not on the material itself); if > you were republishing a substantial part of the collection (in your case, > all of it) you'd need rights to the collection copyright also. > > Study copyright law (including the Berne Convention, to which most nations > having Usenet sites are signatories). Understand what you're getting > yourself into. > > Jason > It is no more illegal (at the present time) for me to store your posting to every usenet or inet service that I have access to on my hard-drive or a CD- Rom for re-sale than it is for you to store my posting on your drive or print it out to the printer. When I got my account I did not sign any kind of agreement relating to me retaining my rights to any material I chose to place on the net for dissimenation to others. There IS an implied motivation to put that material in the public domain so that others may use it for the betterment of all. If you are serious about your view then please forward a money order for $1000 dollars for having my original post stored on whatever medium you used to reply to it. There is no legal precedence at this time that would necessarily and automaticaly copyright every entry I (or you) made, Berne not withstanding, to inet or usenet. If that position is valid then each and every one of us is commiting copyright infringement for storing the material on a hard drive. When discussing copyright there is no involvment in medium of transmission other than what the original author limits it to prior to release of that material. The motivation for bringing this topic up is that it provides a perfect way to make the commen wide-spread usage of encryption a commen and everyday occurance. Namely, authors who wish to retain all rights should do one of two things. They should either encrypt the file and require potential users to contact the author or distributor for keys to unlock it or else it should be mandator for a author to put some sort of fair-use statement in their releases that specificly delineates what the fair-use of that material is. Users of usenet/inet do not read minds and can't necessarily imply what the original motivation was, this means (to me anyway) that the responsibility of enlightening potential users falls solely on the shoulders of the author. From jazz at hal.com Tue Feb 1 09:45:28 1994 From: jazz at hal.com (Jason Zions) Date: Tue, 1 Feb 94 09:45:28 PST Subject: Archiving mail-lists... In-Reply-To: <9402011731.AA09417@media.mit.edu> Message-ID: <9402011742.AA00212@jazz.hal.com> >> Are you arguing that email is not concrete? > >Ayup. If it was, we wouldn't need digital signatures on clear-text msgs, >no? Not the point; "concrete" does not mean immutable. If it did, then things written in pencil, or eraseable ink, or created in mutable media (videotape, audio tape, ...) would not be copyrightable either. Jason From pdn at dwroll.dw.att.com Tue Feb 1 09:50:35 1994 From: pdn at dwroll.dw.att.com (Philippe Nave) Date: Tue, 1 Feb 94 09:50:35 PST Subject: Matsui-san Attack In-Reply-To: <9401312111.AA15451@atlanta.wti.com> Message-ID: <9402011745.AA19697@toad.com> -----BEGIN PGP SIGNED MESSAGE----- buckley at wti.com writes : > > [continuing thread on ease of cracking DES/PEM] > > Using a comparable breaker on the average machine, it is going > to take two years to "break the scheme". > That leaves two years to create stronger/tighter strategies. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Concerns about the validity about the 'two years' figure aside, does this really 'leave you two years?' The technology to store messages (even ones currently uncrackable) has been online for years already- unless your encrypted data is such that you don't mind having it examined by anybody with a DES cracker, you are already at risk. In terms of careers, legal action, and politics, a two-year event horizon is negligible. As advances in computer power continue, the 'two-year' figure will continue to shrink. Taking the long view, I view the PEM/DES debate as virtually identical to the Clipper debate; Clipper's 'trap door' mindset is more overt, but getting everbody involved in PEM/DES when the cracking technology is clearly in sight is no better. - -- ........................................................................ Philippe D. Nave, Jr. | The person who does not use message encryption pdn at dwroll.dw.att.com | will soon be at the mercy of those who DO... Denver, Colorado USA | PGP public key: by arrangement. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLU6UHwvlW1K2YdE1AQGG4gQAqM+LthMCzEo3T2O+fLhKih8uNYUoHhvK 6zvDWjW2PW/t/N7TdWpA2oJ2dVmpABa3ENeNvju0qrEW91CVoU5JwBMHiCxSTrOn wtK4fcQ7m+GBvvoLO6WW5tr+FZcVluzZbJrIcnaLQVWqP/P5Bmfjspd/GfROAduX /oR4u9pFSvk= =O5HV -----END PGP SIGNATURE----- From jazz at hal.com Tue Feb 1 09:55:27 1994 From: jazz at hal.com (Jason Zions) Date: Tue, 1 Feb 94 09:55:27 PST Subject: archiving on inet In-Reply-To: Message-ID: <9402011752.AA00225@jazz.hal.com> > Furthermore, just because something is forwarded and something is archived >I don't believe is expressly covered in copyright law. It's not the forwarding or the archiving that makes anything covered by copyright law; it is the setting down, in concrete form, the expression of an idea. > Others could argue that postings by their very nature, when posted >become "public domain", and thus not copyrightable. Not successfully in court, I should think. How is a posting any different than the production of a radio program which is distributed by store-and-forward satellite distribution and then played through the radio station and received at your home radio? The mechanisms are close to identical in their attributes; tapes at the stations have some lifetime, timeshifting can occur, special equipment is needed to perceive the work, etc. >Finally what is the tangible difference between storing usenet postings >on a hard disk for an indefinite time, or on a cd-rom, or a cd that is >re-writable, or tape or any other storage device? Not very much I would >argue. If you were a ligitimate recipient of the work in the first place (i.e. got it in a newsfeed) and you store those postings for your own use or for the use of others on that node in the store-and-forward network, then you can keep the work 'til the bits rot. Infringement occurs when you copy those bits onto some medium for some purpose other than store-and-forward propagation or the allowed fair-use exceptions; stuffing articles on a CD-ROM and selling them falls into neither category and hence is an infringement. Jason From ravage at wixer.bga.com Tue Feb 1 10:00:34 1994 From: ravage at wixer.bga.com (Jim choate) Date: Tue, 1 Feb 94 10:00:34 PST Subject: Archiving mail-lists... In-Reply-To: <9402011704.AA13796@jazz.hal.com> Message-ID: <9402011744.AA06092@wixer> > > Alan - > > - Not at all clear that Berne applies to electronic mail, even of a > personal nature > > Copyright exists from the moment the work is set down in concrete form. Are > you arguing that email is not concrete? > > - Not at all clear that postings to a publicly-read list like this > are not equivalent to speech in a public place (ie not necessarily > copyrighted) > > Ah. The old "if the NFL has to remind us that its broadcast of the superbowl > is copyrighted, so do you" argument. > > Okay, let's try this on for size. > > Copyright 1994 Jason Zions. Permission to copy and transmit for the purpose > of propagation of the Cypherpunks mailing list in email or local-newsgroup > (usenet) forms is granted; all other rights are reserved. > > - Not at all clear what the status of private communications is vis > a vis publication. > > But this isn't private communication. > > You can't just wave your hand and say the magic word "Berne" and thereby > prevent someone from archiving, reposting etc your messages to this list. > > Law is a complex thing, isn't it. I'd better go back and reread the code and > current decisions. I'm spending more of my time tracking the CompuServe MIDI > copyright actions, though. > > Jason > I have to admit that I have broken your fair use copyright notice inadvertantly. I have stored an image of your message in the ram on my system which is not a part of inet or usenet nor involved in any way with the transmission to other nodes of such stored material. Berne works great for paper, audio recordings, movies, etc. It does not work for networked information transmission. From ravage at wixer.bga.com Tue Feb 1 10:00:36 1994 From: ravage at wixer.bga.com (Jim choate) Date: Tue, 1 Feb 94 10:00:36 PST Subject: archiving on inet In-Reply-To: <9402011734.AA00188@jazz.hal.com> Message-ID: <9402011745.AA06230@wixer> > > Jim - > > >Where is this agreement that it is ok to distribute material through a 'stor e- > >and-forward' network stated in the copyright law? I would be very interested > >in the proviso that exempts such networks from liability. > > It's not embedded in the law; as I said, it's an implicit permission I grant > when I post a message to such a network. Just as, when you buy a program on > a floppy disk, you are implicitly granted the right to copy it from the disk > into your computer's memory in order to run it: the nature of the work > requires that specific type of copying. There's nothing new there. > > >The bottem line is that when I got my feed I was not asked to sign any kinjd > >of waiver releasing any material that I generate from copyright infringement > >as long as it was on a hard drive (or any other media). I did not sign any > >kind of contract at all as a matter of fact. Legaly I still retain my right > >of copyright on every bit on every drive (whether magnetic or otherwise) in > >the internet and even your personal drive if you transfer the mail and other > >material to it for offline processing. > > One more time. The nature of the work and your chosen distribution medium > (netnews) requires a variety of copying for it to work: store-and-forward > for propagation, copying into the memory of my system and onto my screen so > I can read it. You grant permission to do that implicitly when you make the > work available by that mechanism. > > Once I have received the copy you have implicitly authorized me to have, > what I can *do* with that copy is governed by the Copyright Act and its fair > use exemptions. I can use it for purposes of scholarship (i.e. I can keep it > in an online or paper folder and refer to it later) and I can excerpt pieces > for critique, among other things. What I *cannot* do is redistribute it by > any other mechanisms and for any purpose other than your initial netnews > distribution. > > I have spent a lot of time studying this part of the law. Really. I already > heeded my glib advice about reading the damn copyright act. Have you? > > Jason > when I buy a software program the copyright notice specificaly states that I am allowed to make copies for backup purposes. Some of them notices on high- dollar packages even tell me how many I can keep and whether I can keep them on a network or not. From jimn8 at netcom.com Tue Feb 1 10:05:28 1994 From: jimn8 at netcom.com (Jim Nitchals) Date: Tue, 1 Feb 94 10:05:28 PST Subject: archiving on inet In-Reply-To: Message-ID: <199402011803.KAA11756@mail.netcom.com> Kirk writes, > > Dear Jason, > > I don't think you are neccissarily correct about making an archive of the > usenet. You may be correct, but I don't believe this point has been > litigated yet. Furthermore, just because something is forwarded and > something is archived I don't believe is expressly covered in copyright > law. Others could argue that postings by their very nature, when posted > become "public domain", and thus not copyrightable. I practice law, but > am not a copyright/trademark specialist. Also, as was posted earlier > someone is already making an archive of the usenet. See earlier postings. > Finally what is the tangible difference between storing usenet postings > on a hard disk for an indefinite time, or on a cd-rom, or a cd that is > re-writable, or tape or any other storage device? Not very much I would > argue. Let me argue against Usenet archiving on a different point. Archiving violates the poster's implicit right to cancel or provide an expiration date for his posting. Do Usenet archivers provide a revised CD-ROM with the cancelled posts removed on a regular basis, and ensure the original disks are returned? Without such a guarantee, the owners of those messages aren't able to exercise reasonable control over the messages. There's a clear harm done when a cancel message isn't honored in this situation: a potential employer may see a message written in anger or the author was in an exceptionally bad state of mind, yet the author (responsibly) sent out a cancel message just after the CD-ROM happened to be pressed. A second-hand copy of such an incriminating message is hearsay, and should rightfully be considered with suspicion by a potential employer, but a Usenet CD-ROM carries considerably more weight. I'm not a lawyer, but it *seems* to me that when you publish a message from a set of newsgroups containing a 'control' group that allows retraction of messages, you're agreeing to honor those retractions when they're issued by the original poster. If that's not obvious enough, when a message contains an expiration date, the author CLEARLY has a reasonable expectation of having it honored. I'd go further and say there's a strongly implied agreement that says, "if you want to use and republish this information, you must honor my expiration date." Most of us have special words for someone who refuses to honor such an implied agreement, even if it's made void by the message being considered "in the public domain." > > Kirk Sheppard > > kshep at netcom.com > From jazz at hal.com Tue Feb 1 10:10:36 1994 From: jazz at hal.com (Jason Zions) Date: Tue, 1 Feb 94 10:10:36 PST Subject: Archiving mail-lists... In-Reply-To: <9402011727.AA04285@wixer> Message-ID: <9402011809.AA00254@jazz.hal.com> >If you are serious about your view then please forward a money order for >$1000 dollars for having my original post stored on whatever medium you used >to reply to it. Sigh. One more time. The courts have recognized that permission to make copies which are essential for the perception of the work is implicitly granted by the copyright owner when the work is distributed. In order to perceive your copyrighted works my system *must* make a copy or three to get it to me (as would intervening systems if we both lived on uucp links instead of internet). This is relatively old ground that was plowed by computer cases; the exact issue of having to load a copy of a program into ram in order to execute it has indeed been the subject of litigation. The quote from your message I include above falls under the Fair Use exceptions, under both Scholarship and Criticism. >There is no legal precedence at this time that would necessarily and >automaticaly copyright every entry I (or you) made, Berne not withstanding, >to inet or usenet. [...] When discussing copyright there is no involvment in >medium of transmission other than what the original author limits it to >prior to release of that material. But this is *precisely* what the current law says. From the moment the work exists in concrete form, and a posting *is* concrete form, copyright exists. Usenet and Internet are merely distribution mechanisms, the use of which may cause the copyright holder to implicitly grant certain rights (as described above). >From another message: >when I buy a software program the copyright notice specificaly states that I >am allowed to make copies for backup purposes. Some of them notices on high- >dollar packages even tell me how many I can keep and whether I can keep them >on a network or not. Yep. Backups are separate from implicit rights granted due to the medium of expression; I'm not sure what this has to do with anything, except that there is a recognized right for you to make a backup of your usenet news archives. But you can't distribute that backup. >From yet another message: >I have to admit that I have broken your fair use copyright notice >inadvertantly. > >I have stored an image of your message in the ram on my system which is not a >part of inet or usenet nor involved in any way with the transmission to other >nodes of such stored material. You can't perceive the work without loading it into some device that can turn electrical signals into something perceivable by a human; ram on a computer is as good as anything else. As I stated above, this has been covered by case law; it's a copy necessary to the perception of the work. (The identical case arises with CDs - the bits are copied into a buffer in your CD-player before they're fed through the D/A converters. This copy is necessary to perceiving the work and hence permission is implicitly granted.) Jason From kshep at netcom.com Tue Feb 1 10:20:35 1994 From: kshep at netcom.com (Kirk Sheppard) Date: Tue, 1 Feb 94 10:20:35 PST Subject: archiving on inet In-Reply-To: <9402011752.AA00225@jazz.hal.com> Message-ID: Usenet copyrightable? I still doubt it. Of course, the only way to find out is to file a very expensive lawsuit. Most posters would not find their postings worth the expense to sue on copyright. Only a very rich dilletante, or someone less rich who is a fanatic on the subject is likely to do so. Also, you would have a hard time answering the difference between charging for a usenet feed and charging for a cd-rom, again I see little difference except that one is more prompt in time than the other. But, again, my newsfeed from a BBS which might be 24 hrs delayed, and my netcom account which is much faster and a cd-rom differs only as to time removed from the original posting. Kirk Sheppard kshep at netcom.com P. O. Box 30911 "It is Better to Die on Your Feet Than to Bethesda, MD 20824-0911 Live On Your Knees." U.S.A. - Emiliano Zapata On Tue, 1 Feb 1994, Jason Zions wrote: > > > Furthermore, just because something is forwarded and something is archived > >I don't believe is expressly covered in copyright law. > > It's not the forwarding or the archiving that makes anything covered by > copyright law; it is the setting down, in concrete form, the expression of > an idea. > > > Others could argue that postings by their very nature, when posted > >become "public domain", and thus not copyrightable. > > Not successfully in court, I should think. How is a posting any different > than the production of a radio program which is distributed by > store-and-forward satellite distribution and then played through the radio > station and received at your home radio? The mechanisms are close to > identical in their attributes; tapes at the stations have some lifetime, > timeshifting can occur, special equipment is needed to perceive the work, > etc. > > >Finally what is the tangible difference between storing usenet postings > >on a hard disk for an indefinite time, or on a cd-rom, or a cd that is > >re-writable, or tape or any other storage device? Not very much I would > >argue. > > If you were a ligitimate recipient of the work in the first place (i.e. got > it in a newsfeed) and you store those postings for your own use or for the > use of others on that node in the store-and-forward network, then you can > keep the work 'til the bits rot. Infringement occurs when you copy those > bits onto some medium for some purpose other than store-and-forward > propagation or the allowed fair-use exceptions; stuffing articles on a > CD-ROM and selling them falls into neither category and hence is an > infringement. > > Jason > From lefty at apple.com Tue Feb 1 10:45:27 1994 From: lefty at apple.com (Lefty) Date: Tue, 1 Feb 94 10:45:27 PST Subject: archiving on inet Message-ID: <9402011838.AA12820@federal-excess.apple.com> Kirk Sheppard asks > >Finally what is the tangible difference between storing usenet postings >on a hard disk for an indefinite time, or on a cd-rom, or a cd that is >re-writable, or tape or any other storage device? Not very much I would >argue. I don't believe that _storage_ is the issue at all. If I purchase a copy of a book, I don't believe that I'm violating copyright by making an archival copy of it _for_ _my_ _own_ _use_. If I start distributing or selling copies to other people, however, that's a different matter. -- Lefty (lefty at apple.com) C:.M:.C:., D:.O:.D:. From m5 at vail.tivoli.com Tue Feb 1 11:00:37 1994 From: m5 at vail.tivoli.com (Mike McNally) Date: Tue, 1 Feb 94 11:00:37 PST Subject: archiving on inet In-Reply-To: <199402011803.KAA11756@mail.netcom.com> Message-ID: <9402011857.AA07465@vail.tivoli.com> Jim Nitchals writes: > Let me argue against Usenet archiving on a different point. Archiving > violates the poster's implicit right to cancel or provide an expiration > date for his posting. "Implicit right to cancel"? Where'd that come from? > a potential employer may see a message written in anger or > the author was in an exceptionally bad state of mind... There's a poem by Carl Sandburg with some relevance to this. I don't see why the feature of cancel messages (which aren't guaranteed to work anyway) carries with it a new right. > I'm not a lawyer, but it *seems* to me that when you publish a message > from a set of newsgroups containing a 'control' group that allows > retraction of messages, you're agreeing to honor those retractions when > they're issued by the original poster. I am perfectly free to implement my own news system and mailer that does not honor cancel messages. What authority would force me to do so if I don't want to? > when a message contains an expiration date, the author CLEARLY has a > reasonable expectation of having it honored. Why? Does he have an equally clear right to expect that the message does not get deleted before then? > I'd go further and say > there's a strongly implied agreement that says, "if you want to use > and republish this information, you must honor my expiration date." This seems pretty specious to me. -- | 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 mnemonic at eff.org Tue Feb 1 11:10:37 1994 From: mnemonic at eff.org (Mike Godwin) Date: Tue, 1 Feb 94 11:10:37 PST Subject: archiving on inet In-Reply-To: Message-ID: <199402011902.OAA09623@eff.org> Kirk Sheppard writes: > Usenet copyrightable? I still doubt it. You shouldn't. Usenet postings are copyrighted the moment they are instantiated in a tangible medium. --Mike From cknight at crl.com Tue Feb 1 11:15:29 1994 From: cknight at crl.com (Chris Knight) Date: Tue, 1 Feb 94 11:15:29 PST Subject: archiving on inet In-Reply-To: Message-ID: On Tue, 1 Feb 1994, Kirk Sheppard wrote: > law. Others could argue that postings by their very nature, when posted > become "public domain", and thus not copyrightable. I practice law, but If I use your logic, a published article in a magazine becomes public domain because it has become available to a large number of subscribers. > Finally what is the tangible difference between storing usenet postings > on a hard disk for an indefinite time, or on a cd-rom, or a cd that is > re-writable, or tape or any other storage device? Not very much I would > argue. Tangible difference... Lets see... A CD-ROM can be duplicated and sold for profit, and doing so with net archives violates the copyrights of any message author who cares to file class action or personal... Who did you say had that archive, and were they selling it? -ck From cknight at crl.com Tue Feb 1 11:25:29 1994 From: cknight at crl.com (Chris Knight) Date: Tue, 1 Feb 94 11:25:29 PST Subject: Archiving mail-lists... In-Reply-To: <9402011727.AA04285@wixer> Message-ID: On Tue, 1 Feb 1994, Jim choate wrote: > It is no more illegal (at the present time) for me to store your posting to > every usenet or inet service that I have access to on my hard-drive or a CD- > Rom for re-sale than it is for you to store my posting on your drive or print > it out to the printer. I think the question of storage goes beyond copyright law. I have yet to find someone who lost a suit for owning a copy of a magazine. But since you feel the way you do about CDs, why don't you scan in a couple of issues of Life magazine, master it, and try to sell it? Do they supply Inet feeds in prison? > > When I got my account I did not sign any kind of agreement relating to me > retaining my rights to any material I chose to place on the net for > dissimenation to others. Have you ever published an article in say a not-for profit journal? Just because you don't sine a contract guaranteeing your rights DOES NOT mean you have given them up! There IS an implied motivation to put that material > If you are serious about your view then please forward a money order for > $1000 dollars for having my original post stored on whatever medium you used > to reply to it. Now that you have set your rate, I set mine. Please remit your check of $10,000.... I think this is getting a bit carried away. Copyright cases generally relate to the sale or use of material belonging to an author. As I said above, I have never heard of a case where someone lost a suit for posessing a 1942 issue of Life magazine. -ck The material in this message composed by me, lines NOT preceeded by the ">", is expressly copyrighted as the posession of Chris Knight. You may reply to this message, forward this message, and store it for PRIVATE use. Any attempt to sell this material either alone, or as part of an archive will be met by me, at you backdoor, late at night, with a chaninsaw. I have the DOOM cheats! I am invincible! ;> p.s. The above bit of humor is copyrighted 1994, cmk. From cknight at crl.com Tue Feb 1 11:30:37 1994 From: cknight at crl.com (Chris Knight) Date: Tue, 1 Feb 94 11:30:37 PST Subject: Archiving mail-lists... In-Reply-To: <9402011744.AA06092@wixer> Message-ID: On Tue, 1 Feb 1994, Jim choate wrote: > I have to admit that I have broken your fair use copyright notice > inadvertantly. > > I have stored an image of your message in the ram on my system which is not a > part of inet or usenet nor involved in any way with the transmission to other > nodes of such stored material. Are you claiming to have sold your RAM, while still powered, for a profit? Knowing that it contained copyrighted work? Shame on you. > Berne works great for paper, audio recordings, movies, etc. It does not work > for networked information transmission. I'm sorry, I didn not realize I was talking to a supreme court justice. Had I known you had the ultimate authority on this subject, I would not have been wasting your time, or mine. Perhaps we should try this. You sell archives of the net, and we'll file a class action suit... I'll back up my beliefs with actions, how about you? -ck From kshep at netcom.com Tue Feb 1 11:30:39 1994 From: kshep at netcom.com (Kirk Sheppard) Date: Tue, 1 Feb 94 11:30:39 PST Subject: archiving on inet In-Reply-To: Message-ID: Regarding the archive I believe it was some company in Canada, I'm not sure. There was a thread about this archiving question on another group I suppose in the last three weeks. I can't remember where I saw it, if it wasn't here. Sorry. And about "paying" for the cd-rom, I pay for the usenet feed, and none of us who post are getting royalty payments from any of the internet providers. So answer the question again, what is the difference in paying an internet provider for access to usenet, and paying a cd-rom provider for access to usenet? None materially, except that the cd is not interactive, and some providers are (not all as in bbs' that don't send e-mail to the internet, but have some usenet groups.) There is no material difference that I can determine. Kirk Sheppard kshep at netcom.com P. O. Box 30911 "It is Better to Die on Your Feet Than to Bethesda, MD 20824-0911 Live On Your Knees." U.S.A. - Emiliano Zapata On Tue, 1 Feb 1994, Chris Knight wrote: > > > On Tue, 1 Feb 1994, Kirk Sheppard wrote: > > > law. Others could argue that postings by their very nature, when posted > > become "public domain", and thus not copyrightable. I practice law, but > > If I use your logic, a published article in a magazine becomes public domain > because it has become available to a large number of subscribers. > > > > Finally what is the tangible difference between storing usenet postings > > on a hard disk for an indefinite time, or on a cd-rom, or a cd that is > > re-writable, or tape or any other storage device? Not very much I would > > argue. > > Tangible difference... Lets see... A CD-ROM can be duplicated and sold > for profit, and doing so with net archives violates the copyrights of any > message author who cares to file class action or personal... Who did you > say had that archive, and were they selling it? > > -ck > > > From kshep at netcom.com Tue Feb 1 11:35:36 1994 From: kshep at netcom.com (Kirk Sheppard) Date: Tue, 1 Feb 94 11:35:36 PST Subject: archiving on inet In-Reply-To: <9402011838.AA12820@federal-excess.apple.com> Message-ID: This book analogy is not accurate. It is my contention that usenet postings are not copyrighted. Our postings are not disseminated like a book, we are paid nothing for the use of our postings on the multitude of machines that our postings appear. Or, in the alternative, if copyrighted, by posting them in the electronic ether, we give up most of our rights regarding dissemination, copying etc. Perhaps we may still have some residual rights regarding accuracy and the like. Also the posting regarding the legal blurbs on software, really was off point, since what they they were refering to was a "license", and again there is some doubt about how enforceable the individual licenses that the software companies give. That is, some of these licenses may have provisions that are not enforceable. Kirk Sheppard kshep at netcom.com P. O. Box 30911 "It is Better to Die on Your Feet Than to Bethesda, MD 20824-0911 Live On Your Knees." U.S.A. - Emiliano Zapata On Tue, 1 Feb 1994, Lefty wrote: > Kirk Sheppard asks > > > >Finally what is the tangible difference between storing usenet postings > >on a hard disk for an indefinite time, or on a cd-rom, or a cd that is > >re-writable, or tape or any other storage device? Not very much I would > >argue. > > I don't believe that _storage_ is the issue at all. If I purchase a copy > of a book, I don't believe that I'm violating copyright by making an > archival copy of it _for_ _my_ _own_ _use_. > > If I start distributing or selling copies to other people, however, that's > a different matter. > > -- > Lefty (lefty at apple.com) > C:.M:.C:., D:.O:.D:. > > > From lefty at apple.com Tue Feb 1 11:45:27 1994 From: lefty at apple.com (Lefty) Date: Tue, 1 Feb 94 11:45:27 PST Subject: archiving on inet Message-ID: <9402011948.AB17603@federal-excess.apple.com> >Usenet copyrightable? I still doubt it. Of course, the only way to >find out is to file a very expensive lawsuit. Most posters would not find >their postings worth the expense to sue on copyright. Only a very rich >dilletante, or someone less rich who is a fanatic on the subject is >likely to do so. Also, you would have a hard time answering the >difference between charging for a usenet feed and charging for a cd-rom, >again I see little difference except that one is more prompt in time than >the other. But, again, my newsfeed from a BBS which might be 24 hrs >delayed, and my netcom account which is much faster and a cd-rom differs >only as to time removed from the original posting. So, would you argue, on the same grounds, that you didn't believe that a movie delivered into your home via a cable feed could be copyrighted? How about a movie on a laser disk? Do you understand that there's is a difference between personal use, which does not infringe copyright, and redistribution, which does? Are you _sure_ you're an attorney? -- Lefty (lefty at apple.com) C:.M:.C:., D:.O:.D:. From dwomack at runner.utsa.edu Tue Feb 1 11:50:36 1994 From: dwomack at runner.utsa.edu (David L Womack) Date: Tue, 1 Feb 94 11:50:36 PST Subject: PGP Message-ID: <9402011949.AA18718@runner.utsa.edu> I was wondering if anyone has an answer to a question on PGP.... About how many calculations does it take to crack a 1024 bit key? If someone has limitless time, money, etc., they can break it...but how many calculations does it take? Also, there is a password used to protect the keyrings. Assuming a strong password how many calculations does that take to break? If there isn't some special method, an assumption that leads nowhere, just how much "brute force" effort is really required? Thanks, Dave From cknight at crl.com Tue Feb 1 11:55:28 1994 From: cknight at crl.com (Chris Knight) Date: Tue, 1 Feb 94 11:55:28 PST Subject: archiving on inet In-Reply-To: Message-ID: On Tue, 1 Feb 1994, Kirk Sheppard wrote: > Regarding the archive I believe it was some company in Canada, I'm not > sure. There was a thread about this archiving question on another group I > suppose in the last three weeks. I can't remember where I saw it, if it > wasn't here. Sorry. And about "paying" for the cd-rom, I pay for the > usenet feed, and none of us who post are getting royalty payments from > any of the internet providers. So answer the question again, what is the > difference in paying an internet provider for access to usenet, and > paying a cd-rom provider for access to usenet? None materially, except > that the cd is not interactive, and some providers are (not all as in > bbs' that don't send e-mail to the internet, but have some usenet > groups.) There is no material difference that I can determine. I'm just glad you are not a politician. If all you are concerned with is "Material differnce", then you think it's perfectly ok for me to sell you a good copy of a magazine? By your "logic" (loosely used), you had to pay for the copy, and you had to pay for the original, so what's the difference? The difference is the WILL AND PERMISSION of the author! As the author of this message, I willingly placed it within the net. I HAVE NOT, NOR WILL NOT, GIVE FREE PERMISSION TO A CD-ROM PUBLISHING HOUSE TO PUBLISH MY WORK. The basis of copyright law is the protection of the author's rights. One of these rights is the choice of distribution. Perhaps you should try writing for money sometime. You might actually appreciate what you seem to be trying to tear apart. -ck From talon57 at well.sf.ca.us Tue Feb 1 11:55:38 1994 From: talon57 at well.sf.ca.us (Brian D Williams) Date: Tue, 1 Feb 94 11:55:38 PST Subject: clipper petition Message-ID: <199402011952.LAA01629@well.sf.ca.us> -----BEGIN PGP SIGNED MESSAGE----- CPSR sends: Electronic Petition to Oppose Clipper Please Distribute Widely >On January 24, many of the nation's leading experts in >cryptography and computer security wrote President Clinton and >asked him to withdraw the Clipper proposal. >The public response to the letter has been extremely favorable, >including coverage in the New York Times and numerous computer and >security trade magazines. >Many people have expressed interest in adding their names to the >letter. In response to these requests, CPSR is organizing an >Internet petition drive to oppose the Clipper proposal. We will >deliver the signed petition to the White House, complete with the >names of all the people who oppose Clipper. >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 noclipr at snyside.sunnyside.com Tue Feb 1 08:39:20 1994 Date: Tue, 1 Feb 1994 08:39:14 -0800 From: clipper.petition at snyside.sunnyside.com (via CPSR automation) Subject: Your petition regarding opposition to Clipper Apparently-To: Brian D Williams Your name has been added to the petition asking President Clinton to withdraw the Clipper proposal. We will deliver the signed petition to the White House at the end of the project. If you have any comments or questions, please email us at clipper at washofc.cpsr.org. "We have not yet begun to Encrypt!!" Brian Williams Extropian Cypherpatriot "Cryptocosmology: Sufficently advanced comunication is indistinguishable from noise." --Steve Witham -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLU6xXtCcBnAsu2t1AQHs8wP/cpftWyNnUtvEBcp5SuY/YR9h45DO/W7H VlgiVXf/aiOULr0dCMgJdu5BhoeV/C6MXEP0xfPNPSsk4JbpO2bn0yfcDLT69heU 9dGPE1ygVZsX4bOesk8s9eTaE+vSGpQcHXaotGrTWXo5Zsi7SFqdhraJEXFx9wnb g6lln31WF1A= =O1C5 -----END PGP SIGNATURE----- From kshep at netcom.com Tue Feb 1 12:05:27 1994 From: kshep at netcom.com (Kirk Sheppard) Date: Tue, 1 Feb 94 12:05:27 PST Subject: archiving on inet In-Reply-To: Message-ID: Dear Mr. Knight, I am not interested in "tearing apart" anything, I was just participating in a discussion. Ad hominem attacks are really unjustified. Even though you have a hard time understanding my arguments, I have refrained from calling you stupid, until now. You are not only stupid, but silly. "I'm glad your're not a politician" is a non-sequitur, and is certainly irrelevant to the discussion. Further, this whole discussion is entirely "academic", since there is absolutely no case law on this particular subject. So if you are so excited about it, collect your pennies and hire an attorney to enforce your copyright, I'm sure my brethern could use the business. Kirk Sheppard kshep at netcom.com P. O. Box 30911 "It is Better to Die on Your Feet Than to Bethesda, MD 20824-0911 Live On Your Knees." U.S.A. - Emiliano Zapata On Tue, 1 Feb 1994, Chris Knight wrote: > > > On Tue, 1 Feb 1994, Kirk Sheppard wrote: > > > Regarding the archive I believe it was some company in Canada, I'm not > > sure. There was a thread about this archiving question on another group I > > suppose in the last three weeks. I can't remember where I saw it, if it > > wasn't here. Sorry. And about "paying" for the cd-rom, I pay for the > > usenet feed, and none of us who post are getting royalty payments from > > any of the internet providers. So answer the question again, what is the > > difference in paying an internet provider for access to usenet, and > > paying a cd-rom provider for access to usenet? None materially, except > > that the cd is not interactive, and some providers are (not all as in > > bbs' that don't send e-mail to the internet, but have some usenet > > groups.) There is no material difference that I can determine. > > I'm just glad you are not a politician. > > If all you are concerned with is "Material differnce", then you think > it's perfectly ok for me to sell you a good copy of a magazine? By your > "logic" (loosely used), you had to pay for the copy, and you had to pay > for the original, so what's the difference? The difference is the WILL > AND PERMISSION of the author! As the author of this message, I willingly > placed it within the net. I HAVE NOT, NOR WILL NOT, GIVE FREE PERMISSION > TO A CD-ROM PUBLISHING HOUSE TO PUBLISH MY WORK. > > The basis of copyright law is the protection of the author's rights. One > of these rights is the choice of distribution. > > Perhaps you should try writing for money sometime. You might actually > appreciate what you seem to be trying to tear apart. > > > -ck > > From kshep at netcom.com Tue Feb 1 12:15:29 1994 From: kshep at netcom.com (Kirk Sheppard) Date: Tue, 1 Feb 94 12:15:29 PST Subject: Archiving mail-lists... In-Reply-To: Message-ID: Master Knight does seem a bit intolerant, doesn't he? Kirk Sheppard kshep at netcom.com P. O. Box 30911 "It is Better to Die on Your Feet Than to Bethesda, MD 20824-0911 Live On Your Knees." U.S.A. - Emiliano Zapata On Tue, 1 Feb 1994, Chris Knight wrote: > > > On Tue, 1 Feb 1994, Jim choate wrote: > > > I have to admit that I have broken your fair use copyright notice > > inadvertantly. > > > > I have stored an image of your message in the ram on my system which is not a > > part of inet or usenet nor involved in any way with the transmission to other > > nodes of such stored material. > > Are you claiming to have sold your RAM, while still powered, for a > profit? Knowing that it contained copyrighted work? Shame on you. > > > > Berne works great for paper, audio recordings, movies, etc. It does not work > > for networked information transmission. > > I'm sorry, I didn not realize I was talking to a supreme court justice. > Had I known you had the ultimate authority on this subject, I would not > have been wasting your time, or mine. > > Perhaps we should try this. You sell archives of the net, and we'll file > a class action suit... I'll back up my beliefs with actions, how about you? > > > -ck > > > From jazz at hal.com Tue Feb 1 12:25:27 1994 From: jazz at hal.com (Jason Zions) Date: Tue, 1 Feb 94 12:25:27 PST Subject: archiving on inet In-Reply-To: Message-ID: <9402012021.AA01756@jazz.hal.com> > So answer the question again, what is the >difference in paying an internet provider for access to usenet, and >paying a cd-rom provider for access to usenet? It's the difference between listening to the radio yourself and buying a home-made tape of the radio program from someone else. The first is legal; the second is, generally, not. Better yet, it's the difference between watching a program on HBO when you are getting that service legally (i.e. paying for it) and buying a tape of the same program from a friend who has HBO. Whether or not you also have legal access to HBO, the sale of the tape infringes on the copyright of the program. Jason From mccoy at ccwf.cc.utexas.edu Tue Feb 1 12:25:40 1994 From: mccoy at ccwf.cc.utexas.edu (Jim McCoy) Date: Tue, 1 Feb 94 12:25:40 PST Subject: archiving on inet In-Reply-To: <9402011752.AA00225@jazz.hal.com> Message-ID: <199402012023.AA26109@tramp.cc.utexas.edu> Jason Zions writes: > > > Others could argue that postings by their very nature, when posted > >become "public domain", and thus not copyrightable. > > Not successfully in court, I should think. How is a posting any different > than the production of a radio program which is distributed by > store-and-forward satellite distribution and then played through the radio > station and received at your home radio? [...] It is the difference between "broadcast" and "interactive communication." Tell me, if I call in to the talk show you are distribute as part of your radio program, do _I_ now own the copyright to a portion of your show? > >Finally what is the tangible difference between storing usenet postings > >on [any particular storage media] > > If you were a ligitimate recipient of the work in the first place (i.e. got > it in a newsfeed) and you store those postings for your own use or for the > use of others on that node in the store-and-forward network, then you can > keep the work 'til the bits rot. Infringement occurs when you copy those > bits onto some medium for some purpose other than store-and-forward > propagation or the allowed fair-use exceptions; stuffing articles on a > CD-ROM and selling them falls into neither category and hence is an > infringement. Buzzz. According to your logic all that one needs to do is to change the label on the order from from "Usenet articles on CD-ROM" to "Quarterly Usenet Feed distributed on CD-ROM" and I am in the clear. I am not selling a collectoin containing your articles, I am providing a low-bandwidth newsfeed to those who do not have the same level of connectivity you have or that want the excitement of seeing thier newsfeed delivered over the "original information superhighway" (aka postal services.) It is still store-and-forward, it is just store-forever-and-forward-not-so-often. But under all the smoke and mirrors nothing changes the fact that I am selling archives of the Usenet. No amount of puffed up indignation is going to change the fact that your Usenet posting or message to a mailing list is of no real value to you and is honestly as free as a bird once it hits the wire. jim From pmetzger at lehman.com Tue Feb 1 12:30:38 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Tue, 1 Feb 94 12:30:38 PST Subject: archiving on inet In-Reply-To: Message-ID: <199402012029.PAA03234@snark> Chris Knight says: > If all you are concerned with is "Material differnce", then you think > it's perfectly ok for me to sell you a good copy of a magazine? By your > "logic" (loosely used), you had to pay for the copy, and you had to pay > for the original, so what's the difference? The difference is the WILL > AND PERMISSION of the author! As the author of this message, I willingly > placed it within the net. I HAVE NOT, NOR WILL NOT, GIVE FREE PERMISSION > TO A CD-ROM PUBLISHING HOUSE TO PUBLISH MY WORK. Try to sue for damages when your work is available for free to millions of people. The judge will laugh in your face, copyright or no. Damages are, after all, related to lost revenue -- if you allow anyone who wants to see something for free in one medium, you will have a fucking hard time to keep them from examining it in another equivalent medium. Usenet is NOT a magazine. Failing to put a copyright notice in your work destroys whats left of your ability to do anything. I'm sure you can pay a lawyer to sue for you, but this isn't exactly one anyone is going to take on contingency. .pm From nate at VIS.ColoState.EDU Tue Feb 1 12:35:27 1994 From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons) Date: Tue, 1 Feb 94 12:35:27 PST Subject: new, improved remailer GUI Message-ID: <9402012034.AA04618@vangogh.VIS.ColoState.EDU> -----BEGIN PGP SIGNED MESSAGE----- I have added some features to the remailer GUI I built in Mosaic. It now has a radio button for choosing to use the CP remailers, and toggle switches for selecting remailers. It's also been moved, and the old one is no longer there, so don't use it. it's new location is: http://monet.vis.colostate.edu/~nate/mailer.html Give it a try, and tell me what you think. BTW, this one is fully open for business, so use it as much as you like! - -nate - -- +-----------------------------------------------------------------------+ | Nate Sammons | | Colorado State University Computer Visualization Laboratory | | Data Visualization/Interrogation, Modeling, Animation, Rendering | +-----------------------------------------------------------------------+ From kshep at netcom.com Tue Feb 1 12:35:39 1994 From: kshep at netcom.com (Kirk Sheppard) Date: Tue, 1 Feb 94 12:35:39 PST Subject: Archiving mail-lists... In-Reply-To: Message-ID: On Tue, 1 Feb 1994, Chris Knight wrote: > > On Tue, 1 Feb 1994, Jim choate wrote: > > > I have to admit that I have broken your fair use copyright notice > > inadvertantly. > > > > I have stored an image of your message in the ram on my system which is not a > > part of inet or usenet nor involved in any way with the transmission to other > > nodes of such stored material. > > Are you claiming to have sold your RAM, while still powered, for a > profit? Knowing that it contained copyrighted work? Shame on you. > > > > Berne works great for paper, audio recordings, movies, etc. It does not work > > for networked information transmission. > > I'm sorry, I didn not realize I was talking to a supreme court justice. > Had I known you had the ultimate authority on this subject, I would not > have been wasting your time, or mine. > > Perhaps we should try this. You sell archives of the net, and we'll file > a class action suit... I'll back up my beliefs with actions, how about you? > > > -ck > > From jazz at hal.com Tue Feb 1 12:35:41 1994 From: jazz at hal.com (Jason Zions) Date: Tue, 1 Feb 94 12:35:41 PST Subject: archiving on inet In-Reply-To: <199402012023.AA26109@tramp.cc.utexas.edu> Message-ID: <9402012033.AA01805@jazz.hal.com> >It is the difference between "broadcast" and "interactive communication." >Tell me, if I call in to the talk show you are distribute as part of your >radio program, do _I_ now own the copyright to a portion of your show? This is an interesting point of discussion. The question becomes one of determining what the protected work is. Given that it is a call-in show, the entire show would be a protected work and its copyright would belong to the show's creator. I do not know if you retain copyright in the small part of the work which represents your own intellectual property (i.e. what you say), but I suspect it could be argued that you gave your permission to broadcast your work when you called in to begin with. It gets murkier to me with respect to compensation from the sale of transcripts or recordings. Mike, is there case law here? >But under all the smoke and mirrors nothing changes the fact that I am >selling archives of the Usenet. No amount of puffed up indignation is >going to change the fact that your Usenet posting or message to a mailing >list is of no real value to you and is honestly as free as a bird once it >hits the wire. We differ on the use of the word "honestly". In practice, enforcement is well-nigh impossible; nonetheless, according to the letter of the law, my words are my property to do with as I see fit. If I state that they may not be recorded on optical media, the law requires you to honor that. Jason Copyright 1994 Jason Zions. Copying for the purpose of propagation of the Cypherpunks mailing list in email or usenet news form is permitted, except no copy shall be made in permanent optical storage media without the express permission of the author. All other rights reserved. From warlord at MIT.EDU Tue Feb 1 12:45:27 1994 From: warlord at MIT.EDU (Derek Atkins) Date: Tue, 1 Feb 94 12:45:27 PST Subject: PGP In-Reply-To: <9402011949.AA18718@runner.utsa.edu> Message-ID: <9402012041.AA12750@toxicwaste.media.mit.edu> Well, I don't know exactly how many calculations are necessary, but I've seen some posts that have given general numbers... Let me give some examples to try to answer your question. Currently, we estimate about 2500 MIP-years have gone into trying to factor RSA129 (about 425 bits). We estimate we are about 60% through... The whole project taking about 5000 MIP-years. Figure that every ten decimal digits adds one order of magnitude. So, a 512-bit (~155-digit) key would require about 5e7 MIP-years. And a 1024-bit key would require approximately 5e22 MIP-years. (These are approximations -- please do not quote these numbers). Brute-forcing IDEA takes about as much computation as factoring something between a 1200 and 3000 bit RSA key (I've heard both numbers, but I don't know the numbers). So, in the current implementation, RSA is the weak link! Since the passphrase is just a hash to an IDEA key, breaking the secret ring is as hard as either dictionary attacking the key, or breaking IDEA, which is harder than factoring the RSA key, given current knowledge about the algorithms. I hope this answers your questions. If someone has real numbers to put in here, please update mine! -derek From kshep at netcom.com Tue Feb 1 12:45:39 1994 From: kshep at netcom.com (Kirk Sheppard) Date: Tue, 1 Feb 94 12:45:39 PST Subject: archiving on inet In-Reply-To: <9402012021.AA01756@jazz.hal.com> Message-ID: This is not an accurate comparison. A posting on usenet is not the same item as a program on HBO or the radio. In what way does my internet provider (netcom) have a "legal" distribution of usenet news, while a cd-rom provider does not? HBO has paid for the use of the programs it broadcasts that are produced by others, hence they have a contract between themselves and the owners of the copyright. No providers of usenet news have any agreements between themselves and the posters regarding copyrights. Netcom and all the other internet providers receive postings "free" and a cd-rom manufacturer has the same "right" to use postings as any other internet provider. Kirk Sheppard kshep at netcom.com P. O. Box 30911 "It is Better to Die on Your Feet Than to Bethesda, MD 20824-0911 Live On Your Knees." U.S.A. - Emiliano Zapata On Tue, 1 Feb 1994, Jason Zions wrote: > > So answer the question again, what is the > >difference in paying an internet provider for access to usenet, and > >paying a cd-rom provider for access to usenet? > > It's the difference between listening to the radio yourself and buying a > home-made tape of the radio program from someone else. The first is legal; > the second is, generally, not. > > Better yet, it's the difference between watching a program on HBO when you > are getting that service legally (i.e. paying for it) and buying a tape of > the same program from a friend who has HBO. Whether or not you also have > legal access to HBO, the sale of the tape infringes on the copyright of the > program. > > Jason > From cknight at crl.com Tue Feb 1 13:05:28 1994 From: cknight at crl.com (Chris Knight) Date: Tue, 1 Feb 94 13:05:28 PST Subject: Why is Chris Knight a Twerp? In-Reply-To: Message-ID: It sure was short trip for you to go from person to prick. My "attacks" have been on your logic. Something that has always been a prime goal of a debate. Lacking anything intellignet to say, you resort to the text quoted below, and your attempted personal slight of refering to me as "Master Knight" in your current posts. Is there any chance that this will get back to the discussion at hand, or are you tired of this toy and trying to find something else to play with? If all you have left is attacks, name calling, and rudeness, perhaps you should find other toys and leave the discussions to adults. -ck On Tue, 1 Feb 1994, Kirk Sheppard wrote: > Dear Stupid, > > Why you are intent on attacking me for no reason is beyond me. I didn't > attack you personally, what is the matter with you? Also I am not > interested in gratuitous advice regarding "trying to write sometime". I > can see why you might be bitter as you obviously lack the intelligence > and education to make much money writing. > > Kirk Sheppard > > kshep at netcom.com > > P. O. Box 30911 "It is Better to Die on Your Feet Than to > Bethesda, MD 20824-0911 Live On Your Knees." > U.S.A. > - Emiliano Zapata > > > From pmetzger at lehman.com Tue Feb 1 13:05:39 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Tue, 1 Feb 94 13:05:39 PST Subject: archiving on inet In-Reply-To: <9402012021.AA01756@jazz.hal.com> Message-ID: <199402012103.QAA03285@snark> Jason Zions says: > > So answer the question again, what is the > >difference in paying an internet provider for access to usenet, and > >paying a cd-rom provider for access to usenet? > > It's the difference between listening to the radio yourself and buying a > home-made tape of the radio program from someone else. The first is legal; > the second is, generally, not. The reason selling a tape of a radio show isn't legal is because then you can play it as often as you like. On the other hand, usenet is already distributed in a form that lets you read the messages as often as you like. You can archive them forever, and in fact thats part of the news software. .pm From kshep at netcom.com Tue Feb 1 13:05:43 1994 From: kshep at netcom.com (Kirk Sheppard) Date: Tue, 1 Feb 94 13:05:43 PST Subject: archiving on inet In-Reply-To: <9402011948.AB17603@federal-excess.apple.com> Message-ID: Dear Master Lefty, You too, have fallen into the same trap, as Master Knight, i.e., ad hominem attacks, unprovoked, launched merely because I disagree with you. As to your arguments, no I don't think you have followed my logic at all, and I certainly cannot follow or agree with your assertions. My point is that the redistribution of usenet postings by Netcom, my local bbs, me on my hard disk to others for pay or not, or by cd-rom are not different and it is just as legal for Netcom to charge me for providing me a usenet feed as it is legal for a cd-rom manufacturer to do the same, neither is paying us a dime nor are they obligated to do so. Personal use is not at all relevant. Netcom, Delphi are copying and providing usenet newsfeeds as a commercial service, without paying any royalties to the authors of the usenet postings. And we can all do the same and use any medium we want to whether you or Master Knight like it or understand it. Kirk Sheppard kshep at netcom.com P. O. Box 30911 "It is Better to Die on Your Feet Than to Bethesda, MD 20824-0911 Live On Your Knees." U.S.A. - Emiliano Zapata On Tue, 1 Feb 1994, Lefty wrote: > >Usenet copyrightable? I still doubt it. Of course, the only way to > >find out is to file a very expensive lawsuit. Most posters would not find > >their postings worth the expense to sue on copyright. Only a very rich > >dilletante, or someone less rich who is a fanatic on the subject is > >likely to do so. Also, you would have a hard time answering the > >difference between charging for a usenet feed and charging for a cd-rom, > >again I see little difference except that one is more prompt in time than > >the other. But, again, my newsfeed from a BBS which might be 24 hrs > >delayed, and my netcom account which is much faster and a cd-rom differs > >only as to time removed from the original posting. > > So, would you argue, on the same grounds, that you didn't believe that a > movie delivered into your home via a cable feed could be copyrighted? > > How about a movie on a laser disk? > > Do you understand that there's is a difference between personal use, which > does not infringe copyright, and redistribution, which does? > > Are you _sure_ you're an attorney? > > -- > Lefty (lefty at apple.com) > C:.M:.C:., D:.O:.D:. > > > From mnemonic at eff.org Tue Feb 1 13:10:40 1994 From: mnemonic at eff.org (Mike Godwin) Date: Tue, 1 Feb 94 13:10:40 PST Subject: archiving on inet In-Reply-To: <9402012033.AA01805@jazz.hal.com> Message-ID: <199402012105.QAA11615@eff.org> Jim writes: > I do not know if you retain copyright in the small part of > the work which represents your own intellectual property (i.e. what you > say), but I suspect it could be argued that you gave your permission to > broadcast your work when you called in to begin with. It gets murkier to me > with respect to compensation from the sale of transcripts or recordings. > Mike, is there case law here? Not to my knowledge. But there's no disputing among lawyers that copyright law applies. --Mike From kshep at netcom.com Tue Feb 1 13:15:29 1994 From: kshep at netcom.com (Kirk Sheppard) Date: Tue, 1 Feb 94 13:15:29 PST Subject: archiving on inet In-Reply-To: <199402012023.AA26109@tramp.cc.utexas.edu> Message-ID: Well said, Jim. Kirk Sheppard kshep at netcom.com P. O. Box 30911 "It is Better to Die on Your Feet Than to Bethesda, MD 20824-0911 Live On Your Knees." U.S.A. - Emiliano Zapata On Tue, 1 Feb 1994, Jim McCoy wrote: > Jason Zions writes: > > > > > Others could argue that postings by their very nature, when posted > > >become "public domain", and thus not copyrightable. > > > > Not successfully in court, I should think. How is a posting any different > > than the production of a radio program which is distributed by > > store-and-forward satellite distribution and then played through the radio > > station and received at your home radio? [...] > > It is the difference between "broadcast" and "interactive communication." > Tell me, if I call in to the talk show you are distribute as part of your > radio program, do _I_ now own the copyright to a portion of your show? > > > >Finally what is the tangible difference between storing usenet postings > > >on [any particular storage media] > > > > If you were a ligitimate recipient of the work in the first place (i.e. got > > it in a newsfeed) and you store those postings for your own use or for the > > use of others on that node in the store-and-forward network, then you can > > keep the work 'til the bits rot. Infringement occurs when you copy those > > bits onto some medium for some purpose other than store-and-forward > > propagation or the allowed fair-use exceptions; stuffing articles on a > > CD-ROM and selling them falls into neither category and hence is an > > infringement. > > Buzzz. According to your logic all that one needs to do is to change the > label on the order from from "Usenet articles on CD-ROM" to "Quarterly > Usenet Feed distributed on CD-ROM" and I am in the clear. I am not selling > a collectoin containing your articles, I am providing a low-bandwidth > newsfeed to those who do not have the same level of connectivity you have > or that want the excitement of seeing thier newsfeed delivered over the > "original information superhighway" (aka postal services.) It is still > store-and-forward, it is just store-forever-and-forward-not-so-often. > > But under all the smoke and mirrors nothing changes the fact that I am > selling archives of the Usenet. No amount of puffed up indignation is > going to change the fact that your Usenet posting or message to a mailing > list is of no real value to you and is honestly as free as a bird once it > hits the wire. > > jim > From mnemonic at eff.org Tue Feb 1 13:25:28 1994 From: mnemonic at eff.org (Mike Godwin) Date: Tue, 1 Feb 94 13:25:28 PST Subject: archiving on inet In-Reply-To: <199402012029.PAA03234@snark> Message-ID: <199402012121.QAA11869@eff.org> > > Try to sue for damages when your work is available for free to > millions of people. The judge will laugh in your face, copyright or > no. Damages are, after all, related to lost revenue -- if you allow > anyone who wants to see something for free in one medium, you will > have a fucking hard time to keep them from examining it in another > equivalent medium. One can register the work and sue for statutory damages and attorneys' fees. No need to prove damages in such a case. If the Copyright Act is amended this year, it may be that one need not even register the work. --Mike From cknight at crl.com Tue Feb 1 13:25:41 1994 From: cknight at crl.com (Chris Knight) Date: Tue, 1 Feb 94 13:25:41 PST Subject: Why is Chris Knight a Twerp and an Idiot? In-Reply-To: Message-ID: On Tue, 1 Feb 1994, Kirk Sheppard wrote: > Dear Master Knight, > > You have a double standard, or a bad memory. Saying "I'm glad your'e not > a politician" is most definitly a personal attack on me, not my > arguments. An incorrect jump of conclusions. This was a comment on your arguments. I would not sleep well at night if the arguemnts you use were helping to write the laws regarding copyright and intelectual property. > You became a prick first, and I am happy to join in. Happy? Perhaps "At Home" is a better turn of phrase. If fact, it seems you were looking for an excuse to switch to flame mode. > If you look at the thread carefully you will see that you made the ad hominem > attack first, I do admit in joining you in the gutter however. Also, I > really don't care what you're thoughts are? Why should I. Why should you care? I would like to end this useless chatter and go back to the discussion. It appears that you do not. > Just stop calling names when it hasn't been done to you. Or didn't your're mother and father teach you that, Master Knight? It hadn't? OOPS! I guess I misread the subject of this message... Seems you have the thread confused. -ck From jazz at hal.com Tue Feb 1 13:25:45 1994 From: jazz at hal.com (Jason Zions) Date: Tue, 1 Feb 94 13:25:45 PST Subject: archiving on inet In-Reply-To: <199402012103.QAA03285@snark> Message-ID: <9402012121.AA01984@jazz.hal.com> >The reason selling a tape of a radio show isn't legal is because then >you can play it as often as you like. Even if you made play-once-and-then-self-destruct tapes like on Mission Impossible, selling them would still be illegal. You've made an unauthorized copy, plain and simple. >You can archive them forever, and in fact thats part of the news software. Yes, you, a recipient, can archive them forever. You *cannot* distribute that archive in any form whatsoever. I'm struggling with drawing an appropriate distinction between CD-ROM as newsfeed medium and CD-ROM as archive medium. If a newsfeed provider sent you a quarterly newsfeed on CD-ROM which you then fed into your normal news system as if it were a live feed, after which you broke the CD-ROM; that looks like a high-bandwidth-delay-product newsfeed. If a provider sent you a quarterly newsfeed in Cnews directory form which you then mounted onto your news system, I'd buy that as a newsfeed. If the provider sent to a newsfeed in Cnews form which you mounted someplace other than as a part of the news system - now an archive has been created and sold. But if you mounted it as part of Cnews and then copied it via news onto your own CD-ROM drive, then it seems like it'd be a personal archive. No one said this was gonna be easy. It seems like I'm swallowing camels and straining out flies, but these flies are camel-sized. Jason Copyright 1994 Jason Zions. Copying or retransmission for the purpose of propagation of the Cypherpunks mailing list in email or newsfeed form is permitted, except that no copy may be made on any permanent digital optical storage medium. From pmetzger at lehman.com Tue Feb 1 13:25:46 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Tue, 1 Feb 94 13:25:46 PST Subject: Archiving mail-lists... In-Reply-To: Message-ID: <199402012121.QAA03308@snark> Kirk Sheppard says: > On Tue, 1 Feb 1994, Chris Knight wrote: > > > This appears to be merely hot air, since despite all his talk Master > Knight hasn't taken any "action" and it is doubtful that he has the money > or other "necessities" requisite for doing so. Also, notice the term > "beliefs", which explains a lot. I thought were were having a discussion > on a legal or academic basis, not one involving religeous or > philosophical "beliefs" or faith. Archives of the net are already being sold. Furthermore, some folks at the FBI got a newsfeed from uunet years ago by magtape when they didn't have a direct uucp link. I'd say that anyone who thinks they can actually succeed at such a suit is welcome to try, but I wouldn't break a sweat worrying about it. Yes, you have a copyright over your work -- however, once you've posted it to the net it is likely practically impossible to restrict distribution. Since you've already allowed it to be distributed on demand to anyone for free it is hard to claim damages if it is distributed to anyone via some medium you don't like. Archives of all of usenet already exist. I was talking with Eric Fair at Usenix about using a Cray at Apple to produce an index of all usenet traffic thus far -- it likely won't happen, but those worried about such possibilities are welcome to have their lawyers send me nasty letters. If you want your stuff to have limited distribution, you have to make a conscious effort to limit distribution or you have likely lost all cause of action. Posting to the net is likely implicit concent to unlimited distribution, since it is in fact what will happen and you have no reasonable expectation of anything else. Perry From pmetzger at lehman.com Tue Feb 1 13:30:41 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Tue, 1 Feb 94 13:30:41 PST Subject: archiving on inet In-Reply-To: <199402012121.QAA11869@eff.org> Message-ID: <199402012126.QAA03329@snark> Mike Godwin says: > > Try to sue for damages when your work is available for free to > > millions of people. The judge will laugh in your face, copyright or > > no. Damages are, after all, related to lost revenue -- if you allow > > anyone who wants to see something for free in one medium, you will > > have a fucking hard time to keep them from examining it in another > > equivalent medium. > > One can register the work and sue for statutory damages and attorneys' > fees. No need to prove damages in such a case. Absolutely true, but one has to say "Copyright" in the work in such a case. Virtually no usenet work has that magic word in it. From what I understand, if you don't say "Copyright" they can stop you in court but there is a presumption going for the defendant. Perry From lefty at apple.com Tue Feb 1 13:30:44 1994 From: lefty at apple.com (Lefty) Date: Tue, 1 Feb 94 13:30:44 PST Subject: archiving on inet Message-ID: <9402012115.AA22993@internal.apple.com> Kirk "I Can't Believe It's a Law Firm!" Sheppard astounds me by posting > >This book analogy is not accurate. It is my contention that usenet >postings are not copyrighted. Our postings are not disseminated like a book... Immaterial. What on earth does "like a book" mean? Do you contend that only works printed on paper can have copyright protection, or only works which are sold in bookstores, or only works which are bound in signatures? As a trivial counterexample, movies broadcast over cable and songs played on the radio retain copyright, without any question or doubt. They aren't "disseminated like a book", either. >we are paid nothing for the use of our postings on the multitude >of machines that our postings appear. Are you suggesting that there is any connection whatsoever between the ability to copyright a given work and some third party's willingness to pay for it? Are you claiming that if I write a book and decide to give copies away rather than sell them that my work is thereby not copyrighted? If so, you're clearly and without any doubt whatsoever in error. Are you _positive_ you're a lawyer? >Or, in the alternative, if copyrighted, by posting them in the electronic >>ether, we give up most of our rights regarding dissemination, copying etc. Aha. This would explain why there's no legal problem with my recording the complete works of the Beatles off the radio and then reselling them, no doubt. >Perhaps we may still >have some residual rights regarding accuracy and the like. Also the >posting regarding the legal blurbs on software, really was off point, >since what they they were refering to was a "license", and again there is >some doubt about how enforceable the individual licenses that the >software companies give. That is, some of these licenses may have >provisions that are not enforceable. So, let's see here. Let's say, for the sake of argument, that I'm Stephen King. I write a book, using a word processing program on my computer, and saving the results to a magmeto-optical disk. Is it copyrighted? Clearly, it is. I sell the book to a publisher, who prints it onto paper, sews the paper into signatures, binds it between covers, and sells several million instantiations of this book to B. Dalton's. Is it still copyrighted? Clearly, it is. THe publisher takes a copy of my magneto-optical disk, adds some support software licensed from Voyager, Inc., and presses a CD-ROM version of my book. Is it still copyrighted? Clearly, it is. At the same time, I distribute several long sections of the book, via email, to a private mailing list of friends. Is the book still copyrighted? Clearly, it is. OK, now, here's the tough one. I give one of my friend's permission to post a long (i.e. clearly too long to constitute "fair use") section of this book to rec.arts.books, with a copyright notice prominently displayed at the very beginning of the posting, i.e. Copyright (c) 1994 by Stephen King. All rights reserved. You claim that this posting, suddenly and magically, no longer enjoys copyright protection. On what basis? To approach this issue in another way, I wonder whether you're familiar with "Internet Talk Radio", a scheme wherein voice broadcasts can be done over the Internet. If I were to pay the appropriate fees to ASCAP to allow me to broadcast a song by Pearl Jam over Internet Talk Radio, are you claiming that Pearl Jam's copyright to _their_ _own_ _music_ would be destroyed by _my_ having played it back over this medium? This would clearly seem to be your contention. I think you need to give this a wee bit more thought, Kirk. -- Lefty (lefty at apple.com) C:.M:.C:., D:.O:.D:. From pmetzger at lehman.com Tue Feb 1 13:35:29 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Tue, 1 Feb 94 13:35:29 PST Subject: archiving on inet In-Reply-To: <9402012121.AA01984@jazz.hal.com> Message-ID: <199402012131.QAA03337@snark> Jason Zions says: > >You can archive them forever, and in fact thats part of the news software. > > Yes, you, a recipient, can archive them forever. You *cannot* distribute > that archive in any form whatsoever. The news software is explicitly designed to allow remote hosts to request articles from each other. Article numbers are never reused -- I can just use a nasty hierarchical storage system to keep all the news articles I ever receive online. So, how can you reconcile the existance of the news software with your quaint notions? Are you claiming that CNews and INN break the law? Are you claiming usenet is illegal or something? > I'm struggling with drawing an appropriate distinction between CD-ROM as > newsfeed medium and CD-ROM as archive medium. Maybe you are struggling because there is no reasonable way to make the distinction? > Copyright 1994 Jason Zions. Copying or retransmission for the purpose of > propagation of the Cypherpunks mailing list in email or newsfeed form is > permitted, except that no copy may be made on any permanent digital optical > storage medium. Well, you can now sue all the people who back up their home directories nightly to optical disk. I believe all the folks at Bell Labs who use Plan-9 are now in violation of your "copyright". Perry From lefty at apple.com Tue Feb 1 13:35:40 1994 From: lefty at apple.com (Lefty) Date: Tue, 1 Feb 94 13:35:40 PST Subject: archiving on inet Message-ID: <9402012127.AA23182@internal.apple.com> >You too, have fallen into the same trap, as Master Knight, i.e., ad hominem >attacks, unprovoked, launched merely because I disagree with you. Please feel free to identify the "ad hominem attack" to which you're referring. I _have_ questioned your claim to be an attorney, largely because I do not believe that anyone could manage to pass a bar exam while being so utterly ignorant of the basest rudiments of copyright law. >As to >your arguments, no I don't think you have followed my logic at all, and I >certainly cannot follow or agree with your assertions. I found no logic in your postings. This explains, I think, my inability to follow it. I suspect that there are other explanations for _your_ inability to follow, or respond to, _my_ assertions. >My point is that >the redistribution of usenet postings by Netcom, my local bbs, me on my >hard disk to others for pay or not, or by cd-rom are not different and it >is just as legal for Netcom to charge me for providing me a usenet feed >as it is legal for a cd-rom manufacturer to do the same, neither is >paying us a dime nor are they obligated to do so. > >Personal use is not at all relevant. No!? How is it, then, that _I_ can copy a movie legally from HBO but I can't legally sell the tape to you, eh? >Netcom, Delphi are copying and providing usenet newsfeeds >as a commercial service, without paying any royalties to the authors of >the usenet postings. And we can all do the same and use any medium we >want to whether you or Master Knight like it or understand it. None of which has anything, specifically, to do with copyright. Do you understand the concept of "intellectual property" in the least? Are you absolutely, positively, thoroughly _certain_ you're a lawyer? (Hey, can I repost that private email you sent me? I'm sure the list would _love_ to see so deeply reasoned and clearly thought out an argument. Besides, you don't believe that it's copyrighted, do you?) -- Lefty (lefty at apple.com) C:.M:.C:., D:.O:.D:. From cknight at crl.com Tue Feb 1 13:40:41 1994 From: cknight at crl.com (Chris Knight) Date: Tue, 1 Feb 94 13:40:41 PST Subject: archiving on inet In-Reply-To: <199402012029.PAA03234@snark> Message-ID: On Tue, 1 Feb 1994, Perry E. Metzger wrote: > Try to sue for damages when your work is available for free to > millions of people. The judge will laugh in your face, copyright or > no. Damages are, after all, related to lost revenue Lost revenue can be measured in more than one way. Besides estimated loss of sales, it can be measured in profit earned by the defendant. If an author published a story in a magazine once, and never intends to publish it again, this does not give you the right to sell his story because he wasn't going to be making money on it anywhay. > anyone who wants to see something for free in one medium, you will > have a fucking hard time to keep them from examining it in another > equivalent medium. Profanity aside, that's not an entirely logical arguemnt. There are plenty of free publications in the US that contain copyrighted work. Publishing in a "free medium" does not strip your rights. -ck From mnemonic at eff.org Tue Feb 1 13:40:44 1994 From: mnemonic at eff.org (Mike Godwin) Date: Tue, 1 Feb 94 13:40:44 PST Subject: archiving on inet In-Reply-To: <199402012126.QAA03329@snark> Message-ID: <199402012139.QAA12055@eff.org> Perry writes: > Mike Godwin says: > > > Try to sue for damages when your work is available for free to > > > millions of people. The judge will laugh in your face, copyright or > > > no. Damages are, after all, related to lost revenue -- if you allow > > > anyone who wants to see something for free in one medium, you will > > > have a fucking hard time to keep them from examining it in another > > > equivalent medium. > > > > One can register the work and sue for statutory damages and attorneys' > > fees. No need to prove damages in such a case. > > Absolutely true, but one has to say "Copyright" in the work in such a > case. This is not true. > Virtually no usenet work has that magic word in it. From what I > understand, if you don't say "Copyright" they can stop you in court > but there is a presumption going for the defendant. May have been true in the old days, but it isn't true now. --Mike From cknight at crl.com Tue Feb 1 13:50:41 1994 From: cknight at crl.com (Chris Knight) Date: Tue, 1 Feb 94 13:50:41 PST Subject: Archiving mail-lists... In-Reply-To: Message-ID: On Tue, 1 Feb 1994, Kirk Sheppard wrote: > On Tue, 1 Feb 1994, Chris Knight wrote: > > > > This appears to be merely hot air, since despite all his talk Master > Knight hasn't taken any "action" and it is doubtful that he has the money > or other "necessities" requisite for doing so. And what sort of action am I supposed to take? This was, to my knowledge a discussion. And who is this "Master Knight"? > Also, notice the term > "beliefs", which explains a lot. I thought were were having a discussion > on a legal or academic basis, not one involving religeous or > philosophical "beliefs" or faith. All of us, including yourself Mr. Sheppard, have been discussing theoretical law and rights. Until it is tried in court, we are all stating how we BELIEVE it will go. This has nothing to do with religion, or philosophy; merely interpretation of law. -ck From kshep at netcom.com Tue Feb 1 14:10:41 1994 From: kshep at netcom.com (Kirk Sheppard) Date: Tue, 1 Feb 94 14:10:41 PST Subject: Archiving mail-lists... In-Reply-To: Message-ID: "Master" is the term one uses in place of "Mister" or "Mr." when politely addressing a male, under the age of majority. Kirk Sheppard kshep at netcom.com P. O. Box 30911 "It is Better to Die on Your Feet Than to Bethesda, MD 20824-0911 Live On Your Knees." U.S.A. - Emiliano Zapata On Tue, 1 Feb 1994, Chris Knight wrote: > > > On Tue, 1 Feb 1994, Kirk Sheppard wrote: > > > On Tue, 1 Feb 1994, Chris Knight wrote: > > > > > > > > > > This appears to be merely hot air, since despite all his talk Master > > Knight hasn't taken any "action" and it is doubtful that he has the money > > or other "necessities" requisite for doing so. > > And what sort of action am I supposed to take? This was, to my knowledge a > discussion. And who is this "Master Knight"? > > > > Also, notice the term > > "beliefs", which explains a lot. I thought were were having a discussion > > on a legal or academic basis, not one involving religeous or > > philosophical "beliefs" or faith. > > All of us, including yourself Mr. Sheppard, have been discussing > theoretical law and rights. Until it is tried in court, we are all > stating how we BELIEVE it will go. This has nothing to do with religion, > or philosophy; merely interpretation of law. > > > -ck > > From mcb at net.bio.net Tue Feb 1 14:10:45 1994 From: mcb at net.bio.net (Michael C. Berch) Date: Tue, 1 Feb 94 14:10:45 PST Subject: archiving on inet Message-ID: <9402012207.AA29009@net.bio.net> Jason Zion writes: > Yep. When you're providing a netnews feed, you're acting as a node in a > store-and-forward network. A CD-ROM is not a part of a store-and-forward > network; it is a permanently fixed repository of information. You can't hold > up a netnews feed in a courtroom and point at it saying "there it is"; you > *can* do so with a CD-ROM. > > So I suppose you want to give some > kind of list of what types of media are acceptable for transmitting > netnews feeds, and which are not? You seem awfully confident about something that has never, to my knowledge, been litigated at the appellate level. The difference you posit between a netnews feed and a CD-ROM seems very tenuous to me -- not the kind of thing I would feel supreme confidence in trying to convince a judge of. As far as "holding something up" and saying "there it is", I could do the same thing in court with a hard disk containing a news spool and a CD-ROM drive containing a CD with a copy of a news feed. Set up two windows side-by side and they have the same article in them, right down to the Message-ID, byte count, even a CRC or SNEFRU checksum. *Now* try to convince the court they are different animals for copyright purposes... > A CD-ROM isn't a medium for transmitting netnews feeds; it's a permanently > fixed copy of the contents of such a feed. Static versus dynamic; permanent, > ephemeral. Is this hard to understand? Yes, very. And I have been in computing since 1975 and a licensed attorney since 1981. So I think it is fair to say that if I find this murky and confusing, and believe that copyright law does not divide these types of cases into neat little boxes, then others may as well. > The plain and simple fact is: When you post a message to usenet, you do > so with the expectation that others will receive it. You can have no > way of knowing or limiting who may get it; that is given by the nature > of the network. Usenet news is, and is intended to be, publicly > accessable information. If there is something you don't want > distributed, then DON'T POST IT! > > Learn a little about law; while you're at it, learn a little about usenet. > When you post a message to usenet, you have tossed it into a flood-routed > store-and-forward network. You implicitly give permission for copying > appropriate to the propagation of messages in that network. You neither > grant permission nor withhold permission for Fair Use. Everything else, > though, is not granted unless explicitly granted. > > If I post a message, under the terms of the Berne Convention and current US > copyright law, a recipient was not granted the right to print a copy and > publish it in a book. What makes you think I granted them permission to > publish a copy in a CD-ROM? The only permission I granted was that they > could (a) read it and (b) forward it via usenet protocols. Except that it is extremely difficult to put one's finger on "Usenet protocols". *Most* people are using (for example) RFC1036-compliant Netnews article formats and either NNTP or UUCP for transport. BUT, this certainly does not apply to everybody -- some people read newsgroups as e-mail (SMTP, UUCP, QuickMail, cc:mail, Lotus Notes, etc.). Some people receive netnews feeds in the form of magnetic tape; some as large batched file transmissions on IBM mainframe networks. Some get news articles via friends who operate informal "clipping services" and save and print articles of interest and send them via snail-mail. Some people archive newsgroups and put them on FTP/gopher/WWW/WAIS server where they may be indexed and retrieved years later. I would not want to have the burden of convincing a court that any of these are beyond the purview of "Usenet" and thus, in your scheme, implicitly copyright infringements. It is not that I vehemently disagree with any of the points made above -- who knows what will eventually evolve as a legal standard? -- I just think that it is a wildly unsettled area and pronouncements of bright-line criteria in the absence of relevant legislation *or* jurisprudence is fatuous at best. -- Michael C. Berch mcb at net.bio.net / mcb at postmodern.com From lefty at apple.com Tue Feb 1 14:15:28 1994 From: lefty at apple.com (Lefty) Date: Tue, 1 Feb 94 14:15:28 PST Subject: archiving on inet Message-ID: <9402012201.AA23756@internal.apple.com> >This is not an accurate comparison. A posting on usenet is not the same >item as a program on HBO or the radio. So you claim. How does it differ, though? >In what way does my internet provider >(netcom) have a "legal" distribution of usenet news, while a cd-rom >provider does not? I have "provided" my postings to Usenet, for the personal use of Usenet subscribers. By providing my postings to a particular distribution mechanism, I implicitly give permission for them to be redistributed _via_ _that_ _mechanism_. I _do_ _not_ give permission for them to be repackaged and resold via another medium, any more than David Byrne has given me permission to resell cassettes of his music by allowing it to be broadcast on the radio. >HBO has paid for the use of the programs it broadcasts >that are produced by others, hence they have a contract between >themselves and the owners of the copyright. And, hence, they have permission to distribute it over the medium of cable televison transmission. This does not, in and of itself, give them the right to, for instance, resell laser disks of the movies they broadcast. >No providers of usenet news >have any agreements between themselves and the posters regarding >copyrights. An author doesn't _need_ an agreement to assert copyright. Were you, somehow, ignorant of that? >Netcom and all the other internet providers receive postings >"free" and a cd-rom manufacturer has the same "right" to use postings as >any other internet provider. Quite correct. The CD-ROM manufacture may _read_ them. Period. -- Lefty (lefty at apple.com) C:.M:.C:., D:.O:.D:. From cknight at crl.com Tue Feb 1 14:20:41 1994 From: cknight at crl.com (Chris Knight) Date: Tue, 1 Feb 94 14:20:41 PST Subject: Archiving mail-lists... In-Reply-To: Message-ID: On Tue, 1 Feb 1994, Kirk Sheppard wrote: > "Master" is the term one uses in place of "Mister" or "Mr." when politely > addressing a male, under the age of majority. > I confess to some doubts as to your intentions of politeness. But, being of open mind I will put it to the test: Mr Sheppard, I am above the "age of majority", and request that you refrain from using an incorrect form of title. -ck From sfi at verity.com Tue Feb 1 14:20:48 1994 From: sfi at verity.com (Stefan Fielding-Isaacs) Date: Tue, 1 Feb 94 14:20:48 PST Subject: archiving on inet Message-ID: <9402012220.AA24439@verity.com> >From: "Perry E. Metzger" > > > > > >Chris Knight says: > >> If all you are concerned with is "Material differnce", then you think > >> it's perfectly ok for me to sell you a good copy of a magazine? By your > >> "logic" (loosely used), you had to pay for the copy, and you had to pay > >> for the original, so what's the difference? The difference is the WILL > >> AND PERMISSION of the author! As the author of this message, I willingly > >> placed it within the net. I HAVE NOT, NOR WILL NOT, GIVE FREE PERMISSION > >> TO A CD-ROM PUBLISHING HOUSE TO PUBLISH MY WORK. > > > >Try to sue for damages when your work is available for free to > >millions of people. The judge will laugh in your face, copyright or > >no. Damages are, after all, related to lost revenue -- if you allow > >anyone who wants to see something for free in one medium, you will > >have a fucking hard time to keep them from examining it in another > >equivalent medium. Usenet is NOT a magazine. Failing to put a > >copyright notice in your work destroys whats left of your ability to > >do anything. I'm sure you can pay a lawyer to sue for you, but this > >isn't exactly one anyone is going to take on contingency. I believe this is completely fallacious. Simply because I don't include a copyright statement _does not_ mean that my material is not copyrighted (look it up). Secondly, the issue at hand is not so much redistribution (I think that can be resolved by attribution) but rather that the redistribution was done for profit. I think that is where you can be hanged (metaphorically speaking). I do not think it wise to defend such an indefensible (morally and legally) position. Perhaps you should reconsider. Stef From lefty at apple.com Tue Feb 1 14:45:29 1994 From: lefty at apple.com (Lefty) Date: Tue, 1 Feb 94 14:45:29 PST Subject: Why is Kirk Sheppard Wasting Our Time? (was Re: Why is Chris Knight aTwerp?) Message-ID: <9402012230.AA24339@internal.apple.com> I have in fact myself received _two_ such _billets doux_ from Kirk "I claim without evidence to be a lawyer, but so far I only play one badly on the net" Sheppard. I've asked his permission three times whether I can repost them, but have gotten no specific response, other than further insults, silliness and blathering. I can't help but wonder why, given his strongly negative reaction to people who try to argue with him, why on earth he might be inclined to pursue the law as a profession. Nor can I help but wonder how seriously I need to take someone who addresses mail to me with the subjects "Why is Lefty a Twerp?" and "Why is Lefty a Twerp and an Idiot?", wherein he complains about ad hominem attacks. I also wonder, given his tendency to call those who _do_ argue with him "twerp" and "idiot", whether he receives many citations for contempt of court. >Is there any chance that this will get back to the discussion at hand, or >are you tired of this toy and trying to find something else to play with? Highly doubtful. I enjoy a battle of wits as much as the next person, but I'm afraid I have to draw the line at an unarmed opponent. -- Lefty (lefty at apple.com) C:.M:.C:., D:.O:.D:. From kshep at netcom.com Tue Feb 1 14:50:41 1994 From: kshep at netcom.com (Kirk Sheppard) Date: Tue, 1 Feb 94 14:50:41 PST Subject: Master v. Mister In-Reply-To: Message-ID: Dear Master Knight, Normally, I would be happy to oblige in using one's requested term of address, however I may make an exception in this case as you want fair play to be one sided. According to Master Knight, it is OK to start with ad hominem attacks, but not to answer them. Also, Master Knight has this devious habit of posting "private mail" on this list. Twice, now I have answered Master Knight's personal insults with a "private" reply so as to ease the burden on the other members of this very active list, and twice Master Knight, shamelessly posts follow-ups to the list. Not very honorable, Master Knight. So no, if I ever have the need to address you again it will be "Master" for you. Kirk Sheppard kshep at netcom.com P. O. Box 30911 "It is Better to Die on Your Feet Than to Bethesda, MD 20824-0911 Live On Your Knees." U.S.A. - Emiliano Zapata On Tue, 1 Feb 1994, Chris Knight wrote: > > > On Tue, 1 Feb 1994, Kirk Sheppard wrote: > > > "Master" is the term one uses in place of "Mister" or "Mr." when politely > > addressing a male, under the age of majority. > > > > I confess to some doubts as to your intentions of politeness. But, being > of open mind I will put it to the test: Mr Sheppard, I am above the "age > of majority", and request that you refrain from using an incorrect form of > title. > > -ck > > > From pmetzger at lehman.com Tue Feb 1 15:05:29 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Tue, 1 Feb 94 15:05:29 PST Subject: archiving on inet In-Reply-To: <9402012220.AA24439@verity.com> Message-ID: <199402012303.SAA03443@snark> Stefan Fielding-Isaacs says: > I believe this is completely fallacious. Simply because I don't include > a copyright statement _does not_ mean that my material is not copyrighted > (look it up). It does change the nature of the damages you can claim and the nature of the process by which you prove copyright, as does registration of the material. > Secondly, the issue at hand is not so much redistribution (I think that > can be resolved by attribution) but rather that the redistribution was > done for profit. I think that is where you can be hanged (metaphorically > speaking). Redistribution of netnews is already done for profit, or haven't you heard of uunet? Perry From kshep at netcom.com Tue Feb 1 15:05:42 1994 From: kshep at netcom.com (Kirk Sheppard) Date: Tue, 1 Feb 94 15:05:42 PST Subject: Why is Chris Knight a Twerp? In-Reply-To: Message-ID: This is a prime example of Master Knight posting "private" e-mail to the list as a method of retaliation and ad hominem attack. Notice that he defames himself by being too lazy to change the "Subject" line. My sincere apology to the readers of this very active list. I will not reply publically to Master Knight any further as this entire thread is not within the list subject. Kirk Sheppard kshep at netcom.com P. O. Box 30911 "It is Better to Die on Your Feet Than to Bethesda, MD 20824-0911 Live On Your Knees." U.S.A. - Emiliano Zapata On Tue, 1 Feb 1994, Chris Knight wrote: > > It sure was short trip for you to go from person to prick. > > My "attacks" have been on your logic. Something that has always been a > prime goal of a debate. Lacking anything intellignet to say, you resort > to the text quoted below, and your attempted personal slight of refering > to me as "Master Knight" in your current posts. > > Is there any chance that this will get back to the discussion at hand, or > are you tired of this toy and trying to find something else to play with? > > If all you have left is attacks, name calling, and rudeness, perhaps you > should find other toys and leave the discussions to adults. > > -ck > > On > Tue, 1 Feb 1994, Kirk Sheppard wrote: > > > Dear Stupid, > > > > Why you are intent on attacking me for no reason is beyond me. I didn't > > attack you personally, what is the matter with you? Also I am not > > interested in gratuitous advice regarding "trying to write sometime". I > > can see why you might be bitter as you obviously lack the intelligence > > and education to make much money writing. > > > > Kirk Sheppard > > > > kshep at netcom.com > > > > P. O. Box 30911 "It is Better to Die on Your Feet Than to > > Bethesda, MD 20824-0911 Live On Your Knees." > > U.S.A. > > - Emiliano Zapata > > > > > > > > From loki at nately.UCSD.EDU Tue Feb 1 15:05:48 1994 From: loki at nately.UCSD.EDU (Lance Cottrell) Date: Tue, 1 Feb 94 15:05:48 PST Subject: SASE Suggestion Message-ID: <9402012306.AA09568@nately.UCSD.EDU> -----BEGIN PGP SIGNED MESSAGE----- I have been meditating on this problem of return addresses, and have a proposal. The remailers can not be allowed to choose the return path, as any corrupted remailer will corrupt the rest of the path. I suggest the following SASE packet format. Notation: A(foo) = foo encrypted to remailer A P = some sort of one use postage token. end is a flag indicating the final destination. x,y,z,b are large random integers. n is a large prime. Packet: This will rout reply from A -> B -> C -> Bob A(P,x,B,B(P,y,C,C(P,z,Bob,end))),A(b,n,message) Upon receiving the packet, A does the following: A decrypts the packet (both parts separately). A calculates a new b' = b^x mod n and encrypts B(b',n,message) So B receives B(P,y,C,C(P,z,Bob,end)),B(b',n,message) C receives C(P,z,Bob,end),C(b'',n,message) Analysis: The message, which would normally be encrypted to Bob, is never transmitted in the clear. Bob can easily compute b'' to confirm that the message was correctly routed, but this reveals no information about the path the message has taken. The first remailer will refuse to deliver the message twice, because of the expired postage token, so the same path will not be reused. So, what do you think? It does require some work from the remailers, but not too much more than now. - ---------------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki at nately.ucsd.edu PGP 2.3 key available by finger or server. "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche - ---------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLU7fRFVkk3dax7hlAQH4MgP9HIQPR3esnHbJuELXtCmTGXvQoLHgoA+L OeW1WOM6WczcOEwzFRsto8k2vrTsSMDPAqhTm+Ylgy83x8ez+yquoKmfFqiNQzWY Vcoy7ng/Jgu9i9snIGlsVdq6cpKTS8YKiR3EmnQrbpXetL7cFBZRN4yJ+dadS77q cT2rY82uzw4= =YTIz -----END PGP SIGNATURE----- From cknight at crl.com Tue Feb 1 15:05:49 1994 From: cknight at crl.com (Chris Knight) Date: Tue, 1 Feb 94 15:05:49 PST Subject: Capt'n Kirk and Major Tom... Both lost in space... In-Reply-To: Message-ID: I did not consider that a flame war, it was just a bit of banter. You seem to lack both a sense of humor, and the intelligence to discern it in others. As for re-posting personal mail, there is nothing unethical about it. Your vehemence on this point just goes to prove how much you wanted to hide your true personality from those on the net. Since you don't seem to want to end this, I will. Post all you want, personal and private. You have proven beyond a doubt that you have no points of view worth discussing, nothing to be learned, and nothing worth replying to. -ck On Tue, 1 Feb 1994, Kirk Sheppard wrote: > Dear Master Knight, > > You have quickly forgotten the crap about sending valium etc. You started > the flame war then by reading my small post literally and started it > today by making personal insults. This is your habit. My habit is to > respond in kind. Also, the trick of reposting private mail to a list > shows the level of your personal ethics. Quite low from this vantage point. > > Kirk Sheppard > > kshep at netcom.com > > P. O. Box 30911 "It is Better to Die on Your Feet Than to > Bethesda, MD 20824-0911 Live On Your Knees." > U.S.A. > - Emiliano Zapata > > > On Tue, 1 Feb 1994, Chris Knight wrote: > > > > > > > On Tue, 1 Feb 1994, Kirk Sheppard wrote: > > > > > This is the second idiotic flame war you have started with me in the last > > > two weeks. > > > > Perhaps you have your mail lists confused. Until only a week ago, I > > was not posting in this echo. Secondly, you started this "war". > > > > > I would never again apologize to you. > > > > There was a first? > > > > > I do take some small pleasure in the fact that you are so lazy that you > > > don't change the subject line when you reply, so on each reply you republish > > > the condition of your being. It gives me a small chuckle each time I read the > > > "truth" of your intellect. > > > > It is truely sad that these are the pleasures in your life. > > > > > > > > > > From mnemonic at eff.org Tue Feb 1 15:20:42 1994 From: mnemonic at eff.org (Mike Godwin) Date: Tue, 1 Feb 94 15:20:42 PST Subject: Archiving mail-lists... In-Reply-To: <199402012121.QAA03308@snark> Message-ID: <199402012316.SAA13735@eff.org> > Yes, you have a copyright over your work -- however, once you've > posted it to the net it is likely practically impossible to restrict > distribution. Practical impossibility != legal impossibility. > Since you've already allowed it to be distributed on > demand to anyone for free it is hard to claim damages if it is > distributed to anyone via some medium you don't like. Hard, yes, but not impossible. Most copyright actions involving works that are not being sold resort to statutory damages. And you can register your copyright *after* the infringement occurs. --Mike From klbarrus at owlnet.rice.edu Tue Feb 1 15:25:29 1994 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Tue, 1 Feb 94 15:25:29 PST Subject: PGP Message-ID: <9402012321.AA07980@wahoo.owlnet.rice.edu> -----BEGIN PGP SIGNED MESSAGE----- >About how many calculations does it take to crack a 1024 bit key? If >someone has limitless time, money, etc., they can break it...but how >many calculations does it take? I did some calculations on this a few months ago, and it works out to be on the order of 4.42 10^29 steps. So then you can figure out how much real time it takes given machine speed. I also made some calculations for other sizes - to get the rest of the article gopher to chaos.bsu.edu and look at Misc/"Bits and Factoring Difficulty" where I have been archiving various cypherpunks posts, apparently flying the face of copyright laws blah blah blah blah. Since I wrote that I give permission for it to be at the gopher site ;) >Also, there is a password used to protect the keyrings. Assuming a >strong password how many calculations does that take to break? Well, if it's an 128 bit IDEA password, and brute force is the fastest way to "break" it, then 2^128 = 3.4 10^38. Karl Barrus klbarrus at owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLU7jtYOA7OpLWtYzAQFV8wQAjugItETGxmxMkXyGN798/9DwUnhpHU7g A7NskB3jBRSFvFJYwp1B/0c80v2I14LjZg1FHU2zlUD2NPza91mSRc0hW4WcY3Sq 2RQjZIUBxz9Fu+4XPEQWT7iFOh+MhGbx60h5QktXDaJaS46QrrsPz2SXaMbdG7iu BiyraoH3mu8= =aMtI -----END PGP SIGNATURE----- From klbarrus at owlnet.rice.edu Tue Feb 1 15:30:42 1994 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Tue, 1 Feb 94 15:30:42 PST Subject: PGP Message-ID: <9402012329.AA08073@wahoo.owlnet.rice.edu> -----BEGIN PGP SIGNED MESSAGE----- >Brute-forcing IDEA takes about as much computation as factoring >something between a 1200 and 3000 bit RSA key (I've heard both >numbers, but I don't know the numbers). So, in the current >implementation, RSA is the weak link! Yes, I think that the turnaround point is right around 1600 bits, at which IDEA is "easier" than RSA. Assuming of course brute force is the fastest way to break IDEA; the fastest (known|published) factoring method runs in time proportional to the formula I typed out, etc. Karl Barrus klbarrus at owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLU7l2IOA7OpLWtYzAQE7fwP6A6ENOTE7dUl0gbqEk17NRLPnExCHa2za HEt3LTfbn/0gpTfrwnKUTCKP3TAvnVJJ/cDFxRR1RkaTyHxA0RvQR/b8SosFK2Uc HEY5I5AqNVUKE9TceDXcBnYmmMbZAIMpdMMTknrn3Eyo1kcfLGTfOInH0wM35Rdl /o/sPMmc23s= =S2+w -----END PGP SIGNATURE----- From jthomas at access.digex.net Tue Feb 1 15:35:29 1994 From: jthomas at access.digex.net (Joe Thomas) Date: Tue, 1 Feb 94 15:35:29 PST Subject: archiving on inet In-Reply-To: <9402012021.AA01756@jazz.hal.com> Message-ID: On Tue, 1 Feb 1994, Jason Zions wrote: > > So answer the question again, what is the > >difference in paying an internet provider for access to usenet, and > >paying a cd-rom provider for access to usenet? > . . . > Better yet, it's the difference between watching a program on HBO when you > are getting that service legally (i.e. paying for it) and buying a tape of > the same program from a friend who has HBO. Whether or not you also have > legal access to HBO, the sale of the tape infringes on the copyright of the > program. Several variations on this analogy have been posted, but I still don't see how it applies to Usenet. If HBO allowed anyone who could receive its signal to pass it along to anyone else, without a prior license agreement, I would say it would have little grounds for trying to prevent the sale of programs taped off HBO. But to attempt to bring this back from misc.legal to cypherpunks territory... Have people here thought about what happens to the concept of intellectual property in an environment of strong cryptography and cheap anonymity? When there's no way for the government to enforce Berne on movies and electronic books, what hope is there for Usenet postings? Joe From nate at VIS.ColoState.EDU Tue Feb 1 15:45:44 1994 From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons) Date: Tue, 1 Feb 94 15:45:44 PST Subject: new remailer online Message-ID: <9402012345.AA05789@vangogh.VIS.ColoState.EDU> -----BEGIN PGP SIGNED MESSAGE----- There is a new anonymous remailer online at: nate at vis.colostate.edu It does not yet support pgp encryption, but it does remail fine. This is also the standard remailer used by by WWW remailer GUI (even if no mailers are checked). I will be releasing a copy of my remailer GUI and software in the next day or so. - -nate sammons - -- +-----------------------------------------------------------------------+ | Nate Sammons | | Colorado State University Computer Visualization Laboratory | | Data Visualization/Interrogation, Modeling, Animation, Rendering | +-----------------------------------------------------------------------+ From hojunya at ecf.toronto.edu Tue Feb 1 16:05:29 1994 From: hojunya at ecf.toronto.edu (HO JUNYA) Date: Tue, 1 Feb 94 16:05:29 PST Subject: "bio-radar"? Message-ID: <94Feb1.190048edt.5810@cannon.ecf.toronto.edu> In the current issue of Defense Electronics, the editor talks about some "bio-radar" technology, in the hands of both the US and the Soviet bloc.. Does anyone know more about this, or know where to get more information? From loki at nately.UCSD.EDU Tue Feb 1 16:10:45 1994 From: loki at nately.UCSD.EDU (Lance Cottrell) Date: Tue, 1 Feb 94 16:10:45 PST Subject: archiving on inet Message-ID: <9402020008.AA09772@nately.UCSD.EDU> This thread seems way off topic. Lance From jim at bilbo.suite.com Tue Feb 1 16:25:29 1994 From: jim at bilbo.suite.com (Jim Miller) Date: Tue, 1 Feb 94 16:25:29 PST Subject: Why is Chris Knight a Twerp? Message-ID: <9402020019.AA02559@bilbo.suite.com> Please take the "archiving mail-list" thread to e-mail. Thank you, Jim_Miller at suite.com From jimn8 at netcom.com Tue Feb 1 16:30:45 1994 From: jimn8 at netcom.com (Jim Nitchals) Date: Tue, 1 Feb 94 16:30:45 PST Subject: archiving on inet In-Reply-To: Message-ID: <199402020030.QAA20097@mail.netcom.com> > > This is not an accurate comparison. A posting on usenet is not the same > item as a program on HBO or the radio. In what way does my internet provider > (netcom) have a "legal" distribution of usenet news, while a cd-rom > provider does not? I've already said it. I own the copyright to my posts, and only permit them to be distributed by Usenet because I can *cancel* and provide expiration dates with my posts. CD-ROMs do not provide these standard Usenet message control features. If I issue a cancel message, it's obvious that I'm asserting control over the further distribution of my content (sites that ignore them notwithstanding.) Any time a CD-ROM is published with my message, and it contains an expiration date or is later cancelled, the publication violates my right as a copyright holder to retract my message. [portions deleted] > No providers of usenet news > have any agreements between themselves and the posters regarding > copyrights. Netcom and all the other internet providers receive postings > "free" and a cd-rom manufacturer has the same "right" to use postings as > any other internet provider. My expiration dates or cancel messages are perfectly reasonable ways to communicate the way in which I'm exercising my copyright. Netcom and other service providers currently honor those communications, but CD-ROM publishers of Usenet news do not. > > Kirk Sheppard > > kshep at netcom.com > > P. O. Box 30911 "It is Better to Die on Your Feet Than to > Bethesda, MD 20824-0911 Live On Your Knees." > U.S.A. > - Emiliano Zapata > From ebrandt at jarthur.Claremont.EDU Tue Feb 1 16:35:30 1994 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Tue, 1 Feb 94 16:35:30 PST Subject: archiving on inet In-Reply-To: <9402011752.AA00225@jazz.hal.com> Message-ID: <9402020035.AA00478@toad.com> > From: Jason Zions > Infringement occurs when you copy those bits onto some medium for > some purpose other than store-and-forward propagation or the allowed > fair-use exceptions; stuffing articles on a CD-ROM and selling them > falls into neither category and hence is an infringement. This is hardly cut-and-dried. Try the defense lawyer's interpretation: recipients of the CD-ROM are leaf nodes; the CD-ROM is a convenient transport medium. Usenet has been propagated over magtape, after all. CD-ROM is the modern equivalent, cheaper to cut than a tape. You seem to be concerned that your words might be stored on a `permanent' medium. You should be. Anything you post is propagated to a vast and unknown number of systems worldwide. *Somebody* is going to archive it, maybe back it up to WORM. You know this already, so what's the big deal about a CD-ROM? I agree with your basic contention that authors of Usenet postings retain copyright minus some concession to the nature of the medium. But your concessions are unrealistically limited. In the real world, you can't count on the destruction of every copy of your `ephemeral' article. You can't know or control the media of propagation. You can't expect the RFCs to be followed to the letter -- the bulk of news systems these days are probably neighborhood BBSes who run their gateway software out of the box. This is Usenet; post if you can accept it. Eli ebrandt at jarthur.claremont.edu From jimn8 at netcom.com Tue Feb 1 16:40:47 1994 From: jimn8 at netcom.com (Jim Nitchals) Date: Tue, 1 Feb 94 16:40:47 PST Subject: archiving on inet In-Reply-To: <199402012131.QAA03337@snark> Message-ID: <199402020036.QAA20961@mail.netcom.com> > > > Jason Zions says: [portions deleted] > > > I'm struggling with drawing an appropriate distinction between CD-ROM as > > newsfeed medium and CD-ROM as archive medium. > > Maybe you are struggling because there is no reasonable way to make > the distinction? There is. Copyright 1994 James Nitchals. Duplication and redistribution rights permitted only until the expiration date or issuance of a cancel message by the author. CD-ROM publishers cannot honor the request except by reissuing the CD-ROM without my content. Anyone who backs up their home directory is safe, but if they redistribute my article after it's expired or cancelled, they are in violation of my copyright. From jazz at hal.com Tue Feb 1 16:40:53 1994 From: jazz at hal.com (Jason Zions) Date: Tue, 1 Feb 94 16:40:53 PST Subject: The Death of Statutory Compensation for Intellectual Property (was pissing contest) In-Reply-To: Message-ID: <9402020038.AA02579@jazz.hal.com> >Have people here thought about what happens to the concept of intellectual >property in an environment of strong cryptography and cheap anonymity? >When there's no way for the government to enforce Berne on movies and >electronic books, what hope is there for Usenet postings? I was wondering when it was going to come around to this. Surprise. Within ten years, the entire concept of intellectual property will be radically altered, if not completely gone. The whole thing will become so completely unenforceable that something will give; I'm not sure what, but something. At the Austin Crypto Conference, John Perry Barlow was asked what he thought would happen to copyright. As I recall, he said something along the lines of this: that compensation for intellectual property would cease to be a thing of law and become a thing of interpersonal relationships. That people would pay the producers of stuff they liked as an incentive for them to produce more. That the ability of the Internet and its services to make widely-separated people into a community, with all the emotions and duties humans tend to experience in communities, would ensure a kind of darwinism amongst the "stuff" out there; the stuff people liked would get supported out of that sense of community, and the stuff people didn't like would not. Would you pay $895 for a CD-ROM version of the Oxford Unabridged Dictionary? If you could get it for almost nothing on the net, would you be willing to send a check for $10 to the Oxford folks who made it possible? Shareware is the future of just about all intellectual property. Once a movie is released on video, it will be cloned and copied to rapidly that they'll sell, what, a few hundred? Everyone else will trade perfect copies around. There are only a few ways the studios could get huge bucks: 1) Shareware. Ask each owner of a copy to send a few bucks. Personally, I'd rather send it to the director and actors and crew than to the back-office overhead, but what the hell. 2) Stick with theatrical release. It'll get swiped from there too; film is so expensive that the first users of really high-quality digital video will be the studios, at which point it's just a question of dubbing the digital bits (no film involved anymore). 3) Charge out the wazoo for the video tapes. Doesn't matter; the Blockbuster's of the world will pay for one copy, which will be rented and cloned. 4) Serializing digital copies to track down the "leaker". All you need is two copies from different sources to find steganographically-hidden bits or to produce a combination of the two that has a unique fingerprint that doesn't match anything already shipping. Within ten years it's all over. Until then, until societal changes occur to help creative people get paid the money they deserve for the fruits of their labors, try and stay honest with the law as it is, eh? It's not that expensive to do it by the book (send your check to the copyright clearance center for printed matter, for example) and it's the primary feedback mechanism you have to the creators of the works you like. Jason Copyright 1994 Jason Zions. You can copy this to propagate cypherpunks mailing list as email or local newsgroups; no permanent digital optical copies allowed (except for backup purposes, which I can't restrict anyway; see relevant case law). From mg5n+ at andrew.cmu.edu Tue Feb 1 16:50:47 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Tue, 1 Feb 94 16:50:47 PST Subject: Archiving on inet Message-ID: Wow, this usenet copyright issue has touched off a pretty heated debate. Let me just make a few points: In most usenet areas, there are no limitations on who may receive the group. By posting to such an area, you imply that you intend your post to be received by an unrestricted audience. This, of course, includes the possibility that some readers of the newsfeed will be reading it in a time-delayed manner, such as a dialup newsfeed over slip, uucp, or other protocol. A CD-ROM is just another form of delayed newsfeed. There are many areas availiable where restrictions are placed upon who may receive the feed. Many mailing lists, such as extropians, have this policy. Anyone receiving that list agrees that they will not redistribute the messages, and that includes selling CD-ROMs. If you have something which you would like to limit the distribution of, there are many forums availiable where the readers consent that they will abide by such a policy. The general readers of usenet have not consented to any such agreement. What offends me is that some hypocritical people would send a message to an area that they know is public domain, and then complain that they didn't want their message distributed. When you post, you should decide weather or not you want it public domain. But don't complain if you change your mind after the fact. I reccomend that everyone who is concerned about the distribution of some document that you wrote, (ie research paper, commentary, etc) post a message in a public forum giving a brief overview, and then state that it is copyrighted, and that anyone who agrees to respect your terms of non-distribution should send you email and that you will send them a copy. This also allows you to place an expiration time limit on it, so that someone won't find it reading outdated usenet news. To continue Lefty's cable TV analogy: A cable TV company can charge you a fee for assisting you in receiving a publicly availiable signal. However, they do not have copyright on that signal - they can't stop you from buying your own antenna, nor can they stop a competing cable company (if the municipality allows it). The cable company is selling you their assistance in receiving a publicly availiable signal. They do not own that signal or the copyright to it. They are merely a common carrier of the communication. In the same way, internet service companies like netcom are merely providing a service which aids you in receiving a publicly availiable signal. Selling the netnews feed either on a CD-ROM is no different. They are not selling the posts - they are selling their communications services which allow you to receive it. They have no copyright on the posts. They are NOT SELLING COPYRIGHTED MATERIAL - they are SELLING A COMMUNICATIONS SERVICE. If a TV station was to take the broadcast of a competing station, add their own commercials etc, and rebroadcasts it, then we have copyright infringement. They are taking someone else's material and using it for their own benefit - here we have copyright infringement. The cable company does not do this - they are simply distributing the signal unaltered, commercial advertisements and all. In the same way, if someone is selling complete, unaltered archives of usenet, it is a communication service. If they're taking posts, modifying for their own purposes, and selling at a profit, we have the possibility of copyright infringement. I hope you all understand the difference. From frissell at panix.com Tue Feb 1 17:00:49 1994 From: frissell at panix.com (Duncan Frissell) Date: Tue, 1 Feb 94 17:00:49 PST Subject: Cypherpunk article in NY Message-ID: <199402020055.AA18359@panix.com> Life in Cyberspace - Joshua Quittner New York Newsday - Page 59 Tuesday, 01 February 1994 CODING UP A BIT OF PRIVACY MOUNTAIN VIEW, Calif. This must be how the Founding Fathers looked when they hacked out the Constitution : A roomful of young men, mostly--frazzled hair, eager eyes, wild beards, arms flailing and fingers jabbing in air, reaching for big ideas. You can't help but feel it; urgency tempers their voices. The earnest men plan and argue in this corporate conference room as the last sun rays of a winter Saturday afternoon fade in through a skylight. Time is running out for the Cypherpunks. There is much work to be done before the information highway arrives. The information highway --- that 500-channel shopping mall/cineplex championed by cable and telephone companies --- is a noxious concept to the people in this room. They are not technophobes or Luddites, these Cypherpunks, Instead, they are a collection of clever computer programmers, engineers and wire heads from some of the nation's best-known Silicon Valley software houses and hardware shops. This is their central question: In a future world where all information is centralized on a network, where all information is tracked by the bit, where every purchase you make and every communication can be monitored by corporate America, how does privacy survive? If you go to the bookstore now and buy a book, you can pay in cash. No one knows your name or what you purchased. "What happens to cash transactions on the information highway?" they ask. The Cypherpunks believe that they can preserve your privacy through good cyphers, or codes. But they must hurry, must get their codes out and their networks up and running. "The whole information highway thing is now part of the public eye," explain Eric Hughes, a founder of the Cypherpunk movement. "If we don't change it now, it'll be impossible later." The Cypherpunks know what technology is capable of. We visit them today because they represent one edge of the national debate on the structure of the information highway. And as we all know, extreme positions help define the middle. Many of the Cypherpunks have been heavy Internet users for years and hope to preserve the communal spirit of that freewheeling world of interconnected computer networks. They dread the coming commercial network of televisions and computers, saying it will displace the Internet and destroy many of the freedoms they now enjoy. So the Cypherpunks, with the kind of zeal they professionally bring to marathon, 72-hour sessions hacking computer code, are plotting to keep free networks alive. That's "free" in the sense of unfettered, unmonitored, uncensored. One way they're going about it is by spreading easy-to-use, cheap cryptography. Cryptography is the science of keeping two-way communication private. Computers, it turns out, are revolutionary cryptographic tools, able to encode and decode files quickly. For the first time, virtually unbreakable codes are now possible, thanks to computers. The Cypherpunks post cryptographic software on the Internet where anyone can access it, and can encode their communications, including electronic mail, pictures and video. The the U.S. government is concerned, as governments always are, about the spread of powerful cryptography (terrorists could use it, kidnappers could use it, drug dealers could use it, all of them on cellular phones that encode conversations). It currently is pushing its own commercial cryptographic standard, through a special chip known as the Clipper. The chip is reviled by Cypherpunks and other civil libertarians because it provides a back door that law-enforcement agencies could enter, with the proper warrants, for surveillance. By getting good, unbreakable cryptography out there now, the Cypherpunks hope, whatever the government finally decides will be moot. Software has a wonderful property, the Cypherpunks are fond of saying: Once it's created, it can never be destroyed. It can be copied infinitely, from computer to computer, spreading like a secret. Come what may, unbreakable Cypherpunk code, and Cypherpunk networks, will be out there forever, they hope. But just to be safe, the Cypherpunks are toying with different network-related plans to create an economy of "digicash" --- network money that, like the dollars in your pocket, isn't tied to a user's credit cards or other personal identification. Digicash will help pay for Cypherpunk networks and will allow people to purchase goods without revealing their identity. "I'm starting a bank, and it's not going to be a U.S. bank," Hughes says. He standing at the whiteboard now. A strawberry-blond ponytail dangles down his back and he grasps a magic marker in his hand. "We have several long-term strategies, one of which is the elimination of central banks." He tells the assembled crowd what they already know. Heads nod. Some people take notes. Hughes is a self-employed programmer in Berkeley. His hand flies across the whiteboard, sketching out a schematic diagram, showing how his bank will operate. The bank will store depositors' money (he's thinking a $200 minimum deposit) and disburse payments to anyone --- all over the Internet. It will be based abroad, maybe in Mexico. A Cypherpunk network bank is one way to pay for a network of truly encrypted, private communications, you see. "Is this going to lead the way to portable laptop ATM machines?" someone else asks. "First Bank of Cyberspace!" yells one person. "First Internet bank!" yells another. "The Nth National Bank!" Laughter. Billy goat beards bob. There is much work to be done. ******************************* Net Tips If you have e-mail access to the Internet, you can subscribe free to the Cypherpunks mailing list, which circulates to about 750 people daily. Send an e-mail message to: cypherpunks-request at toad.com with the word " Subscribe" and your name in body of message. More information about cryptography, as well as cryptographic software, can be obtained over the Internet by ftp'ing to: ftp.soda.berkeley.edu ******************************** Thanks to Lois for entering this article. --- WinQwk 2.0b#1165 From jim at bilbo.suite.com Tue Feb 1 17:20:48 1994 From: jim at bilbo.suite.com (Jim Miller) Date: Tue, 1 Feb 94 17:20:48 PST Subject: SASE Suggestion Message-ID: <9402020114.AA03481@bilbo.suite.com> Lance Cottrell writes: > I have been meditating on this problem of return > addresses, and have a proposal. The remailers > can not be allowed to choose the return path, > as any corrupted remailer will corrupt the rest > of the path. As I understand it, the remailers don't "chose" the return path, Bob (the sender of the original message) choses the return path when he creates the SASE. All the remailers do is interpret the part of the SASE that becomes readable to them after decrypting the SASE portion sent to them from the previous hop. If all is working, what becomes readable is the address of the next hop (closer to Bob) and some misc other stuff (postage, maybe, and perhaps another encryption key). Am I not understanding something correctly? Jim_Miller at suite.com From lefty at apple.com Tue Feb 1 17:25:31 1994 From: lefty at apple.com (Lefty) Date: Tue, 1 Feb 94 17:25:31 PST Subject: Another Request Message-ID: <9402020106.AA27839@internal.apple.com> Can anyone give me a pointer to where I might find information about Kerberos? -- Lefty (lefty at apple.com) C:.M:.C:., D:.O:.D:. From lefty at apple.com Tue Feb 1 17:25:47 1994 From: lefty at apple.com (Lefty) Date: Tue, 1 Feb 94 17:25:47 PST Subject: A Request Message-ID: <9402020106.AA27836@internal.apple.com> A few weeks ago, an ad from Microsoft looking for a staff cryptographic expert was posted. If anyone saved a copy, can they please forward it to me? -- Lefty (lefty at apple.com) C:.M:.C:., D:.O:.D:. From tcmay at netcom.com Tue Feb 1 17:25:53 1994 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 1 Feb 94 17:25:53 PST Subject: archiving on inet In-Reply-To: Message-ID: <199402020123.RAA16841@mail.netcom.com> Boy, this has been one of the most contentious, arguing-in-circles thread I've seen in a long time. I was getting ready to delete all these posts by lawyers, semi-lawyers, wannabee-lawyers, and non-lawyers when I ran across this nice and concise post by Joe Thomas: > But to attempt to bring this back from misc.legal to cypherpunks territory... > Have people here thought about what happens to the concept of intellectual > property in an environment of strong cryptography and cheap anonymity? > When there's no way for the government to enforce Berne on movies and > electronic books, what hope is there for Usenet postings? > > Joe Exactly! The copyright laws, confusing as they may be, are basically unenforceable for _private_ and _mostly private_ behaviors. Xeroxing books, sheet music, and the like is done routinely--stand in a copy shop for a while and watch what happens. And these things are indisputably violations of copyright (there is a "grey zone" for short copying jobs, under the "fair use" interpretatins, but certainly not for copying entire chapters or books, or sheet music). Ditto for copying software, as we all know. Copying CDs onto tapes is a murkier issue, because of the recent revisions to the laws and the so-called "tape tax," which collects a royalty on blank tape while allowing essentially unlimited copying for _personal_ use (e.g., I can safely tape CDs onto DAT so long as I don't then _sell_ them). Where the rubber meets the road on all this stuff is when a visible, public situation occurs--the college instructor who makes Xerox copies of a textbook (not his own, but maybe even that is a violation) and distributes or sells them to a class, the musician in a public concert who is seen with piles of Xeroxed sheet music, the guy selling dubbed videos at a flea market, the corporation buying one copy of a program and then duplicating it for 30 employees, etc. In these cases, a whistleblower can call in the Music Police (don't know their real name), the Data Narcs (SPA), etc., and some action _may_ be taken. (Rarely, for many reasons.) The hair-splitting about whether making backup copies of Usenet constitutes any kind of violation is not all that useful. The issue is what happens when--as is inevitable--folks sell compilations of other people's postings. Indeed, there was a raging debate on this several years ago when Brad Templeton was planning to sell a book of the best jokes he's seen in rec.humor.funny. Maybe the book even came out....I never did hear the outcome. Anyone know? With strong crypto and anonymous systems, few actions will be publically visible enough to allow enforcement and sanctions. Copyrighted material may be sent through remailers to protect the source (recall the "Information Liberation Front"). Ditto for other kinds of "software." A brave new world. My fear is that the NII will be structured so as to limit crypto use with a public rationale of preventing these kinds of abuse (the private rationale being the NSA/FBI/national security state sorts of things). --Tim May, who's not a lawyer and doesn't want to become one (and who hates to see fine minds devoted to the credo "Cypherpunks study law") -- .......................................................................... 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. From klbarrus at owlnet.rice.edu Tue Feb 1 17:40:48 1994 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Tue, 1 Feb 94 17:40:48 PST Subject: REMAIL: ping, script Message-ID: <9402020140.AA07524@screech.owlnet.rice.edu> -----BEGIN PGP SIGNED MESSAGE----- I've been catching up on past messages; I see there was some interest in scripts for pinging remailers, and some questions about how many there are, etc. Here is the data file and script I use to ping non-special remailers. Note: remailer #12 will only remail if you attach "digital cash", remailer #20 batches until midnight, remailer #21 requires encryption. Save this as "remailer.data" - ----------8< cut here >8---------- 01:n:remailer at chaos.bsu.edu 02:n:nowhere at bsu-cs.bsu.edu 03:n:hh at cicada.berkeley.edu 04:n:hh at pmantis.berkeley.edu 05:n:hh at soda.berkeley.edu 06:n:00x at uclink.berkeley.edu 07:y:hal at alumni.caltech.edu 08:y:ebrandt at jarthur.claremont.edu 09:y:catalyst at netcom.com 10:y:sameer at netcom.com 11:y:remailer at rebma.mn.org 12:y:elee6ue at rosebud.ee.uh.edu 13:y:elee7h5 at rosebud.ee.uh.edu 14:y:hfinney at shell.portal.com 15:y:sameer at soda.berkeley.edu 16:y:remail at tamsun.tamu.edu 17:y:remail at tamaix.tamu.edu 18:y:remailer at utter.dis.org 19:y:remailer at entropy.linet.org 20:y:elee9sf at menudo.uh.edu 21:s:remail at extropia.wimsey.com - ----------8< cut here >8---------- and then the script - ----------8< cut here >8---------- #!/usr/local/bin/perl #ping the anonymous remailers #Karl L. Barrus open (IN, "remailer.data") || die "Can't open remailer.data\n"; while () { ($num, $rest) = split(/:/, $_, 2); $remailers{$num} = $rest; } close (IN); #ping all remailers except special ones foreach $i (sort keys(%remailers)) { ($mode, $name) = split(/:/, $remailers{$i}); print "remail via $name" if $mode ne "s"; open (MAIL, "| /usr/lib/sendmail " . $name); print MAIL "To: " . $name; print MAIL "From: nobody\n"; print MAIL "Subject: test " . $i . "\n"; print MAIL "Request-Remailing-To: klbarrus at owlnet.rice.edu\n"; print MAIL "\ntesting :-)\n"; close (MAIL); sleep 5; } - ----------8< cut here >8---------- -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLU8EUIOA7OpLWtYzAQFbjAQAhMj765Rd7r4BgRkXnRKmSRuJRphyNz/6 3Q7N4v+rQME44ZtiufDkxEyxj/M7s+bMXRqP+2n+gXVSaAgXq/g2CFrVisyvL70P 6RS//XHaoThJHRPp9x0/p9fO2MMeqOct0YXtYWi2C9LlU8B9/smjm7/Qg6q65tgk D3FgR6YAlZI= =bl8B -----END PGP SIGNATURE----- From warlord at MIT.EDU Tue Feb 1 18:35:28 1994 From: warlord at MIT.EDU (Derek Atkins) Date: Tue, 1 Feb 94 18:35:28 PST Subject: Another Request In-Reply-To: <9402020106.AA27839@internal.apple.com> Message-ID: <9402020234.AA14461@toxicwaste.media.mit.edu> You can obtain a lot of documentation from the anonymous ftp site: ftp://athena-dist.mit.edu/pub/kerberos/doc There are a lot of papers, docs, etc in that directory. Hope this helps. -derek From jthomas at access.digex.net Tue Feb 1 18:55:28 1994 From: jthomas at access.digex.net (Joe Thomas) Date: Tue, 1 Feb 94 18:55:28 PST Subject: The Death of Statutory Compensation for Intellectual Property (was pissing contest) In-Reply-To: <9402020038.AA02579@jazz.hal.com> Message-ID: On Tue, 1 Feb 1994, Jason Zions wrote: > Surprise. Within ten years, the entire concept of intellectual property will > be radically altered, if not completely gone. The whole thing will become so > completely unenforceable that something will give; I'm not sure what, but > something. Here's my slant on it: Without government coercion, "intellectual property" is limited to its only natural form -- a secret. If you don't want everyone to have certain information, don't tell anyone. At the very least, don't tell anyone who has no incentive to keep the information to himself. > At the Austin Crypto Conference, John Perry Barlow was asked what he thought > would happen to copyright. As I recall, he said something along the lines of > this: that compensation for intellectual property would cease to be a thing > of law and become a thing of interpersonal relationships. That people would > pay the producers of stuff they liked as an incentive for them to produce > more. That the ability of the Internet and its services to make > widely-separated people into a community, with all the emotions and duties > humans tend to experience in communities, would ensure a kind of darwinism > amongst the "stuff" out there; the stuff people liked would get supported > out of that sense of community, and the stuff people didn't like would not. EFF Co-Founder Solves Prisoner's Dilemma Game Theorists Had Neglected "Community Spirit," Says Barlow > Shareware is the future of just about all intellectual property. Maybe. I wouldn't expect to get rich on it, though... > There are only a few ways the studios could get huge bucks: [most of list deleted] > 4) Serializing digital copies to track down the "leaker". All you need is > two copies from different sources to find steganographically-hidden bits or > to produce a combination of the two that has a unique fingerprint that > doesn't match anything already shipping. Is this really a settled issue? I'll bet I could devise a scheme for tagging a large number of copies of an image, such that the information available to a cheater from two images isn't enough to produce an untraceable copy. Such a scheme would entail some image degradation -- if you didn't mess with some visible bits in each picture, a cheater would only have to randomize all the "invisible" bits. But of course this stuff is only useful if the work is distributed non-anonymously in the first place. It doesn't do QVC/Paramount much good to know that an2538295 was the one responsible for redistributing 10,000 copies of Star Trek L. Computer software and other interactive works should fare better, since the publishers can restrict their distribution to secure machines on a network. Customers would pay to use the software, but never receive a copy of their own. Reverse-engineering even "Dragon's Lair"-type games would be non-trivial and error-prone. And after getting ripped off for a bad interactive copy, most people would probably be happy to pay a premium for the real thing. Joe From ebrandt at jarthur.Claremont.EDU Tue Feb 1 19:30:49 1994 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Tue, 1 Feb 94 19:30:49 PST Subject: fwd: Canadian gov't eavesdropping In-Reply-To: <94Feb1.201622est.83288(2)@ivory.educom.edu> Message-ID: <9402020326.AA05527@toad.com> > Date: Tue, 1 Feb 1994 20:21:46 -0500 [...] > HIGH-TECH SNOOP GADGET. A super-secret branch of the Canadian Security > Intelligence Service has awarded three contracts to a Montreal firm to make > equipment that can quickly isolate key words and phrases from millions of > airborne phone, fax, radio signals and other transmissions. The hardware > has the "Orwellian potential to sweep through ... and keep records of all > conversations," said one CSIS critic. (CTV National News, 01/31/94 11:00 > pm). Dunno how feasible this kind of keyword recognition presently is, but here's another reason to encrypt. > EDUPAGE. To subscribe to Edupage send e-mail to listproc at educom.edu, > containing the following text: SUB EDUPAGE yourfirstname yourlastname. To Eli ebrandt at jarthur.claremont.edu From jim at bilbo.suite.com Tue Feb 1 21:20:49 1994 From: jim at bilbo.suite.com (Jim Miller) Date: Tue, 1 Feb 94 21:20:49 PST Subject: 2-way anonymous via SASE Message-ID: <9402020513.AA07003@bilbo.suite.com> Jon Boone writes: > Now, what is this SASE? Apparently it is either a) a > fully-specified return-path (presumably a chain of > anonymous ids at various remailers), b) a next-hop > address (anonymousid at the next remailer that "knows" > where to send the message), or c) some combination of the > previous two. > > Is there another possibility that I have missed? > The SASE's that I've been describing are not type a, b, or c. "b" is closest, except the next-hop address is not an "anonymousid at the next remailer", rather, it is simply the e-mail address of the next remailer to send to. The SASE is structured somewhat like a message enclosed in a bunch of nested digital envelopes. If you don't understand "message enclosed in a bunch of nested digital envelopes" then you will have a hard time understanding SASE's (at least the type of SASE's I'm describing). ** Using Nested Envelopes for sending anonymous e-mail (simplified) ** Say Bob wants to send a message to Ted, routing the message through R1 and R2, and finally to Ted. First of all, Bob needs to know the e-mail address of R1, R2, and Ted. Bob also needs to know the public-key of R1, and R2. He will probably also want to know the public-key of Ted, but that is not required. [Notice that I did *not* say the Bob needed to have an anonymous account id at each of the remailers. There are different types of remailers. Some provide anonymous accounts, others simple forward e-mail. In the description below, I am referring to remailers that just forward e-mail.] To send to Ted, Bob constructs the following: (not considering SASE's yet) R1_PK(R2-addr, R2_PK(Ted-addr, Ted_PK(message))) where: XX_PK(stuff) stuff encrypted with XX's public-key XX-addr e-mail address of XX Bob sends this mess to R1. >From R1's point of view, R1 receives R1_PK(stuff1) R1 decrypts "stuff1" and gets: R2-addr, R2_PK(stuff2) R1, strips off "R2-addr" and e-mails R2_PK(stuff2) to "R2-addr". R2 receives R2_PK(stuff2) R2 decrypts "stuff2" and gets Ted-addr, Ted_PK(message) R2 strips off "Ted-addr" and e-mails Ted_PK(message) to "Ted-addr". Ted receives Ted_PK(message) Ted decrypts it, and gets Bob's message. As you can see, you need to use a special type of remailer to get this to work. Not all remailers support the "decrypt, strip, and re-send" operation. You seem to be familiar with the type of remailer that sets up an anonymizing "account" (e.g. an12345 at anon.penet.fi). These "Penet-style" remailers give you an easy mechanism for doing 2-way anonymous communication. Ted can use ordinary e-mail commands to send a reply addressed to "an12345 at anon.penet.fi". The "decrypt, strip, and re-send" remailers do not provide a trivial way to send reply messages. The SASE mechanism is an attempt to extend these types of remailers so Ted can reply to whomever sent him the anonymous message (Ted doesn't know anything about the original sender, not even a anonymous id. Ted only knows that R2 forwarded a message to him). Jim_Miller at suite.com From jim at bilbo.suite.com Tue Feb 1 21:40:48 1994 From: jim at bilbo.suite.com (Jim Miller) Date: Tue, 1 Feb 94 21:40:48 PST Subject: 2-way anonymous via SASE Message-ID: <9402020534.AA07060@bilbo.suite.com> I finally got around to downloading and reading the remailer stuff from the cypherpunks ftp site*. I could have saved myself some embarrassment if I had read it before posting my "original" SASE idea. The file pub/cypherpunks/remailer/hals.instructions describes a mechanism that is basically a simplified SASE. Oh well... Jim_Miller at suite.com --------- *ftp soda.berkeley.edu From nobody at qwerty.org Tue Feb 1 22:10:49 1994 From: nobody at qwerty.org (nobody at qwerty.org) Date: Tue, 1 Feb 94 22:10:49 PST Subject: New Remailer Up. Message-ID: <199402020607.WAA29302@mail.netcom.com> -----BEGIN PGP SIGNED MESSAGE----- Greetings. New remailer: qwerty at netcom.com. No logs. Only a "counter" that works by appending the word "R" or "ER" to a text file so I can get an idea if anyone is using it. However, I'm sure the Netcom and other site's mail logs will be enough to track serious abusers of anonymity down, without my help. This remailer is dedicated to honest people who desire PRIVACY. (The extra "-" and "space" characters at the beginning of some lines are an artifact of my signing this with PGP). Accepts standard, :: Request-Remailing-To: address (space) message or standard, :: Encrypted:PGP (blank line) - -----BEGIN PGP MESSAGE----- Version: 2.3 Blah blah blah. - -----END PGP MESSAGE----- (blank line) Optional message here. in which the first two lines of the decrypted message contains, :: Request-Remailing-To: address (blank line) Spelling mistakes will land mail in my mail box where I will emotionlessly delete them. Leaving out the blank lines may cause messages to dissapear. Public key for Qwerty Remailer , - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQCNAi1NtgAAAAEEALD07N5RllpklGhOQaiYtRupb+8Jm1M34ya8rxmcNUCVndcb JgH9EW1Z2VvkJ3vTcEOOBK9jM/HCIGDqBbQZR8VOLbLNOD7VQIzTpyTOmZJCMSZG bqZtRtP6KDtMcTx1SgHq9LiRNz5YUyB3WOV963y8W/x00QS4yGkgCDZkVQXZAAUR tCNRd2VydHkgUmVtYWlsZXIgPHF3ZXJ0eUBuZXRjb20uY29tPokAlQIFEC1OzEgE sxus60J9UQEB224D/jUcYRnXmIj9nt4Y7sjGYTmO+v7b9W+rsxYLn6+hCGmx5iQJ zPr3ggvm8ylBZnNp3WUxssDlb9GyiK801vzm6HDXWd/yCeGXHX7YB2DDFd5WrK70 /XGTMGv3gvNnExIM+UVv5tl8y/YXOfeLWWGttD6a60MkUNxAOGT9qBsUTqJNiQCV AgUQLU3TdWkgCDZkVQXZAQH1ygP/TCY7T0PdNVRUVbEpN9YsbxFKhFT/7+hZTySr Md0j2GrObjcRc7aa0c9lEZrtKpaDCJkgF+7k20z1eQpw7zD/dO+ZsSqni62TLGYa pdTsAiYbev90Nb+1S2ST36KvIgJSmQS6zvgpToTRpGwYhJhqTZhTo8Z2U5ufb+SF TsNMd0Q= =BXnK - -----END PGP PUBLIC KEY BLOCK----- See the PGP FAQ for how to use encrypted remailers. Send mail to na38138 at anon.penet.fi with subject "Bomb me!" for Gary Edstrom's PGP FAQ and my "Here's How to MacPGP!" guide. That's NA (not AN), thirty-eight, one-thirty-eight. Thanks to Hal Finney for sending me updated perl scripts and a working copy of UNIX PGP2.3a. I am looking into ViaCrypt UNIX PGP 2.4 as well. Send mail regarding the remailer to qwerty at netcom.com. -Xenon -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLU77FgSzG6zrQn1RAQHlvgQAj2S4bYB+5dEDubfzk8etdBOSbehxfF/o B8ycAHgbHjs0SI9HEb0Xm9RJP+ZLtFfD8J7KgOWe0cJlWdy8NKwJxh55Uqn6yiQn IHB2M9x51nXD3ySCIH8f2USXuHYj8qiInzvQwP6naNiC0vU9E+4ab02Th+IbC8zL n9Jthe+vTf8= =MEvY -----END PGP SIGNATURE----- From nobody at qwerty.org Tue Feb 1 22:55:29 1994 From: nobody at qwerty.org (nobody at qwerty.org) Date: Tue, 1 Feb 94 22:55:29 PST Subject: SuperPing1.2 Message-ID: <199402020651.WAA05123@mail.netcom.com> This may not be elegant, but it works well in my account. It checks the entire Cypherpunk remailer network connections and is user friendly. -Xenon #!/usr/bin/perl # Change this to reflect where your system has perl. # SuperPing version 1.2: Ping Cyperpunk remailer connections. # Now pings in both directions, as I have learned they are NOT equivalent. # Brought to you by Xenon . # Thanks to Alan Barrett for teaching me some perl. # Warning: outputs ~40 e-mails at a time. May give "too many processes" # error towards the end if you haven't killed all of your stopped jobs. # Increase the sleep(sec) time if needed. # Be careful. If mail bounces between any two remailers in either # direction, "Mr. Remailer Operator" will obtain a full mailbox! # To test the program, comment out all the remailers in the list and add # YOUR address at least three times to the list of "remailers". # You MUST make a file called .PingFile that contains: #:: #Request-Remailing-To: your.address # #Ping! # #-----Begin Test----- #Test #-----End Test----- # Will also function as a convenient method to shut down all remailers at # once by making .PingFile 500K instead of 1K. Not recommended if you # value your life ;-). # List of remailers (not complete). Make any line a comment to remove that # line's remailer. cicada and pmantis are not meant for heavy traffic so I # have removed them. Soda is commented for no particular reason. @Rm = ( "catalyst at netcom.com", "remailer at dis.org", "ebrandt at jarthur.claremont.edu", "remailer at merde.dis.org", "qwerty at netcom.com", "elee7h5 at rosebud.ee.uh.edu", "hfinney at shell.portal.com", #"hh at soda.berkeley.edu", ); #Nicknames for output and subject lines. @Nick = ( "catalyst", "dis.org", "jarthur", "merde", "qwerty", "rosebud", "shell", #"soda", ); # Select a marking character for this SuperPing session. @Mark = ("A","B","C","D","E","F","G","H","I","J","K","L","M","N","O", "P","Q","R","S","T","U","V","W","X","Y","Z"); srand(time); $M = $Mark[rand(26)]; # Strings, since lines got too long below. # Obviously this could be written better using sendmail but I'm writing # perl code without KNOWING any perl. $A = "(echo \"::\" ; echo \"Request-Remailing-To: "; $B = " ; echo \"\" ; cat .PingFile) | mail -s \"$M."; # Send a "Ping!" between all combinations of two remailers, in both # directions. $Num is a count that ends up in the Subject line. Each number # is used twice, with a < and > telling which direction the mail went. Change # "system" to "print" to see the Unix commands being produced. foreach $Sec (0..$#Rm) { foreach $First ($Sec+1..$#Rm) { $Num++ ; $C = " $Nick[$First] > $Nick[$Sec]\" " ; system "$A$Rm[$Sec]\"$B$Num$C$Rm[$First]"; print "$M.$Num $Nick[$First] > $Nick[$Sec]\n"; sleep(1) ; $C = " $Nick[$First] < $Nick[$Sec]\" " ; system "$A$Rm[$First]\"$B$Num$C$Rm[$Sec]"; print "$M.$Num $Nick[$First] < $Nick[$Sec]\n"; sleep(1) ; } } # Output (with only catalyst, qwerty and rosebud checked) looks like this: # S.1 qwerty > catalyst # S.1 qwerty < catalyst # S.2 rosebud > catalyst # S.2 rosebud < catalyst # S.3 rosebud > qwerty # S.3 rosebud < qwerty # These are printed out as the program progresses and they also appear as # the Subject of each piece of mail. # alias g '(grep Subject: /usr/spool/mail/n/name | sort -t. +1 -n) | more' # will make the command "g" give a list of received pings, in order. /n/name # is your part of the mail spool. You should also check that the received # pings really came from the second remailer instead of getting short # circuited by the first remailer. # Sample output mail as received by a remailer: # #From: Your name #Message-Id: #To: qwerty at netcom.com #Subject: S.1 qwerty > catalyst #Status: R # #:: #Request-Remailing-To: catalyst at netcom.com # #:: #Request-Remailing-To: your.address # #Ping! # #-----Begin Test----- #Test #-----End Test----- From ritter at cactus.org Tue Feb 1 23:25:29 1994 From: ritter at cactus.org (Terry Ritter) Date: Tue, 1 Feb 94 23:25:29 PST Subject: NxM DES Message-ID: <9402020724.AA29200@cactus.org> Ritter Software Engineering 2609 Choctaw Trail Austin, Texas 78745 (512) 892-0494, ritter at cactus.org Strong Block Ciphers from Weak Ones: NxM DES A New Class of DES Operating Modes Terry Ritter January 31, 1994 Introduction Many security vendors are now preparing a new generation of software and hardware products. Given the well-known criticism of DES, and the government's unwillingness to publish their new Skipjack algorithm, much attention has been focused on triple-DES as a replacement for DES. But triple-DES requires three times the processing of normal DES, and retains the same small block size which must be increasingly vulnerable to improved dictionary attacks. Thus it is reasonable to seek alternatives to triple-DES, and compare them with respect to keyspace, processing requirements, and block size. Vendors should be cautioned that triple-DES is not the only, nor necessarily the best, alternative to DES. They should consider delaying implementation of alternatives until a consensus develops on exactly what the replacement should be. New ciphering algorithms are often challenged to "prove" they are stronger than DES. Since it is impossible to measure the "strength" of a cipher (and there has been no absolute proof of strength for any practical cipher), new cipher algorithms are often considered curiosities. On the other hand, DES itself is well-known and accepted (despite having no proof of strength), so there seems to be great interest in the possibility of forming from DES a stronger cipher. Triple-DES is one approach at forming that stronger cipher, and is what we could call a 1x3 DES structure: one DES block wide by three DES cipherings deep. Naturally, we expect software for any three-level ciphering to operate at about one-third the speed of normal DES. There is an alternative approach which offers a larger keyspace, reduced processing, and larger block sizes (which, nevertheless, can often be used without data-expansion beyond that of normal DES). I call that approach "NxM DES," of which 2x2 DES is perhaps the easiest nontrivial example: 2x2 DES Instead of repeatedly enciphering a single 8-byte block, consider using multiple DES cipherings to form a 16-byte block operation and thereby improve plaintext block statistics. 2x2 DES will be two DES blocks wide by two DES cipherings deep. First, encipher two data blocks with DES, each under a different key. Exchange half the data in the first and second blocks. Then encipher the resulting blocks again, using two more keys: Let us denote a DES enciphering by: ciphertext := DESe( plaintext, key ) . We want to encipher two DES-size blocks, call them A and B, and end up with ciphertext blocks G and H: C := DESe( A, k1 ); D := DESe( B, k2 ); E := C[0..3],D[4..7]; F := D[0..3],C[4..7]; G := DESe( E, k3 ); H := DESe( F, k4 ); The byte-index notation on the second line is intended to convey the exchange of the rightmost four bytes of the first two DES ciphertexts. The exchange is a permutation, costless in hardware, and simple and cheap in software. This particular permutation is also a self-inverse, so that the same permutation can be used for both enciphering and deciphering. If we give each two-bytes of data a symbol and denote the original data as: 0123 4567 then after the permutation we have: 0167 4523 . For example, A: 01A1D6D039776742 B: 5CD54CA83DEF57DA k1: 7CA110454A1A6E57 k2: 0131D9619DC1376E C: 690F5B0D9A26939B D: 7A389D10354BD271 E: 690f5b0d354bd271 F: 7a389d109a26939b k3: 07A1133E4A0B2686 k4: 3849674C2602319E G: b4de11d10c55c267 H: 64f1a0b723d360a7 . Deciphering is similar to enciphering, except that the last-stage keys are used first, and we use DES deciphering instead of enciphering: E := DESd( G, k3 ); F := DESd( H, k4 ); C := E[0..3],F[4..7]; D := E[0..3],F[4..7]; A := DESd( C, k1 ); B := DESd( D, k2 ); Thus, 2x2 DES enciphers DES blocks A and B to DES blocks G and H in four DES cipherings. This is faster than triple DES, because twice as much data are enciphered in each block: 2x2 DES has a cost similar to double-DES. But 2x2 DES is potentially stronger than triple-DES, because each of the resulting ciphertext bits is a function of 128 plaintext bits (instead of 64), as well as three DES keys. (Although four keys are used in 2x2 DES, only three keys affect each output block, a 168-bit keyspace.) 2x2 DES does have a larger block size, so, when used alone, last-block padding overhead increases from four bytes (on average) to eight; a four-byte data expansion. Naturally, when used alone in CBC mode, the initialization vector (IV) will also be larger, 16 bytes instead of 8. This 12-byte overall increase in overhead should be weighed against the stronger 16-byte block size, since strength is the reason for moving away from normal DES in the first place. 4x2 DES In a manner similar to 2x2 DES, we can consider enciphering four DES blocks of plaintext, sharing data between them, and then enciphering the resulting four blocks again. 4x2 DES has a larger keyspace than 2x2 DES, yet retains the same ciphering cost. 4x2 DES does have some additional last-block and IV overhead, in return for a greater keyspace and larger block-size strength. Each 4x2 ciphering requires eight DES keys: E[0..7] := DESe( A, k1 ); F[0..7] := DESe( B, k2 ); G[0..7] := DESe( C, k3 ); H[0..7] := DESe( D, k4 ); (swap right-hand half of the data in {E,F} and {G,H}) I := E[0..3],F[4..7] J := F[0..3],E[4..7] K := G[0..3],H[4..7] L := H[0..3],G[4..7] (swap the middle half of the data in {I,L} and {J,K}) M := I[0..1],L[2..5],I[6..7] N := J[0..1],K[2..5],J[6..7] O := K[0..1],J[2..5],K[6..7] P := L[0..1],I[2..5],L[6..7] Q := DESe( M, k5 ); R := DESe( N, k6 ); S := DESe( O, k7 ); T := DESe( P, k8 ); The intermediate permutation involves four 32-bit exchange operations, an expense still trivial compared to the DES ciphering operations. (In a hardware implementation, the byte-swaps are the connections always needed between stages, just connected differently, with no added expense at all.) This permutation is also a self-inverse. If we denote each two-bytes of the data symbolically: 0123 4567 89ab cdef then after the permutation, we have: 0da7 49e3 852f c16b . Alternately, if we denote the data prior to permutation as: 0000 1111 2222 3333 then after the permutation we have: 0321 1230 2103 3012 , showing that each permuted block contains exactly two bytes from each of the four original DES blocks. Each 8-byte output block in 4x2 DES is a function of 32 bytes of input plaintext, as well as five DES keys, a 280-bit keyspace. For example, A: 01A1D6D039776742 B: 5CD54CA83DEF57DA C: 0248D43806F67172 D: 51454B582DDF440A k1: 7CA110454A1A6E57 k2: 0131D9619DC1376E k3: 07A1133E4A0B2686 k4: 3849674C2602319E E: 690F5B0D9A26939B F: 7A389D10354BD271 G: 868EBB51CAB4599A H: 7178876E01F19B2A M: 690f876ecab4d271 N: 7a38bb5101f1939b O: 868e9d109a269b2a P: 71785b0d354b599a k5: 04B915BA43FEB5B6 k6: 0113B970FD34F2CE k7: 0170F175468FB5E6 k8: 43297FAD38E373FE Q: 89af722f592664c4 R: 012d483a04db300f S: dd60060ad098e3e0 T: a3832dc4ff5c99ad . Again, 4x2 DES deciphering is similar, except that we use the last- stage keys first, and DES deciphering instead of enciphering. NxM DES 8x2 DES would have a 64-byte block and 16 DES keys, yet should still be considerably faster than triple-DES. Even larger blocks are possible, but would seem to require exchange operations on non-byte boundaries (to assure that each permuted block contains bits from each stage-one ciphertext block), so 16x2 DES and larger structures may have a larger software permutation cost. Nevertheless, the Nx2 approach gives us a way to increase the keyspace while generally retaining processing costs similar to double-DES. DES structures with additional ciphering levels, such as 2x3 DES or 4x3 DES, are also available, at a processing cost similar to triple- DES, but with the increased strength of a larger block size. A 2x3 DES structure would have a 280-bit keyspace similar to 4x2 DES, but with 50 percent higher processing costs. A 4x3 DES structure could be appropriate for some applications, but would have a huge 504-bit keyspace which would require us to create, transport and store the associated 84-byte key set. Large Blocks in Existing Systems It should be possible to adapt many existing systems to use larger blocks without further data expansion. Consider an 82-byte message, which would normally be structured as eleven 8-byte DES blocks, for a total of 88 bytes: An NxM DES alternative might use two 4x2 DES blocks, one 2x2 DES block, and one 1x3 DES block, for 32+32+16+8 or 88 bytes, exactly the same as normal DES. A 63-byte message (normally 8 DES blocks) would use just two 4x2 DES blocks for a total of 64 bytes, also the same as normal DES. If larger blocks are always used until smaller blocks would be more efficient, there is exactly one way to structure any given amount of data, and the resulting length is sufficient to reproduce the multiple-size blocking structure. The overhead of these blocking manipulations remains insignificant when compared to the DES ciphering operations. We could call this sort of use of multi-size blocking "NxM+ DES," and 4x2+2x2+1x3 DES (which we could call "4x2+ DES") would seem to be a very practical system. Clearly, in CBC mode, 4x2 DES will require a larger IV than normal DES. Perhaps the IV could be transferred as part of the key-exchange; there is obviously no way to avoid using larger keys if we want a stronger cipher, whatever approach we use. Smaller blocks at the end of a data area could just take the left-most part of the preceding block as their chain value. Similarly, a 2x2 DES block might use the left-most two DES keys at both levels of a 4x2 DES block (k1,k2,k5,k6), while a 1x3 DES block might just use the first three keys of the 2x2 DES block. Overall, 4x2+ DES might be a simple firmware upgrade for existing DES hardware. Summary Because the DES cipher is well known, there is interest in creating a stronger cipher which builds on normal DES as a base. By introducing a larger block width in addition to repeated cipherings, additional complexity can be obtained with a moderate increase in processing. This approach is unusual in that various levels of strength can be obtained at virtually the same processing cost, a cost comparable to double-DES and substantially less than triple-DES. Furthermore, the larger data blocks can be used even in systems which would not support data expansion beyond that inherent in normal DES. Consequently, the NxM DES approach would seem to have significant practical advantages over either double-DES or triple-DES as a replacement for DES. NxM DES is a product of my own research. I am not aware that this approach has been previously published. From sameer at soda.berkeley.edu Wed Feb 2 00:30:50 1994 From: sameer at soda.berkeley.edu (Sameer) Date: Wed, 2 Feb 94 00:30:50 PST Subject: Anonymous mail service up for alpha testing Message-ID: -----BEGIN PGP SIGNED MESSAGE----- I've written a small anonymous mail service, and it's now available for testing. There's no security, and I'll be keeping logs, so don't think that it's secure, in any way. It's also running on a PPP link which isn't connected all the time, so it's rather flaky. (I'll set it up as a real service once I get a real link-- if anyone else wants to do it, they're welcome to use my code.) How to get an anonymous account: Send mail to admin at infinity.hip.berkeley.edu -- include in the message a login, a "Full Name", a choice of remailer, and an encrypted return address block encrypted with that remailer's public key. I'll set it up. How the anonymous account works: Someone will send mail to login at infinity.hip.berkeley.edu. Then the system looks up in a table which remailer is associated with that login. It then sends out mail to that remailer, starting with the contents of the encrypted return address block, then a "##" and then all of the message to login at infinity, with "Received" lines taken out. Thus once the message gets to the last remailer of the chain in the encrypted return block, the ## pasts the identifying information of the person mailing to login at infinity.hip in the header of the message. (It *should* do that...) If the person mailing to the infinity address would like anonymity he/she should use an anon-mailer on his/her end. The encrypted-return address you send me should look like: :: Encrypted: PGP - -----BEGIN PGP MESSAGE----- etc. Make sure you include that ::/Encrypted or the remailer which gets it won't know that it's PGP encrypted. Remember, this is just setup for testing. Don't use it for real applications. - -Sameer -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLU9jrni7eNFdXppdAQH/FwP/b9pllDYnW6L4x0y1dVnC6km9TQ9lTw2x U/ea87JnguYSHYRxOk6lZoBBx5ZH/A48OCHJztzWHaSP2Tq69Oro4FTrtRcpTjbf ti8L97x9+Xvx1A6/Vkw1nuS5MRJ8SoPUV4bDKFdf80Ykhik5bk8b0WOUew1uF6dq QJzyDsKDFQU= =2EIr -----END PGP SIGNATURE----- From qwerty at netcom.com Wed Feb 2 01:10:50 1994 From: qwerty at netcom.com (Qwerty Uiopas) Date: Wed, 2 Feb 94 01:10:50 PST Subject: New Remailer Up. Message-ID: <199402020908.BAA13212@mail.netcom.com> ...and, to mail to an anon.penet.fi address, you must change the an1234 to na1234 (not anonymous), for I have a password/anon.penet.fi address for this account but I don't wish to either 1) give it out so anyone could then change it, or 2) have Julf remove it, so anyone could remail to anon.penet.fi but a few could also forge mail from qwerty to set a password. -Xenon From edgar at spectrx.saigon.com Wed Feb 2 01:10:56 1994 From: edgar at spectrx.saigon.com (Edgar W. Swank) Date: Wed, 2 Feb 94 01:10:56 PST Subject: Remailer Tearline Conventins Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Someone (not me) asked about remailer tearline conventions to eliminate automatic sigs: Though this subject came up some months ago, I never noticed any final decision. Is there now an accepted tearline convention for the generic cypherpunks remailers? The mail handler here and at most of my other accounts automagically adds the host address and/or my address to all outgoing mail, which is...well..._counterproductive_ when sending mail to a remailer. The extropia remailer by accepting encrypted messages avoids this problem, but most of the other remailers seem to have no provisions for excluding extraneous text and address footers. Was there ever a "8<----(cut here)" arrangement agreed upon and incorporated into the remailers? I'm the one who brought this up "months ago" and the short answer to your question is "no." One remailer Hall Remailer added a "cut line" of --ignore-- [no indentation in actual use]. I tested this when Hall first announced it and it seems to work. You would be advised to test it yourself before relying on it. Unfortunately the Hall Remailer is one of the remailers that does not support encryption. AFIK, this "cut line" code was never propagated to any other Cypherpunks remailers. At the time I brought this up, the attitude of most remailer operators (Chael Hall and Miron Cuperman notably excepted) was that anyone who couldn't figure out how and remember to turn off their auto sig didn't deserve any privacy. I recommend that you always use the wimsey (extropia) remailer as the first (or only) leg of a remailer chain. It is also the only Cypherpunks remailer outside the USA (it's in Canada) which will make tracing msgs a little more difficult for USA authorities. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLU5FJt4nNf3ah8DHAQECYQP/f2LDs7Tq1PfrH4PQBOR0Iu1XIrCDztZB dVapPFSjfF2Y20ljWqHsMK7xjUpfLpaXluFogav9DpGgey/zrO48MJJf8gFBGsJA 7gsOUl3Yc3VDPWvWI18zN4MgYeeEfRoTXIToWSeiadJmiEMq5m0hqs1bjZwOmmSr rewqGMxMUeI= =U43w -----END PGP SIGNATURE----- -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca From nobody at qwerty.org Wed Feb 2 02:10:49 1994 From: nobody at qwerty.org (nobody at qwerty.org) Date: Wed, 2 Feb 94 02:10:49 PST Subject: SuperPing1.2 Message-ID: <199402021008.CAA22797@mail.netcom.com> If it wasn't obvious, SuperPing is the sort of utility that only needs to be run say once a day by ONE person out there. Since I did it today, and I haven't reported any down links, you can be rest assured the network is fully connected, at least the remailers listed in the code. -Xenon From nobody at qwerty.org Wed Feb 2 02:25:28 1994 From: nobody at qwerty.org (nobody at qwerty.org) Date: Wed, 2 Feb 94 02:25:28 PST Subject: Remailer Tearline ConventiOns. Message-ID: <199402021025.CAA23813@mail.netcom.com> Edgar wrote, "I recommend that you always use the wimsey (extropia) remailer as the first (or only) leg of a remailer chain." I'm not too familiar with extropia these days. Does it have a direct internet connection? What is its characteristics? I'm trying to make up a more useful list of remailers, with details, since different users do have different needs for remailers. Thanks. -Xenon From pmetzger at lehman.com Wed Feb 2 04:15:30 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 2 Feb 94 04:15:30 PST Subject: archiving on inet In-Reply-To: <9402012201.AA23756@internal.apple.com> Message-ID: <199402021211.HAA05378@snark> Lefty says: > >In what way does my internet provider > >(netcom) have a "legal" distribution of usenet news, while a cd-rom > >provider does not? > > I have "provided" my postings to Usenet, for the personal use of Usenet > subscribers. Excellent. Now, please tell me how to determine if someone is a subscriber. Is there a big subscriber list available somewhere for the judge to check? > By providing my postings to a particular distribution > mechanism, I implicitly give permission for them to be redistributed _via_ > _that_ _mechanism_. I _do_ _not_ give permission for them to be repackaged > and resold via another medium, any more than David Byrne has given me > permission to resell cassettes of his music by allowing it to be broadcast > on the radio. Wonderful. Now, can you please explain what the usenet transmission mechanism is? It obviously includes magtapes. It appears to include CD-ROMs -- they have been used to distribute newsfeeds for years now. In theory, an NNTP site that never expires articles makes those articles available forever via NNTP, so time is obviously not a criterion. Usenet has always been gatewayed to email, so email isn't excluded (indeed, CNews explicitly provides a "by email" news distribution mechanism). So, what exactly, is NOT part of the usenet mechanism? Perry From pmetzger at lehman.com Wed Feb 2 04:20:53 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 2 Feb 94 04:20:53 PST Subject: archiving on inet In-Reply-To: <199402020036.QAA20961@mail.netcom.com> Message-ID: <199402021218.HAA05396@snark> Now all you have to do is explain what an "expiration date" is and explain the legal liability of sites that miss cancel messages by accident. .pm Jim Nitchals says: > There is. Copyright 1994 James Nitchals. Duplication and redistribution > rights permitted only until the expiration date or issuance of a cancel > message by the author. > > CD-ROM publishers cannot honor the request except by reissuing the CD-ROM > without my content. Anyone who backs up their home directory is safe, > but if they redistribute my article after it's expired or cancelled, they > are in violation of my copyright. > > From pmetzger at lehman.com Wed Feb 2 04:25:30 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 2 Feb 94 04:25:30 PST Subject: archiving on inet In-Reply-To: <199402020030.QAA20097@mail.netcom.com> Message-ID: <199402021222.HAA05404@snark> Many news systems don't understand expiration dates, and some don't grok cancel messages. CD-ROMs can easily carry cancel messages, too, by the way -- they are a transport medium. Next bright idea? Anyway, people who want to use the law to restrict distribution of their news articles are extremely foolish. Your words are out there and they WILL be read. Forever. You can't help it. If you find your words embarassing, don't say them. .pm Jim Nitchals says: > I've already said it. I own the copyright to my posts, and only permit > them to be distributed by Usenet because I can *cancel* and provide > expiration dates with my posts. CD-ROMs do not provide these standard > Usenet message control features. > > If I issue a cancel message, it's obvious that I'm asserting control > over the further distribution of my content (sites that ignore them > notwithstanding.) Any time a CD-ROM is published with my message, and > it contains an expiration date or is later cancelled, the publication > violates my right as a copyright holder to retract my message. > > [portions deleted] > No providers of usenet news > > have any agreements between themselves and the posters regarding > > copyrights. Netcom and all the other internet providers receive postings > > "free" and a cd-rom manufacturer has the same "right" to use postings as > > any other internet provider. > > My expiration dates or cancel messages are perfectly reasonable ways > to communicate the way in which I'm exercising my copyright. Netcom > and other service providers currently honor those communications, but > CD-ROM publishers of Usenet news do not. > > > > Kirk Sheppard > > > > kshep at netcom.com > > > > P. O. Box 30911 "It is Better to Die on Your Feet Than to > > Bethesda, MD 20824-0911 Live On Your Knees." > > U.S.A. > > - Emiliano Zapata > > From boone at psc.edu Wed Feb 2 07:00:55 1994 From: boone at psc.edu (Jon 'Iain' Boone) Date: Wed, 2 Feb 94 07:00:55 PST Subject: New Remailer Up. In-Reply-To: <199402020607.WAA29302@mail.netcom.com> Message-ID: <9402021500.AA11889@igi.psc.edu> nobody at qwerty.org writes: > > -----BEGIN PGP SIGNED MESSAGE----- > > Greetings. > > New remailer: qwerty at netcom.com. > > No logs. Only a "counter" that works by appending the word "R" or "ER" to a > text file so I can get an idea if anyone is using it. However, I'm sure the > Netcom and other site's mail logs will be enough to track serious abusers > of anonymity down, without my help. This remailer is dedicated to honest > people who desire PRIVACY. Is the sendmail (I assume you are using sendmail for SMTP services) daemon set up so that it *doesn't* log to /usr/spool/mqueue/syslog [or any other syslog facility]? Otherwise, it may well be possible to track the usage of the remailer through browsing the syslog logs. This is one of the problems (it seems to me) with using a remailer and *not* having root access. Unless you can convince your sysadmin to remove the syslog mechanism that sendmail uses, you may be exposing your users (presumably by accident). Jon Boone | PSC Networking | boone at psc.edu | (412) 268-6959 PGP Public Key fingerprint = 23 59 EC 91 47 A6 E3 92 9E A8 96 6A D9 27 C9 6C From hughes at ah.com Wed Feb 2 07:40:56 1994 From: hughes at ah.com (Eric Hughes) Date: Wed, 2 Feb 94 07:40:56 PST Subject: New Remailer Up. In-Reply-To: <9402021500.AA11889@igi.psc.edu> Message-ID: <9402021536.AA17122@ah.com> >> New remailer: qwerty at netcom.com. > Is the sendmail [...] daemon > set up so that it *doesn't* log to /usr/spool/mqueue/syslog [...] ? > This is one of the problems (it seems to me) with using a remailer and > *not* having root access. The remailers could implement their own outoing SMTP, to get rid of one end of the log, albeit the less important end. They could also run a SMTP server on a non-reserved TCP port, but that would require a few things: -- The remailer would have to be in the process table at all times and listening to some TCP port. Right now the remailer is activated by incoming mail and appears only transiently in the process table. -- The remailer chain would have to know to use the alternate port when sending. This should require new syntax for setting up source routes. It would, however, eliminate the standard mail logging. Eric From hughes at ah.com Wed Feb 2 08:15:32 1994 From: hughes at ah.com (Eric Hughes) Date: Wed, 2 Feb 94 08:15:32 PST Subject: On return addresses Message-ID: <9402021609.AA17192@ah.com> I've been troubled for many months by an invariant in all forms of return address schemes: The outside world contains sufficient _persistent_ information to find a real adress. There are lots of clever schemes to split this information up so as to require reassembly between many parties, but the information is still out of one's control. (I use 'reassembly' rather than 'collusion' since the latter indicates an intent; see my rant of a few days ago.) The fundamental problem seems impenetrable. So how do we solve it? By abandoning return addresses and using mail spool facilities. Consider the following service. 1. I have a machine and I'll sell you an address on it, say "onyma at privacy.net". This address is _not_ an account, merely an address. Your mail is password or public key protected. 2. When mail come in for you, it sits in a spool. This service comes with a spool of a certain size and an allowance for checking your mail at a certain rate, with overages at extra cost for both. (This is to bound known promised capacity of the machine by a sufficient amount of money to pay for it.) 3. Your mail sits in the spool until you access it with, say, a POP client like Eudora. Just point the client at a different address to pick up mail. The server can further support a number of protocols for getting the mail, including a mail server command of "send me a mailbox file of my waiting mail". The main advantage is that the only _persistent_ information out in the world is the address itself and the authenticator (password or public key). The address is already public and the authenticator is arbitrary, so no identity information is persistent. A complete chain could still be forged between sender and receiving pseudonym, but we now have some amount of forward secrecy. If in fact an intermediate link does discard connection information, it is gone forever. With any kind of SASE, however, the information therein, however encrypted, still contains a full path back. Now consider two ways of getting your mail out of this service, supposing you don't trust the service with your identity. A IP redirector can be with POP service to conceal origin from the mail service. An IP redirector is a remailer for packets, with a bidirectional link set up when the service starts and removed when it goes away. Matt Blaze has a name for this--'packet laundry'--which is a wonderful but politically unfortunate term. The IP redirectors can be chained just like remailers. With a mail server, the command to 'send me my mailbox' can be sent to a remailer address with an encrypted remailing block prepended. In this case, however, the encrypted remailer block is provided with the mail command that requests the mailbox and it is not by design stored persistently. (By design. It could, of course, actually be stored.) The address on the other side of the first remailer hop could be another mail spooing service, in addition. The elimination of persistent identifying information for return paths is a worthwhile design objective. I propose that we start thinking about it more thoroughly. Eric From sameer at soda.berkeley.edu Wed Feb 2 08:50:56 1994 From: sameer at soda.berkeley.edu (Sameer) Date: Wed, 2 Feb 94 08:50:56 PST Subject: REMAIL: ping, script In-Reply-To: <9402020140.AA07524@screech.owlnet.rice.edu> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Karl Lui Barrus spake: > 10:y:sameer at netcom.com > 15:y:sameer at soda.berkeley.edu These remailers are down. :-( -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLU/UkXi7eNFdXppdAQEJ6wP/ZyqgG4nF32c8/4MaG/DNaqeHJpd1KyW1 YfZ58gR9GzWlnE7zhDgfiLRo1I0W6PVUO7mMxj8aIou7xhzME3F9fwqZfPbX8yZN DWbSY4yDBgSyVu1wcs5gtwOK8htlLdpinBxDXjSh6rH6d9tQEQi55tXz6ocveveI i1euOShTWoI= =9Hax -----END PGP SIGNATURE----- From ravage at wixer.bga.com Wed Feb 2 09:11:06 1994 From: ravage at wixer.bga.com (Jim choate) Date: Wed, 2 Feb 94 09:11:06 PST Subject: Archiving on Inet Message-ID: <9402021708.AA09079@wixer> I would like to ask all subscribers who are not addressing the issues of this question to please move their responces to private mail. I have no interest in exploring your personalities or views of others personalities. If a global network is to survive there must be a commen understanding of what is public domain and what is private or commercial. At the present time this is completely new ground. The fact is that the copyright laws of the US are of little interest to a net user in Moscow, Russia or Pretoria, S. Africa. If as a cpunk you don't feel that a anonymous regulatory agency can protect your privacy why do you feel they can protect your intellectual property? The issue has direct bearing on both intellectual property and the wide spread use of cryptographic techniques. As a active cpunk it seems to me that your first motivation after producing the actual code is to creat a atmosphere where it can be used for the betterment of all. To create a useable global community (what I am striving for) it seems to me that entries on that network must be public domain by default. Otherwise every country who joins, and by reduction every potential user, will have to agree on how to recompense each and every user who desires to be paid for their submissions. This, to me, leads incontrovertibly to the conclusion of a beurocratic nightmare that will not significanly assist anyone other than the regulatory agencies. The only other answer that seems even close to working (and I consider this a stretch of the imagination) is one where everyone is given access for free and the governments regulate the traffic completely and pat for it with tax dollars. As to the issue as it applies to community bbs'es. I run such a system and am in the process of getting it on the net. As part of this project I have 2 other systems that I will be providing feeds for. These systems are all run by individuals who have these boxes sitting in their den. By insisting on a priori copyright of all material it is my opinion that you are creating a situation which will prevent the growth of such systems. Now if we don't have regulatory agencies and the sites are indipendant (and I assume self supporting) how can we expect some Joe or Jill to put up a system to help the people in their neighborhood if they have to keep looking over thier shoulders for the copyright police? The answer is they won't put up such systems and we all loose. By providing strong crypto tools for business and individuals to protect their intellectual and commercial property we are creating an open door atmosphere which motivates people to join the network for their own enjoyment and edification. This to me is more important than keeping the present view (as applied to non-networked environments) of copyright. It is time that we as uses of Internet set a precedence before the legislators set one for us that will in the long run only assist those already in power by strangthening the need for regulatory agencies. I strongly suggest that you all consider this idea from the global and long term view. I think you will find that the view "information wants to be free' is the way to go. To this end I propose that organizations such as EFF and cpunks take the position of a priori public domain status of network submissions. Also that all individuals who wish to retain intellectual or commercial rights either use strong crypto w/ e-mail distribution of keys or a change be implimented in message headers such that sites who don't wish to carry such material can filter it, along with this should be a requirement that any such non- crptographicly secure material must contain a fair use policy at the beginning of each and every document. It is time we quite letting big brother tell us what we can do with our ideas and how to distribute them. From nobody at qwerty.org Wed Feb 2 09:15:32 1994 From: nobody at qwerty.org (nobody at qwerty.org) Date: Wed, 2 Feb 94 09:15:32 PST Subject: New Remailer Up. Message-ID: <199402021713.JAA08629@mail.netcom.com> Jon Boone wrote, " Is the sendmail (I assume you are using sendmail for SMTP services) daemon set up so that it *doesn't* log to /usr/spool/mqueue/syslog [or any other syslog facility]? Otherwise, it may well be possible to track the usage of the remailer through browsing the syslog logs. This is one of the problems (it seems to me) with using a remailer and *not* having root access. Unless you can convince your sysadmin to remove the syslog mechanism that sendmail uses, you may be exposing your users (presumably by accident)." No, fortunately for other users, I do not have root access on Netcom ;-). So who is going to be doing this browsing? Other Netcom users can't read the mqueue: qwerty: cd /usr/spool qwerty: ls cron lpd.lock news news4 uucp locks mail news2 rwho uucppublic lpd mqueue news3 secretmail uumaps qwerty: cd mqueue mqueue: Permission denied qwerty: ls -la total 480 drwxr-sr-x 15 bin 512 Feb 2 01:38 . drwxr-xr-x 13 root 512 Feb 2 01:38 .. drwxr-sr-x 4 root 512 Feb 2 01:38 cron drwxr-sr-x 2 uucp 512 Feb 2 08:30 locks drwxrwsr-x 2 daemon 512 Feb 2 03:47 lpd -rw-r--r-- 1 root 4 Feb 2 01:38 lpd.lock drwxrwsrwt 4 root 430080 Feb 2 08:37 mail drwxr-s--- 2 root 18944 Feb 2 08:37 mqueue drwxr-xr-x284 netnews 12288 Feb 2 05:29 news drwxr-sr-x 2 netnews 512 Aug 28 17:03 news2 drwxr-sr-x 2 netnews 512 Aug 28 17:03 news3 drwxr-sr-x 2 netnews 512 Jan 16 19:56 news4 drwxr-sr-x 2 root 512 Jan 31 14:40 rwho drwxrwsrwx 2 bin 512 Nov 3 08:49 secretmail drwxr-sr-x 11 uucp 512 Feb 2 01:38 uucp lrwxrwxrwx 1 root 20 Nov 26 15:48 uucppublic -> /usr/hack/uucppublic drwxrwxr-x 5 netnews 12288 Feb 2 05:48 uumaps "Is the sendmail (I assume you are using sendmail for SMTP services) daemon set up so that it *doesn't* log to /usr/spool/mqueue/syslog [or any other syslog facility]? Otherwise, it may well be possible to track the usage of the remailer through browsing the syslog logs." I'm using Hal's remailer, so ask him the details of what I have running. How many of those private sites with remailers having root, keep NO personal logs? Any? I would like to compile a more detailed listing of the details about each remailer's capabilities, situation, and policy statements. If someone sends anonymous mail through my mailer victimizing someone in a criminal manner, and law enforcement convinces Netcom to check the logs, then more power to them. If someone sends mail discussing large doses of vitamin C, when vitamin supplementys are banned a year from now, and the FDA wants to arrest them, and Netcom allows them to see the mqueue then that would be unfortunate indeed. I am running a remailer. Here is the situation. What more can I offer? I would ask people to look at the various remailers and ask in a street smart practical manner what the pros and cons of each one is. What, exactly, does the mqueue record? How long does it get saved? I needed remailers to maintain some simple privacy by distancing myself from the character Xenon. No 5AM fone calls and letters from people asking me to send them PGP.... I figured if I was going to become the largest volume user of the remailers, I should become a remailer myself. The other option was to use the Netcom account to directly mail out what I am sending to people, but that wasn't as fun of an idea. -Xenon From mmarkley at microsoft.com Wed Feb 2 09:30:56 1994 From: mmarkley at microsoft.com (Mike Markley) Date: Wed, 2 Feb 94 09:30:56 PST Subject: fwd: Canadian gov't eavesdropping Message-ID: <9402021727.AA04813@netmail2.microsoft.com> | From: Eli Brandt | To: cypherpunks list | Subject: fwd: Canadian gov't eavesdropping | Date: Tuesday, February 01, 1994 7:26PM | | Received: from relay2.UU.NET by netmail.microsoft.com with SMTP (5.65/25-eef) | id AA07450; Tue, 1 Feb 94 19:59:09 -0800 | Received: from toad.com by relay2.UU.NET with SMTP | (5.61/UUNET-internet-primary) id AAwbln22133; Tue, 1 Feb 94 22:55:33 -0500 | Received: by toad.com id AA05602; Tue, 1 Feb 94 19:30:49 PST | Received: by toad.com id AA05533; Tue, 1 Feb 94 19:26:28 PST | Return-Path: | Received: from jarthur.Claremont.EDU ([134.173.42.1]) by | toad.com id AA05527; Tue, 1 Feb 94 19:26:21 PST | Message-Id: <9402020326.AA05527 at toad.com> | In-Reply-To: <94Feb1.201622est.83288(2)@ivory.educom.edu>; | from "E-D-U-P-A-G-E" at Feb 1, 94 8:21 pm | X-Arcane-Subliminal-Header: fooquayleglorkpsilocybinrkbapinkyogsothothquux | X-Mailer: ELM [version 2.3 PL11] | | > Date: Tue, 1 Feb 1994 20:21:46 -0500 | [...] | > HIGH-TECH SNOOP GADGET. A super-secret branch of the Canadian Security | > Intelligence Service has awarded three contracts to a Montreal firm to make | > equipment that can quickly isolate key words and phrases from millions of | > airborne phone, fax, radio signals and other transmissions. The hardware | > has the "Orwellian potential to sweep through ... and keep records of all | > conversations," said one CSIS critic. (CTV National News, 01/31/94 11:00 | > pm). | | Dunno how feasible this kind of keyword recognition presently is, | but here's another reason to encrypt. I'd be curious to see how they are going to do voice recognition on random conversations. Unless I am very sadly out of date you need to teach the pattern matcher individual voices. | | > EDUPAGE. To subscribe to Edupage send e-mail to listproc at educom.edu, | > containing the following text: SUB EDUPAGE yourfirstname yourlastname. To | | Eli ebrandt at jarthur.claremont.edu | | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 werner at mc.ab.com Wed Feb 2 09:40:57 1994 From: werner at mc.ab.com (werner at mc.ab.com) Date: Wed, 2 Feb 94 09:40:57 PST Subject: remailers Message-ID: <9402021739.AA04726@werner.mc.ab.com> Hi, Can a remailer be used to post to an arbitrary Usenet group? Is the above a stupid question? From blake.coverett at canrem.com Wed Feb 2 10:00:56 1994 From: blake.coverett at canrem.com (Blake Coverett) Date: Wed, 2 Feb 94 10:00:56 PST Subject: archiving on inet In-Reply-To: <9402011752.AA00225@jazz.hal.com> Message-ID: <60.2666.6525.0C19348B@canrem.com> jazz at hal.com, in a message on 1 February, wrote: JA> If you were a ligitimate recipient of the work in the first place (i.e. g JA> it in a newsfeed) and you store those postings for your own use or for th JA> use of others on that node in the store-and-forward network, then you can JA> keep the work 'til the bits rot. Infringement occurs when you copy those JA> bits onto some medium for some purpose other than store-and-forward JA> propagation or the allowed fair-use exceptions; stuffing articles on a JA> CD-ROM and selling them falls into neither category and hence is an JA> infringement. Hmm... why is "stuffing articles on a CD-ROM and selling them" not a type of store-and-forward propagation? Usenet is not just a bunch of machines speaking CNews. I agree that you have a copyright on the expression of ideas that make up a Usenet post. However I maintain that by posting them on Usenet you are explicitly allowing them to be distributed (either freely or for a cost) by all methods used to distribute Usenet. I would seem obvious to me that taking a nice piece of Usenet prose and publishing it a collection of essays would be in violation of a copyright. On the other hand, publishing the same thing in a collection of this month's Usenet traffic would not. People redistribute and sell your Usenet postings all the time, why would it make a difference if they do so via CD-ROM? -Blake (Never underestimate the bandwidth of a trunk full of CD-ROMs) ... * ATP/DJgcc 1.42 * blake.coverett at canrem.com, disclaimers? fooey! From nobody at qwerty.org Wed Feb 2 10:15:56 1994 From: nobody at qwerty.org (nobody at qwerty.org) Date: Wed, 2 Feb 94 10:15:56 PST Subject: remailers Message-ID: <199402021815.KAA24792@mail.netcom.com> werner asked, "Can a remailer be used to post to an arbitrary Usenet group?" newsgroup at news.cs.indiana.edu posts things quickly via e-mail. When I use anon.penet.fi for Usenet, I often use this, since it is quite a bit faster than using anon.penet.fi's posting feature. "Is the above a stupid question?" Is this a stupid answer? Both are in various FAQs. -Xenon From pgpkeys at wasabi.io.com Wed Feb 2 10:20:56 1994 From: pgpkeys at wasabi.io.com (PGP Slave Key Server) Date: Wed, 2 Feb 94 10:20:56 PST Subject: system logging Message-ID: <199402021245.MAA19515@wasabi.io.com> > Greetings. > > New remailer: qwerty at netcom.com. > > No logs. Only a "counter" that works by appending the word "R" or "ER" to a > text file so I can get an idea if anyone is using it. However, I'm sure the > Netcom and other site's mail logs will be enough to track serious abusers > of anonymity down, without my help. This remailer is dedicated to honest > people who desire PRIVACY. People should be aware that whether Niko makes personal logs on his qwerty account or not, the public logs on netcom show more than enough info to trivially track people down. By the way it's very bad practice to forge From: lines, especially with completely non-existant site names like qwerty.org...perhaps you should ask netcom to register it for you. Or if they charge real money for it, your postmaster at columbia.edu might do it for free if you asked him nicely. From nobody at qwerty.org Wed Feb 2 10:25:33 1994 From: nobody at qwerty.org (nobody at qwerty.org) Date: Wed, 2 Feb 94 10:25:33 PST Subject: fwd Canadian gov't eavesdropping Message-ID: <199402021825.KAA27093@mail.netcom.com> Mike Markley say, "I'd be curious to see how they are going to do voice recognition on random conversations. Unless I am very sadly out of date you need to teach the pattern matcher individual voices." But of course they will just collect voice samples from everyone soon, and use them to IDENTIFY you. It'll probably be put on our US national health care cards. Ever since I started worrying about leaving DNA on postage stamps, I've started to think what can be done will be done. -Xenon From gnu Wed Feb 2 10:25:56 1994 From: gnu (John Gilmore) Date: Wed, 2 Feb 94 10:25:56 PST Subject: Josh Quittner's Newsday column on Cypherpunks Message-ID: <9402021823.AA26464@toad.com> Date: Wed, 02 Feb 1994 10:41:42 est From: "josh quittner" To: gnu at cygnus.com Subject: newsday column Hiya John: Here's the little column I did for my newspaper on the cypherpunks meeting I sat in on last month. Thought you might be interested. I know it's laymanlike, but if you want, you have my permission to distribute it to your list. I told Eric I'd send him a copy, but I left his email address at home, so if you'd be good enough, would you either pass this on to him or email me his address so I can? Thanks. Hope all is well with you. Be glad you're not freezing your ass off back here. Regards, -jq PUBLICATION DATE Tuesday. February 1, 1994 EDITION NASSAU AND SUFFOLK SECTION DISCOVERY PAGE 53 OTHER EDITIONS 59 C HEADLINE Life In Cyberspace COMPUTERS IN THE ^90s Coding Up a Bit of Privacy BYLINE Joshua Quittner DATELINE MOUNTAIN VIEW, Calif. LENGTH 91 Lines MOUNTAIN VIEW, Calif. THIS MUST BE HOW the Founding Fathers looked when they hacked out the Constitution: A roomful of young men, mostly - frazzled hair, eager eyes, wild beards, arms flailing and fingers jabbing the air, reaching for big ideas. You can't help but feel it; urgency tempers their voices. The earnest men plan and argue in this corporate conference room as the last sun rays of a winter Saturday afternoon fade in through a skylight. Time is running out for the Cypherpunks. There is much work to be done before the information highway arrives. The information highway - that 500-channel shopping mall / cineplex championed by cable and telephone companies - is a noxious concept to the people in this room. They are not technophobes or Luddites, these Cypherpunks. Instead, they are a collection of clever computer programers, engineers and wire heads from some of the nation's best-known Silicon Valley software houses and hardware shops. This is their central question: In a future world where all information is centralized on a network, where all information is tracked by the bit, where every purchase you make and every communication can be monitored by corporate America, how does privacy survive? If you go to a bookstore now and buy a book, you can pay in cash. No one knows your name or what you purchased. "What happens to cash transactions on the information highway?" they ask. The Cypherpunks believe that they can preserve your privacy through good cyphers, or codes. But they must hurry, must get their codes out and their networks up and running. "The whole information highway thing is now part of the public eye," explains Eric Hughes, a founder of the Cypherpunk movement. "If we don't change it now, it'll be impossible later." The Cypherpunks know what technology is capable of. We visit them today because they represent one edge of the national debate on the structure of the information highway. And as we all know, extreme positions help define the middle. Many of the Cypherpunks have been heavy Internet users for years and hope to preserve the communal spirit of that freewheeling world of interconnected computer networks. They dread the coming commercial network of televisions and computers, saying it will displace the Internet and destroy many of the freedoms they now enjoy. So the Cypherpunks, with the kind of zeal they professionally bring to marathon, 72-hour sessions hacking computer code, are plotting to keep free networks alive. That's "free" in the sense of unfettered, unmonitored, uncensored. One way they're going about it is by spreading easy-to-use, cheap cryptography. Cryptography is the science of keeping two-way communication private. Computers, it turns out, are revolutionary cryptographic tools, able to encode and decode files quickly. For the first time, virtually unbreakable codes are now possible, thanks to computers. The Cypherpunks post cryptographic software on the Internet where anyone can access it, and can encode their communications, including electronic mail, pictures and video. But the U.S. government is concerned, as governments always are, about the spread of powerful cryptography (terrorists could use it, kidnapers could use it, drug dealers could use it, all of them on cellular phones that encode conversations). It currently is pushing its own commercial cryptographic standard, through a special chip known as the Clipper. The chip is reviled by Cypherpunks and other civil libertarians because it provides a back door that law-enforcement agencies could enter, with the proper warrants, for surveillance. By getting good, unbreakable cryptography out there now, the Cypherpunks hope, whatever the government finally decides will be moot. Software has a wonderful property, the Cypherpunks are fond of saying: Once it's created, it can never be destroyed. It can be copied infinitely, from computer to computer, spreading like a secret. Come what may, unbreakable Cypherpunk code, and Cypherpunk networks, will be out there forever, they hope. But just to be safe, the Cypherpunks are toying with different network-related plans to create an economy of "digicash" - network money that, like the dollars in your pocket, isn't tied to a user's credit cards or other personal identification. Digicash will help pay for Cypherpunk networks and will allow people to purchase goods without revealing their identity. "I'm starting a bank, and it's not going to be a U.S. bank," Hughes says. He's standing at the whiteboard now. A strawberry-blond ponytail dangles down his back and he grasps a magic marker in his hand. "We have several long-term strategies, one of which is the elimination of central banks." He tells the assembled crowd what they already know. Heads nod. Some people take notes. Hughes is a self-employed programer in Berkeley. His hand flies across the whiteboard, sketching out a schematic diagram, showing how his bank will operate. The bank will store depositers^ money (he's thinking a $200 minimum deposit) and disburse payments to anyone - all over the Internet. It will be based abroad, maybe in Mexico. A Cypherpunk network bank is one way to pay for a network of truly encrypted, private communications, you see. "Is this going to lead the way to portable laptop ATM machines?" someone asks in the back. People snicker. "Have you thought about its name?" someone else asks. "First Bank of Cyberspace!" yells one person. "First Internet Bank!" yells another. "The Nth National Bank!" Laughter. Billy goat beards bob. There is much work to be done. --end of story-- -- josh quittner vox: 516-843-2806 fax: 516-843-2873 quit at newsday.com From wjm at MIT.EDU Wed Feb 2 10:30:57 1994 From: wjm at MIT.EDU (william j mitchell) Date: Wed, 2 Feb 94 10:30:57 PST Subject: unsubscribe wjm@mit.edu Message-ID: <9402021826.AA26210@MIT.EDU> unsubscribe wjm at mit.edu From pgpkeys at wasabi.io.com Wed Feb 2 10:45:32 1994 From: pgpkeys at wasabi.io.com (PGP Slave Key Server) Date: Wed, 2 Feb 94 10:45:32 PST Subject: New US keyserver now fully operational - pgp-public-keys@io.com Message-ID: <199402021313.NAA19622@wasabi.io.com> The US-based keyserver 'pgp-public-keys at io.com' is now open to the public. Come one, come all! Here is the current file as returned by 'Subject: help'. This site is a PGP key server SLAVE site. It behaves very similarly to the European PGP master sites, but there are a few small differences which will be noted below. The most noticable difference is that it answers your requests immediately instead of waiting for a daily batch job to run :-) The particular installation at io.com does *not* log the details of requests for keys, however the fact that you have sent mail to the key server at all is logged in the daily sendmail logs. These logs will be erased automatically after one week. PGP Public Keyservers --------------------- There are PGP public key servers which allow one to exchange public keys running through the Internet and UUCP mail systems. This service is NOT supported in any way whatsoever by the schools or organizations on which these servers run. It is here only to help transfer keys between PGP users. It does NOT attempt to guarantee that a key is a valid key; use the signators on a key for that kind of security. This service can be discontinued at any time without prior notification. Each keyserver processes requests in the form of mail messages. The commands for the server are entered on the Subject: line. To: pgp-public-keys at io.com From: johndoe at some.site.edu Subject: help Sending your key to ONE server is enough. After it processes your key, it will forward your add request to other servers automagically. For example, to add your key to the keyserver, or to update your key if it is already there, send a message similar to the following to any server: To: pgp-public-keys at io.com From: johndoe at some.site.edu Subject: add -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 -----END PGP PUBLIC KEY BLOCK----- COMPROMISED KEYS: Create a Key Revocation Certificate (read the PGP docs on how to do that) and mail your key to the server once again, with the ADD command. Valid commands are: Command Message body contains ---------------------- ------------------------------------------------- ADD Your PGP public key (key to add is body of msg) *** Note: your update is forwarded to a master server and may take a few days to reappear INDEX List all PGP keys the server knows about (-kv) VERBOSE INDEX List all PGP keys, verbose format (-kvv) GET Get the whole public key ring GET 0xA1B2C3 Get a single key by Key ID *** Note: the master servers allow you to omit the 0x in front of the Key ID. The slave servers do not. GET userid Get a single key by User ID MGET substr List all keys which match "substr" *** Note: this is different from the master servers which return the keys themselves, not just a listing of their Key IDs. Also the master servers accept a wild-card expression; at the moment we do not. LAST days Get the keys updated in the last `days' days *** Note: not yet implemented ------------------------------------------------------------------------ Examples for the MGET command: MGET michael Lists all keys which have "michael" in them MGET @iastate.edu Lists all keys which contain "@iastate.edu" Check the Usenet newsgroup alt.security.pgp for updates to this system and for new sites. Based on a document originally by Michael From cknight at crl.com Wed Feb 2 10:55:33 1994 From: cknight at crl.com (Chris Knight) Date: Wed, 2 Feb 94 10:55:33 PST Subject: fwd: Canadian gov't eavesdropping In-Reply-To: <9402021727.AA04813@netmail2.microsoft.com> Message-ID: On Wed, 2 Feb 1994, Mike Markley wrote: > > I'd be curious to see how they are going to do voice recognition on > random conversations. Unless I am very sadly out of date you need to > teach the pattern matcher individual voices. > Drop by your nearest Apple Macintosh dealer and ask them to show you the speach recognition system that comes shipped with the Quadra AV series. I gave a demo in a crowded room, and a stereo in the background... Several people took turns asking the computer what time it was, open the control panel, etc. I think you will be suprised. -ck From boone at psc.edu Wed Feb 2 10:55:58 1994 From: boone at psc.edu (Jon 'Iain' Boone) Date: Wed, 2 Feb 94 10:55:58 PST Subject: New Remailer Up. In-Reply-To: <199402021713.JAA08629@mail.netcom.com> Message-ID: <9402021852.AA15745@igi.psc.edu> nobody at qwerty.org writes: > > Jon Boone wrote, > " Is the sendmail (I assume you are using sendmail for SMTP services) daemon > set up so that it *doesn't* log to /usr/spool/mqueue/syslog [or any other > syslog facility]? Otherwise, it may well be possible to track the usage > of the remailer through browsing the syslog logs. > > No, fortunately for other users, I do not have root access on Netcom ;-). > So who is going to be doing this browsing? Other Netcom users can't read > the mqueue: > > qwerty: cd /usr/spool > qwerty: ls > cron lpd.lock news news4 uucp > locks mail news2 rwho uucppublic > lpd mqueue news3 secretmail uumaps > qwerty: cd mqueue > mqueue: Permission denied > qwerty: ls -la > total 480 > drwxr-sr-x 15 bin 512 Feb 2 01:38 . > drwxr-xr-x 13 root 512 Feb 2 01:38 .. > drwxr-sr-x 4 root 512 Feb 2 01:38 cron > drwxr-sr-x 2 uucp 512 Feb 2 08:30 locks > drwxrwsr-x 2 daemon 512 Feb 2 03:47 lpd > -rw-r--r-- 1 root 4 Feb 2 01:38 lpd.lock > drwxrwsrwt 4 root 430080 Feb 2 08:37 mail > drwxr-s--- 2 root 18944 Feb 2 08:37 mqueue > drwxr-xr-x284 netnews 12288 Feb 2 05:29 news > drwxr-sr-x 2 netnews 512 Aug 28 17:03 news2 > drwxr-sr-x 2 netnews 512 Aug 28 17:03 news3 > drwxr-sr-x 2 netnews 512 Jan 16 19:56 news4 > drwxr-sr-x 2 root 512 Jan 31 14:40 rwho > drwxrwsrwx 2 bin 512 Nov 3 08:49 secretmail > drwxr-sr-x 11 uucp 512 Feb 2 01:38 uucp > lrwxrwxrwx 1 root 20 Nov 26 15:48 uucppublic -> /usr/hack/uucppubl ic > drwxrwxr-x 5 netnews 12288 Feb 2 05:48 uumaps Well, anyone who is the group which owns mqueue (you need to do an ls -ldg to show this info) can read the directory and (likely) the logs. It would not be unusual for the daemon or bin id's to be allowed read access to these files/directories, so anyone who could exploit the latest sendmail bug could end up reading those files... And that doesn't even go into the potential access by legitimate sysadmins who may not care too much about other users' privacy... > I'm using Hal's remailer, so ask him the details of what I have running. > How many of those private sites with remailers having root, keep NO personal > logs? Any? I would like to compile a more detailed listing of the details > about each remailer's capabilities, situation, and policy statements. As would I. > If someone sends anonymous mail through my mailer victimizing someone in > a criminal manner, and law enforcement convinces Netcom to check the logs, > then more power to them. If someone sends mail discussing large doses of > vitamin C, when vitamin supplementys are banned a year from now, and the > FDA wants to arrest them, and Netcom allows them to see the mqueue then > that would be unfortunate indeed. I am running a remailer. Here is the > situation. What more can I offer? I would ask people to look at the > various remailers and ask in a street smart practical manner what the > pros and cons of each one is. Good advice. Caveat Emptor! > What, exactly, does the mqueue record? How long does it get saved? Here is an example of what sendmail might log to syslog: Feb 2 12:31:18 localhost: 15068 sendmail: AA15068: message-id= \ <199402021713.JAA08629 at mail.netcom.com> Feb 2 12:31:18 localhost: 15068 sendmail: AA15068: from= \ , size=4402, class=0, \ received from mailer.psc.edu (128.182.62.100) Feb 2 12:31:19 localhost: 15070 sendmail: AA15068: to=, \ delay=00:00:13, stat=Sent I have re-formatted the lines to make them easier to read... This is the log of you sending this mail to me... Here's my previous response, which I sent to the list, logged again... Feb 2 10:00:27 localhost: 11889 sendmail: AA11889: message-id= \ <9402021500.AA11889 at igi.psc.edu> Feb 2 10:00:27 localhost: 11889 sendmail: AA11889: from=, size=1391, class=0, received from local Feb 2 10:00:31 localhost: 11891 sendmail: AA11889: to=, delay=00:00:04, stat=Sent And here's the list sending it back to me... Feb 2 10:19:09 localhost: 13086 sendmail: AA13086: message-id= \ <9402021500.AA11889 at igi.psc.edu> Feb 2 10:19:09 localhost: 13086 sendmail: AA13086: from= \ , size=2028, class=0, \ received from mailer.psc.edu (128.182.62.100) Feb 2 10:19:11 localhost: 13089 sendmail: AA13086: to=, \ delay=00:00:02, stat=Sent If the mailer recieves a lot of messages, then it would not be easy (if at all possible to correlate the messages received with the id's that they were sent out to...). If the traffic load is small, then correlation is fairly easy. Similarly, if the load is very high, it might become easier -- if I set up a script which sent mail to a particular anonid every 2 seconds or so, I would probably be able to correlate, given access to the syslog logs. Of course, I could forgo the logs and just look at the packets passed on your network, but we were discussing the use of the syslog logs. > I needed remailers to maintain some simple privacy by distancing myself > from the character Xenon. Aside from traffic obscuring random messages, a forced, random delay and a medium sized load of traffic seem to be the best ways to defeat the use of the syslog logs. Disabling syslog calls in sendmail (or whatever you use for SMTP) would be an even better tack to take. Remember folks, even if I can't get root when the machine is up, I may be able to force it into single-user mode and access the logs then -- physical security of the machines [as well as software security] is an important consideration of *any* remailer you use. > No 5AM fone calls and letters from people asking me to send them PGP.... > I figured if I was going to become the largest volume user of the remailers, > I should become a remailer myself. The other option was to use the Netcom > account to directly mail out what I am sending to people, but that wasn't > as fun of an idea. I'm not advising you to not be a remailer, but you should be aware of the potential holes -- even if you can't do anything about them... If you're concerned with your own personal privacy, I can't think of a good way to ensure that you will not be "outed" from your anon-id. Even if you use a personal machine which connects to the network via a dialup slip IP pool, the provider is likely to keep logs of what machines have access to that pool and who their owners are... And, of course, a permanent connection (T1 or the like) is a dead give-away... We really need the IP security -- the proposal put forward by Mssr. Blaze and Mssr. Ioannidis for encrypted-IP would help.. but you still rely on having the other side *not* log... Jon Boone | PSC Networking | boone at psc.edu | (412) 268-6959 PGP Public Key fingerprint = 23 59 EC 91 47 A6 E3 92 9E A8 96 6A D9 27 C9 6C From talon57 at well.sf.ca.us Wed Feb 2 11:00:59 1994 From: talon57 at well.sf.ca.us (Brian D Williams) Date: Wed, 2 Feb 94 11:00:59 PST Subject: digital signatures/copyright Message-ID: <199402021858.KAA17982@well.sf.ca.us> -----BEGIN PGP SIGNED MESSAGE----- A question for Mike Godwin and other attorneys on the list: Could one make a case that the use of Digital signatures in messages imply's copyright retention by the author? Does digital signature=copyright or is it at least equivalent? Brian Williams Extropian Cypherpatriot "Cryptocosmology: Sufficently advanced comunication is indistinguishable from noise." --Steve Witham -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLU/2HdCcBnAsu2t1AQF15gP+IqS3o0gNeHng9BSqlk95KzmPwp3oo70p j2FVYHNOeUKgDSAAwvWr+p3/DOwTafSkJf4A5gW33NOKr0E9JZ4In349RAoueTku J94VMajT4i7yhOC8X41RPkVLlCltPDRo04SS8h5UFnEk/zFxiTkvXY9mpBcK3yUw vYY9pbmupSc= =KbXS -----END PGP SIGNATURE----- From mnemonic at eff.org Wed Feb 2 11:25:33 1994 From: mnemonic at eff.org (Mike Godwin) Date: Wed, 2 Feb 94 11:25:33 PST Subject: digital signatures/copyright In-Reply-To: <199402021858.KAA17982@well.sf.ca.us> Message-ID: <199402021924.OAA23853@eff.org> > A question for Mike Godwin and other attorneys on the list: > > Could one make a case that the use of Digital signatures in > messages imply's copyright retention by the author? I suppose one could, but, really, there's no issue of "copyright retention" out there. Post something to the Net, and it's copyrighted, and you hold the copyright. Doesn't matter whether you've digsigged it or not. > Does digital signature=copyright or is it at least equivalent? No. --Mike From Tomaz.Borstnar at arnes.si Wed Feb 2 11:35:32 1994 From: Tomaz.Borstnar at arnes.si (Tomaz Borstnar) Date: Wed, 2 Feb 94 11:35:32 PST Subject: New US keyserver now fully operational - pgp-public-keys@io.com In-Reply-To: <199402021313.NAA19622@wasabi.io.com> Message-ID: <9402021932.AA27987@toad.com> In-reply-to: Your message dated: Wed, 02 Feb 1994 13:13:22 GMT > The US-based keyserver 'pgp-public-keys at io.com' is now open to the public. I would like to set up server in Slovenia and don't want to reinvent wheel so I need server's software. Where can one get it? Thanks in advance. Tomaz From bob at USCWS4.gat.com Wed Feb 2 11:51:01 1994 From: bob at USCWS4.gat.com (bob harvey) Date: Wed, 2 Feb 94 11:51:01 PST Subject: No Subject Message-ID: <9402021945.AA12911@USCWS4.gat.com> unsubscribe bob at USCWS4.gat.com From nobody at qwerty.org Wed Feb 2 12:01:00 1994 From: nobody at qwerty.org (nobody at qwerty.org) Date: Wed, 2 Feb 94 12:01:00 PST Subject: New Remailer Up. Message-ID: <199402021959.LAA15215@mail.netcom.com> Jon wrote, " Aside from traffic obscuring random messages, a forced, random delay and a medium sized load of traffic seem to be the best ways to defeat the use ..." How LONG should the such a random delay BE, at max? I am not willing to add more than 10-15 minutes, max. Is this worth it then? Hours is just too primitive when it comes to electronic communications. Even minutes! -Xenon From reagle at gl.umbc.edu Wed Feb 2 12:05:33 1994 From: reagle at gl.umbc.edu (Joseph Reagle Jr.) Date: Wed, 2 Feb 94 12:05:33 PST Subject: test Message-ID: <199402022003.PAA24245@xsg02.gl.umbc.edu> Regards, Joseph M. Reagle Jr. | reagle at umbc.edu | It's celluar peptide cake with mint frosting! jreagl1 at umbc8.umbc.edu | -- Worf From smb at research.att.com Wed Feb 2 12:06:10 1994 From: smb at research.att.com (smb at research.att.com) Date: Wed, 2 Feb 94 12:06:10 PST Subject: digital signatures/copyright Message-ID: <9402022005.AA28855@toad.com> It's worth noting that U.S. copyright law makes explicit provision for copyrighting anonymous works. From nobody at qwerty.org Wed Feb 2 12:21:02 1994 From: nobody at qwerty.org (nobody at qwerty.org) Date: Wed, 2 Feb 94 12:21:02 PST Subject: system logging Message-ID: <199402022017.MAA20262@mail.netcom.com> PGP Slave, Could you please announce my full name, phone number, address, visa card number, a giff of my signature, height, weight and driver's licence number not only to the Cypherpunks mailing list but to many usenet groups as well, since you obviously feel I no longer wish to be known to the masses as Xenon, and I instead want them to start calling me and postal mailing me asking for copies of PGP. Thanks asshole. I thought the people on this list were concerned with privacy, but I was wrong. I mention Xenon in my personal .plan, but I ask people to let me keep the small amount of extra privacy I still retain. You wrote, "qwerty account or not, the public logs on netcom show more than enough info to trivially track people down." Trivial? And so you hack out the info that a message went from remailer A through qwerty and on to remailer B, at a certain time. You haven't tracked down anyone my friend. -Xenon From DBS5112 at ibm.MtSAC.edu Wed Feb 2 12:51:02 1994 From: DBS5112 at ibm.MtSAC.edu (DBS5112 at ibm.MtSAC.edu) Date: Wed, 2 Feb 94 12:51:02 PST Subject: unsubscribe Message-ID: <9402022047.AA29669@toad.com> (mailing to cypherpunks-request at toad.com doesn't seem to work)... please unsubscribe me from the list... thanxs From nobody at pmantis.berkeley.edu Wed Feb 2 13:05:34 1994 From: nobody at pmantis.berkeley.edu (nobody at pmantis.berkeley.edu) Date: Wed, 2 Feb 94 13:05:34 PST Subject: anonymous mail Message-ID: <9402022101.AA15882@pmantis.berkeley.edu> There's a jerk that's been mail-bombing me, and I can't do anything because he's root at his site. Would it be ethical to use a remailer to bomb him back? Or maybe I shoudl simply fakemail a message to alt.fan.rush-limbaugh at anon.penet.fi with his name and have the contents say something like 'Limbaugh sucks', or post to alt.sex.wanted with the subject 'SWF virgin seeks man for first time'. Any ideas on how to get someone back, or at least make life annoying? From mab at research.att.com Wed Feb 2 13:11:01 1994 From: mab at research.att.com (Matt Blaze) Date: Wed, 2 Feb 94 13:11:01 PST Subject: Notes on key escrow meeting with NSA Message-ID: <9402022105.AA18514@big.l1135.att.com> A group from NSA and FBI met the other day with a group of us at Bell Labs to discuss the key escrow proposal. They were surprisingly forthcoming and open to discussion and debate, and were willing to at least listen to hard questions. They didn't object when asked if we could summarize what we learned to the net. Incidentally, the people at the meeting seemed to base a large part of their understanding of public opinion on Usenet postings. Postings to sci.crypt and talk.politics.crypto seem to actually have an influence on our government. A number of things came out at the meeting that we didn't previously know or that clarified previously released information. What follows is a rough summary; needless to say, nothing here should be taken as gospel, or representing the official positions of anybody. Also, nothing here should be taken as an endorsement of key escrow, clipper, or anything else by the authors; we're just reporting. These notes are based on the collective memory of Steve Bellovin, Matt Blaze, Jack Lacy, and Mike Reiter; there may be errors or misunderstandings. Please forgive the rough style. Note also the use of "~ ~" for 'approximate quotes' (a marvelous Whit Diffie-ism). NSA's stated goals and motives for all this: * DES is at the end of its useful life * Sensitive, unclassified government data needs protection * This should be made available to US Citizens * US business data abroad especially needs protection * The new technology should not preclude law enforcement access They indicated that the thinking was not that criminals would use key escrowed crypto, but that they should not field a system that criminals could easily use against them. The existence of key escrow would deter them from using crypto in the first place. The FBI representative said that they expect to catch "~only the stupid criminals~" through the escrow system. Another stated reason for key escrow is that they do not think that even government-spec crypto devices can be kept physically secure. They do expect enough to be diverted to the black market that they feel they need a response. NSA's emphasis was on the foreign black market... There seems to be a desire to manipulate the market, by having the fixed cost of key escrow cryptography amortized over the government market. Any private sector devices would have to sell a much larger number of units to compete on price. (This was somewhere between an implication and an explicit statement on their part.) When asked about cryptography in software, "~...if you want US government cryptography, you must do it with hardware~". Clipper chips should be available (to product vendors) in June. You can't just buy loose chips - they have to be installed in approved products. Your application interface has to be approved by NIST for you to get your hands on the chips. An interesting point came up about the reverse-engineering resistance of the chips: they are designed to resist reverse engineering the data in the chip without destroying the chip. It is not clear (from the information presented at the meeting) whether the chips are equally resistant to destructive reverse-engineering to learn the skipjack algorithm. They said the algorithm was patented, but they may have been joking. ("~And if that doesn't scare you enough, we'll turn the patent over to PKP.~") The resistance to reverse engineering is not considered absolute by NSA. They do feel that "~it would require the resources of a national laboratory, and anyone with that much money can design their own cryptosystem that's just as strong.~" They repeated several times that there are "~no plans to regulate the use of alternate encryption within the US by US citizens.~" They also indicated they "~weren't naive~" and didn't think that they could if they wanted to. There were 919 authorized wiretaps, and 10,000 pen register monitors, in 1992. They do not have any figures yet on how often cryptography was used to frustrate wiretaps. They do not yet have a production version of the "decoder" box used by law enforcement. Initially, the family key will be split (by the same XOR method) and handled by two different people in the athorized agencies. There is presently only one family key. The specifications of the escrow exploitation mechanism are not yet final, either; they are considering the possibility of having the central site strip off the outer layers of encryption, and only sending the session key back to the decoder box. The escrow authorities will NOT require presentation of a court order prior to releasing the keys. Instead, the agency will fill out a form certifying that they have a legal authorization. This is also backed up with a separate confirmation from the prosecutor's office. The escrow agencies will supply any key requested and will not themselves verify that the keys requested are associated with the particular court order. The NSA did not answer a question as to whether the national security community would obtain keys from the same escrow mechanism for their (legally authorized) intelligence gathering or whether some other mechanism would exist for them to get the keys. The masks for the Clipper/Capstone chip are unclassified (but are protected by trade secret) and the chips can be produced in an unclassified foundry. Part of the programming in the secure vault includes "~installing part of the Skipjack algorithm.~" Later discussion indicated that the part of the algorithm installed in the secure vault are the "S-tables", suggesting that perhaps unprogrammed Clipper chips can be programmed to implement other 80-bit key, 32 round ciphers. The Capstone chip includes an ARM-6 RISC processor that can be used for other things when no cryptographic functions are performed. In particular, it can be used by vendors as their own on-board processor. The I/O to the processor is shut off when a crypto operation is in progress. They passed around a Tessera PCMCIA (type 1) card. These cards contain a Capstone chip and can be used by general purpose PC applications. The cards themselves might not be export controlled. (Unfortunately, they took the sample card back with them...) The card will digitally sign a challenge from the host, so you can't substitute a bogus card. The cards have non-volatile onboard storage for users' secret keys and for the public keys of a certifying authority. They are building a library/API for Tessera, called Catapult, that will provide an interface suitable for many different applications. They have prototype email and ftp applications that already uses it. They intend to eventually give away source code for this library. They responded favorably to the suggestion that they put it up for anonymous ftp. Applications (which can use the library and which the NSA approves for government use) will be responsible for managing the LEAF field. Note that they intend to apply key escrowed Skipjack to other applications, including mail and file encryption. The LEAF would be included in such places as the mail header or the file attributes. This implies that it is possible to omit sending the LEAF -- but the decrypt chip won't work right if it doesn't get one. When asked, they indicated that it might be possible wire up a pair of Clipper/Capstone chips to not transmit the LEAF field, but that the way to do this is "~not obvious from the interface we give you~" and "~you'd have to be careful not to make mistakes~". They gave a lot of attention to obvious ways to get around the LEAF. The unit key is generated via Skipjack itself, from random seeds provided by the two escrow agencies (approximately monthly, though that isn't certain yet). They say they prefer a software generation process because its correct behavior is auditable. Capstone (but not Clipper) could be configured to allow independent loading of the two key halves, in separate facilities. "~It's your money [meaning American taxpayers].~" The LEAF field contains 80 bits for the traffic key, encrypted via the unit key in "~a unique mode ~", 32 bits for the unit id, and a 16 bit checksum of some sort. (We didn't waste our breath asking what the checksum algorithm was.) This is all encrypted under the family key using "~another mode ~". They expressed a great deal of willingness to make any sort of reasonable changes that vendors needed for their products. They are trying *very* hard to get Skipjack and key escrow into lots of products. From pmetzger at lehman.com Wed Feb 2 13:25:34 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 2 Feb 94 13:25:34 PST Subject: anonymous mail In-Reply-To: <9402022101.AA15882@pmantis.berkeley.edu> Message-ID: <199402022122.QAA05944@snark> nobody at pmantis.berkeley.edu says: > There's a jerk that's been mail-bombing me, and I can't do anything > because he's root at his site. Would it be ethical to use a remailer to > bomb him back? > > Or maybe I shoudl simply fakemail a message to > alt.fan.rush-limbaugh at anon.penet.fi with his name and have the contents > say something like 'Limbaugh sucks', or post to alt.sex.wanted with the > subject 'SWF virgin seeks man for first time'. > > Any ideas on how to get someone back, or at least make life annoying? Call his network service provider and explain that he's violating federal law by attempting to disrupt your service from his site. Alternatively, rig your sendmail.cf file to forward any mail he sends you back to him. .pm From beker at netcom.com Wed Feb 2 13:45:33 1994 From: beker at netcom.com (Brian Beker) Date: Wed, 2 Feb 94 13:45:33 PST Subject: Anonymous mail service up for alpha testing In-Reply-To: Message-ID: On Wed, 2 Feb 1994, Sameer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > I've written a small anonymous mail service, and it's now > available for testing. There's no security, and I'll be keeping logs, > so don't think that it's secure, in any way. Excellently and well done, Sameer! Ah, the pleasure of seeing a budding cypherpunk do us all some good. Keep us posted. Mucho Obligado, Amigo, brianB From paul at poboy.b17c.ingr.com Wed Feb 2 13:51:01 1994 From: paul at poboy.b17c.ingr.com (Paul Robichaux) Date: Wed, 2 Feb 94 13:51:01 PST Subject: Notes on key escrow meeting with NSA In-Reply-To: <9402022105.AA18514@big.l1135.att.com> Message-ID: <199402022151.AA02282@poboy.b17c.ingr.com> Thank you very much for a) taking the time to meet with these people and b) posting a lucid and timely summary to the list. -Paul Robichaux -- Paul Robichaux, KD4JZG | "Though we live in trying times perobich at ingr.com | We're the ones who have to try." - Neil Peart Intergraph Federal Systems | Be a cryptography user- ask me how. From nate at VIS.ColoState.EDU Wed Feb 2 13:51:12 1994 From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons) Date: Wed, 2 Feb 94 13:51:12 PST Subject: WWW Anonymous Remailer Software release Message-ID: <9402022148.AA12174@vangogh.VIS.ColoState.EDU> -----BEGIN PGP SIGNED MESSAGE----- I have modified my WWW Anonymous remailer interface and put it up for ftp on vangogh.vis.colostate.edu in /pub/nate/remailer There is a README in there which should explain how to set it up, but if I missed anything, please tell me. The remailer no longer needs you to tell it that you're using the remailers, it just knows. Hope you like it, - -nate - -- +-----------------------------------------------------------------------+ | Nate Sammons | | Colorado State University Computer Visualization Laboratory | | Data Visualization/Interrogation, Modeling, Animation, Rendering | +-----------------------------------------------------------------------+ From qwerty-remailer at netcom.com Wed Feb 2 13:55:33 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Wed, 2 Feb 94 13:55:33 PST Subject: Remailer FAQ. Info request! Message-ID: <199402022153.NAA10067@mail.netcom.com> I have only seen unsatisfying info on the remailers out there. If people know the details up front, the Cypherpunk remailers will become more popular. Different people have different needs for remailing as well. Please help me out with this. I would appreciate info from operators as well as users of remailers. If you do not want to disclose a specific bit of info, I will enter it as "N/A". If I get no answer at all I will leave it as "?". Send responses to qwerty at netcom.com. If you wish your remailer be taken off the list I will comply. -Xenon Xenon's Full Disclosure Remailer List. Remailer Who's Fast? PGP? Logs? Comments ---------- ----- ------- ------- ------ ------------------------------------ bsu-cs NSA? + ? ? Strips Subject. catalyst Scott + Y(2.3a) ? choas NSA? + ? ? Strips Subject. cicada Eric ++ N ? Tread lightly. dis.org NSA? - Y(2.3a) ? extropia NSA? ? Y(2.3a) ? Only accepts PGP remailing. jarthur Eli +/-- ? ? menudo NSA? -- ? ? merde NSA? -/-- ? ? batches out at midnight?? penet.fi Julf -- N Stats <48K. Overloaded. Slow. pmantis Eric ++ N ? Tread lightly. qwerty Xenon + Y(2.3a) Count rosebud NSA? ++/- Y(2.3a) ? shell Hal ++/+/- Y(2.3a) Stats+ soda Eric ++/- N Stats+? Can post to Usenet ++ <5 min - ~10-30 min delay -- pinging isn't practical due to long delays + ~10 min +/- sometimes +, sometimes - Normal internet mail delays are common, and are not equivalent in the two directions between any two remailers. Mail still gets through. Full: full copies of all mail is archived. My large volume mailing should help put a stop to this. Stats: logs of when mail was remailed. Stats+: logs of when and where mail was remailed. None: operator keeps no logs. Count: simple counter. bsu-cs nowhere at bsu-cs.bsu.edu catalyst catalyst at netcom.com chaos remailer at chaos.bsu.edu cicada hh at cicada.berkeley.edu dis.org remailer at dis.org extropia remail at extropia.wimsey.com jarthur ebrandt at jarthur.claremont.edu menudo nobody at Menudo.UH.EDU merde remailer at merde.dis.org penet.fi anon.penet.fi pmantis hh at pmantis.berkeley.edu qwerty qwerty at netcom.com rosebud elee7h5 at rosebud.ee.uh.edu shell hfinney at shell.portal.com soda hh at soda.berkeley.edu Discontinued remailers still on some lists out there: phantom at mead.u.washington.edu remail at tamaix.tamu.edu sameer at netcom.com (spelling?) sameer at berkeley.edu (spelling?) cdodhner at indirect.com remailer at entropy.linet.org?? 00x at uclink.berkeley.edu? hal at alumni.cco.caltech.edu? remail at tamaix.tamu.edu? remailer at entropy.linet.org? Background on each remailer: bsu-cs: Run by Chael Hall. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Comments: ?? History: ?? catalyst: Run by Scott Collins. Machine: personal dial-up account on Netcom. Problems policy: ?? Contact ?? Software: ?? Comments: ?? History: ?? chaos: Run by ?? Machine: ?? Problems policy: ?? Contact ?? Software: ?? Comments: finger remailer.help at chaos.bsu.edu for info. ?? History: ?? cicada: Run by Eric Hollander. Machine: ??? Problems policy: ?? Contact ?? Software: ?? Comments: being "phased out". dis.org: Run by ?? Machine: ?? Problems policy: ?? Contact ?? Software: ?? Comments: ?? History: ?? extropia: Run by ?? Machine: ?? Problems policy: ?? Contact ?? Software: ?? Comments: ?? History: ?? jarthur: Run by Eli Brandt. Maching: ?? Problems policy: ?? Contact ?? Software: ?? Comments: ?? History: ?? menudo: Run by ?? Maching: ?? Problems policy: ?? Contact ?? Software: ?? Comments: Stores messages and sends them at midnight?? History: ?? merde: Run by ?? Maching: ?? Problems policy: ?? Contact ?? Software: ?? Comments: ?? History: ?? penet.fi: Run by Julf (last name?) Machine: ?? Operator owned. Problems policy: Account revokation. Contact ??@anon.penet.fi. Software: custom. Comments: ?? History: ?? pmantis: Run by Eric Hollander. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Comments: being "phased out". History: ?? qwerty: Run by Xenon. Machine: dial-up account on Netcom. Problems policy: "What problems?". Contact qwerty at netcom.com. Software: Hal's remailer. Comments: ?? History: Up 2/94. Set up by Xenon who needed more remailers to use to send PGP info to people with, since anon.penet.fi was overloaded. rosebud: Run by Karl Barrus. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Comments: ?? History: ?? shell: Run by Hal Finney. Machine: ?? Problems policy: ?? Contact ?? Software: Hal's Remailer.? Comments: ?? History: ?? soda: Run by Eric Hollander. Run by: ?? Machine: ?? Problems policy: ?? Blocking of addresses. Mail sent to problem causer. Contact ?? Software: custom. ?? Comments: Was keeping full logs till Xenon's bulk mailing venture. ?? History: ?? Remailer Public Keys: Anonymous Remailer 1024-bit key, Key ID C0EA49, created 1993/08/30 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQCNAiyBTjoAAAEEAMIKpRnqXb82TOQpx/vEDwGPXndXaxtfiZeSLZqullWCEbd4 YkCHG/F1i3Wzq4Pgz6nSbb58vMS5RonY7+ZC6IHI8zBpp9oMW3u+lqbk8Z61x49d xwAKlE7Zsk/pOeGrqbsidm83WUqlSGgyOpvq0A8LzT4+WPra8ZvHue9jwOpJAAUR tChBbm9ueW1vdXMgUmVtYWlsZXIgPGNhdGFseXN0QG5ldGNvbS5jb20+iQCVAgUQ LIaqhIOA7OpLWtYzAQH4sgQAsc6s3X75LwWTV65Dw76wdSRKuoI57F2ZZWjSOIQK n1CWUn6YEYOIs3kkdHNd0uz9Mspoy+6BsnWGSW11r8k88VThEoVpJ74o91apR1ML yCEdD7O/+nZK8N484+mN2BcKOdeze4QvgTt+qHHUd+Q5alW9VfXtbNImmSnI3FC/ 8n4= =Hh6a -----END PGP PUBLIC KEY BLOCK----- Remailing Service 512-bit key, Key ID 64E8A7, created 1993/03/05 Also known as: Anonymous Remailer -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQBNAiuX3kAAAAECAMd6YkS3ylajgNSzX+wYLrpW03D+99OFvePQLlR5N+R5iZBr y4FbAMeDj+eCeEAqiEyNjUxHN5tGlqx1g6tk6KcABRG0JFJlbWFpbGluZyBTZXJ2 aWNlIDxyZW1haWxlckBkaXMub3JnPokAVQIFECwomeN8p7i9YJH3xQEBDhEB/A7+ RLEw2bGJeBdBy0yXn5mIenda/tHHs9NGXJZR5BvOsU9EwVY+9s86E33R2/tgqAjY UYc5MiWS0r1+H9Zw+FeJAJUCBRArmsesg4Ds6kta1jMBAW4zA/4waabkcIHN93Jy /9OMXhRDqrRf2kickmeUWOGHF0KALLo37kAqfDvMNDtFs1u3WbdaBWdTSiLR8qIM 6TQNq0IEhAeny07AVweLlIpJc7lVN7biHqVIPknxJTAI/xscybuMUin3yALzFpWR 54uFMbd45iuKWBJ2/IGdUYcd39H0FbQsIEFub255bW91cyBSZW1haWxlciA8cmVt YWlsZXJAdXR0ZXIuZGlzLm9yZz6JAJUCBRArmsmdg4Ds6kta1jMBAbdwA/9m2GYJ 978xxchux7nnl4HAo3N+A2Nx+n40kQftWNiyJwivrG8kYwDI24QYaUpr2l6+2HDd xedEOFsX6DiHbDQK5J7dGYOigASmZHPs39lEdJ3AHvrTVYVYjOxBMQ2W6p+Q5rbn qxfmVlqRMzPRosPJ1gpbfcTzIpqznwSTl7tztQ== =v3Hk -----END PGP PUBLIC KEY BLOCK----- Remailer 1024-bit key, Key ID B5A32F, created 1992/12/13 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQCNAisrAP0AAAEEAJr3OwIfOIOoh9JndwwqFg+VyWFTAyM8S0B7wyGKI+A9sMAB mbSOIU52EszvLdZk8NH8mrOD9m3EZlt9gXOjln881RMilAunnzdXaJ6ffBKqPL+l yiefCbCo6wScVNfMSV6Di/2HMoFzVqukwRjTx8lqKt6hgy0uedtwcCemtaMvAAUR tCVSZW1haWxlciA8cmVtYWlsQGV4dHJvcGlhLndpbXNleS5jb20+iQCVAgUQK2SV p4OA7OpLWtYzAQG8eQP9F9ye/F/rXhJLNR5W/HV5k+f6E0zWSgtmTTWUYyydfJw+ lKDEDH6v+OFOFE3+fuTIL5l0zsNMSMdF5u7thSSWiwcFgaBFQF9NWmeL/uByOTSY tsB6DQSbw656SBH7c7V7jvUsPit/DubwBXZi9sOlULau3kQqXeeQxPhNE+bpMy6J AJUCBRArKwSLk3G+8Dfo40MBAXYAA/4hCVDFD0zG47pYPMg+y7NPE5LktWt2Hcwt Z4CRuT5A3eWGtG8Sd5QuHzbE4S9mD3CFn79bxZi0UDhryD8dsCG4eHiCpAcZqSvR JSkpgamdRaUQHNmMxv5goxHhRem6wXrKxZQNn5/S0NtQOrS6QKhFlGrzDIh/2ad1 J9qpyzJ/IYkARQIFECsrA9RLrSJixHgP9wEBNcEBewWpzywKk/SBDwocXebJmsT6 zug/ae78U/cu9kTX620Xcj1zqOdx9Y9Ppwem9YShaQ== =I7QE -----END PGP PUBLIC KEY BLOCK----- jarthur remailer c/o 512-bit key, Key ID 7D154B, created 1993/04/04 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQBNAiu+hVUAAAECAMVjEfl2IMNgSOJ+/fx1V6EbH50ofa6K4r1PBKMmkcHQextP ghwC4lXIgaAWUlLJ9x61+qf4jB5fpNUZLrF9FUsABRG0NWphcnRodXIgcmVtYWls ZXIgIGMvbyA8ZWJyYW5kdEBqYXJ0aHVyLmNsYXJlbW9udC5lZHU+iQCVAgUQK8M/ BIOA7OpLWtYzAQGJRAP9GIVi0qoQW4bjU9sikIPG4zIEbQ9O3rU1vd2uCrrnGQMM tdE9NoOx4umoVZKYTpCc96TlFQetb2UVd9JhaayXO7+nwNNHYgApkRJboolq9UzU wCRBA8k1EMAkdzCjzYglpZIQJz2yNP50Izu7g2LMbC1pHQX3CHVL7YlQrKGNLz4= =ItNk -----END PGP PUBLIC KEY BLOCK----- Qwerty Remailer 1024-bit key, Key ID 5505D9, created 1994/02/01 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQCNAi1NtgAAAAEEALD07N5RllpklGhOQaiYtRupb+8Jm1M34ya8rxmcNUCVndcb JgH9EW1Z2VvkJ3vTcEOOBK9jM/HCIGDqBbQZR8VOLbLNOD7VQIzTpyTOmZJCMSZG bqZtRtP6KDtMcTx1SgHq9LiRNz5YUyB3WOV963y8W/x00QS4yGkgCDZkVQXZAAUR tCNRd2VydHkgUmVtYWlsZXIgPHF3ZXJ0eUBuZXRjb20uY29tPokAlQIFEC1OzEgE sxus60J9UQEB224D/jUcYRnXmIj9nt4Y7sjGYTmO+v7b9W+rsxYLn6+hCGmx5iQJ zPr3ggvm8ylBZnNp3WUxssDlb9GyiK801vzm6HDXWd/yCeGXHX7YB2DDFd5WrK70 /XGTMGv3gvNnExIM+UVv5tl8y/YXOfeLWWGttD6a60MkUNxAOGT9qBsUTqJNiQCV AgUQLU3TdWkgCDZkVQXZAQH1ygP/TCY7T0PdNVRUVbEpN9YsbxFKhFT/7+hZTySr Md0j2GrObjcRc7aa0c9lEZrtKpaDCJkgF+7k20z1eQpw7zD/dO+ZsSqni62TLGYa pdTsAiYbev90Nb+1S2ST36KvIgJSmQS6zvgpToTRpGwYhJhqTZhTo8Z2U5ufb+SF TsNMd0Q= =BXnK -----END PGP PUBLIC KEY BLOCK----- Remailer (remailer at rebma.mn.org) 1024-bit key, Key ID BA80A9, created 1992/11/26 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQCNAisUI2QAAAEEAKgm07Hsje5KpmXYd5azk0R6AES+qK7LcofnVGojUs7GBghD WbwrmW8oOEOhRorlShRALKeYspV4xYIw4WDkJcJxuf1B254scz1urF/Eem3zPW9b yPAx7W/cGwvs6SouZvFcSDq4v1zApvGE9hP4szPzHeGmVr0NVNeaDK0guoCpAAUR tCBSZW1haWxlciAocmVtYWlsZXJAcmVibWEubW4ub3JnKYkAlQIFECtkldODgOzq S1rWMwEBnx8D/1p9vNDfnSzgKhd0q0xF0KTQWBzbQgXFeWLTUwLPLN30vGQRZHVc IrOSzjCOSflhcl0zc7tp7q+GQkVT5P/PIUG0yeL0mFi+oUswcws14LRaelYmVbgw OsjwJ7g4vwKICqzOWRVsdtSurMfw/65LzdgSUNPS18pGpD/4MJF3kHpkiQCVAgUQ KxQkYRiQVHeOVJ+HAQHXOAP/Usb0O200RU8V13GRQs/D4CSRuZKiWuolSZXH/fLd BLUC1b69WoXTKGBaC+DvvRvv7EyfDM78jWeHQUrayF3UmTHgVUIDly3KpTNUWOTU 0TpVppFzkG8EPWdTG1SF5HRZcNznR/4A0eBE2THbYwZG+mGx4zJer86TzyilKfsM is4= =jbyA -----END PGP PUBLIC KEY BLOCK----- remailer03 1022-bit key, Key ID ABFBB3, created 1992/12/02 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQCNAiscKOYAAAED/jmrZbh5t5HgEHDGE2zzFZx3sIplEjIFRFsLpCfJYBfN36Rm uT8VGIyCcUSmCTqEOJ5HJZF58CUCOsy3B215ptOvbZdGijC3Qs7FbtGHKGA49q0v gBgVIcjjyppRI9YjfqlI2gUKDLPceCTw20ODAA7UTKYIa3IBS32zjcrFq/uzAAUR tCZyZW1haWxlcjAzIDxlbGVlN2g1QHJvc2VidWQuZWUudWguZWR1PokAlQIFECtk lUeDgOzqS1rWMwEBUdAEAIosaOm/+kTsQI53GAqPXr08v5AAfwup5lDiUbCWp17C ueYHZrP4zolAqQ7kyWrkIeHgJHkX3yB6YH/jQ0MeDZERXS69kq2SGVQSH6inGoF9 3WerfGRpdONa597JVcRpklzMUz6bmXnhsiEm/K1FP9pNOZYyS6h/3gs92ikezq3X iQBVAgUQKxwo79I3XvyZ21fpAQG27AIAk7r8plkjpH1X9uQcsqFqjdjJtXGmHCeA dLV7tiviHlljDe2RqOKkjfFsQtzZV+yjCNXr8OhW0TiE0J5WqBwECA== =VK3C -----END PGP PUBLIC KEY BLOCK----- Remailing Service 510-bit key, Key ID 5620D5, created 1992/11/15 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQBNAisGf+IAAAEB/ieS6th8hI1QBjGpmctVvsIxZBtmpykVXc3psh0XVfH4sECS ugouk2zm/PJtt59A2E5SO3xjpDjeKlkQ745WINUABRG0LFJlbWFpbGluZyBTZXJ2 aWNlIDxoZmlubmV5QHNoZWxsLnBvcnRhbC5jb20+iQCVAgUQK3Azm4OA7OpLWtYz AQHzawQAwZPaJUR9iNwyKMDm4bRSao0uu381pq6rR3nw0RI+DSLKTXPqDaT3xBmL dVv1PVguLcoao/TRLkAheV7CIxodEiI9lAC2o6lqSXCP+vm3jYmulSgUlKafXYbj LAbZpsKRAUjCpyx0wlYmoHhkA+NZDzMcWp6/1/rM/V1i4Jbt2+GJAJUCBRArBpKv qBMDr1ghTDcBASTlBACfTqODpVub15MK5A4i6eiqU8MDQGW0P0wUovPkNjscH22l 0AfRteXEUM+nB+Xwk16RG/GdrG8r9PbWzSCx6nBYb7Fj0nPnRPtS/u69THNTF2gU 2BD0j2vZF81lEHOYy6Ixao2b6Hxmab2mRta2eTg7CV6XP3eRFDPisVqgooAWgw== =arSc -----END PGP PUBLIC KEY BLOCK----- From jim at uu4.psi.com Wed Feb 2 14:05:33 1994 From: jim at uu4.psi.com (jim at uu4.psi.com) Date: Wed, 2 Feb 94 14:05:33 PST Subject: contemplating remailer postage Message-ID: <9402022200.AA01456@uu4.psi.com> Although lot of people (including me) have mentioned Digital Stamps, or remailer postage, when describing advanced remailers, I've yet to see a good description of a practical remailer postage mechanism. I assume it will be (or has been) modeled after one of the Chaumian digital cash protocols. If there has been work done on a remailer postage mechanism, could somebody post the details? (or a reference) Here's what I think would make up a practical remailer postage mechanism: I think that each remailer should issue its own stamps, rather than using a central digital postage service. The existence of a centralize digital postage service creates a single point of failure for the entire remailer system. It also complicates the protocol needed to validate digital stamps and check for double spending. Of course, having each remailer issue its own stamps would increase the complexity for the users of the remailer system. However, I believe the increased user-side complexity can be completely hidden within a good set of scripts (e.g. the scripts could maintain a subdirectory for each remailer to hold stamps for that remailer). If all digital stamps have the same "denomination", then the protocol for obtaining stamps can be greatly simplified. You wont need to engage in a cut-and-choose protocol with the remailer (see page 121, Digital Cash Protocol #4, Applied Cryptography). To obtain 100 stamps from R1, Bob would generate and blind 100 uniqueness strings (random numbers large enough that they are unlikely to collide with anyone else's) and send them all to R1. R1 would simply sign all 100 of them and send them back. Bob would unblind them and store them in his "R1_stamps" subdirectory. Given the low value of individual stamps, it is probably not necessary to try to determine who is attempting to double spend stamps. Therefore, stamps wouldn't need the identity strings used in Digital Cash Protocol #4. Also, since the remailer is both "bank" and "merchant", there's no chance of the "merchant" cheating the "bank". ... When Bob wants to route a message through R1, he place an R1 stamp at the appropriate level within the nested envelopes. These stamps can also be used in SASE's. When R1 receives a stamped message (or SASE) it will check the signature of the stamp. If the signature doesn't verify, R1 discards the message. If the signature verifies, R1 checks the uniqueness string against his archive of "used" stamps. If the uniqueness string is present in the archive, the stamp has already been used and the message will be discarded. If the uniqueness string is not present in the archive, R1 will route the message on to the next hop. Finally, R1 places the uniqueness string in his "used stamp" archive. Seems simple enough. The major sticking point (to me) is the remailer's "used stamp" archive. This could grow to be very large. Something needs to be done to keep the archive from getting too large. One idea is to have the remailer periodically change the key it uses to sign stamps. Changing the "stamp validation key" effectively invalidates all unused stamps signed by that key. If you haven't used the stamp by that time, you're out of luck. The remailer can purge its "used stamp" archive whenever it changes its "stamp validation key". Of course, invalidating peoples' unused stamps out from under them is not a nice thing for a remailer to do. The remailer could provide a mechanism whereby people could get new stamps from old, unused stamps. To make this work, the remailer would have to retain the previous "used stamp" archive for a while to give people a chance to get new stamps. However, there still needs to be a limit on how long the remailer retains the "used stamp" archives for old validation keys. If you wait too long, you would lose any chance to get new stamps from old. Comments welcome. Jim_Miller at suite.com From reagle at gl.umbc.edu Wed Feb 2 14:45:33 1994 From: reagle at gl.umbc.edu (Joseph Reagle Jr.) Date: Wed, 2 Feb 94 14:45:33 PST Subject: Quantum Crypto. In-Reply-To: Message-ID: [Here is the conclusion to my QC paper, unfortunately I can't get the whole file into a PS format because of the faulty file translators in the Mac applications.] Conclusion Quantum cryptography has proven to be an interesting and novel application of quantum physics. It does posses some severe limitations that I have considered. Optimistic predictions of it�s affective area is still far below 100 km. This may of course change depending on technological development. It has been suggested to me that one could have secure stations where interception and reception of the message would be allowed. [10] This is possible, but weakens the �absoluteness� that is the appeal of quantum cryptography. A basic assumption is made previous to the research mentioned: that Eve will not interfere on the public channel. It could be very possible that Eve would set herself up between Alice and Bob on the quantum and private channels, and act as a relay station that I mentioned in the first point. She would have to impersonate both Alice and Bob, who in reality might not even be on the same public and quantum channels, but merely think they are. Public key methods could be used for authentication, but this destroys the motivation for the use of quantum cryptography. I feel the solution here is in the definition of �public�. Meaning a random and public switching of public channels, phone numbers and such. Even this may be subverted by a very powerful Eve who may also control the phone company�s switching circuits. Perhaps further thought can resolve this issue, but the problem of identification and authentication on the public channel is severe. Further, quantum cryptography is subject to a denial of service attack. If Eve wishes, she may destroy the unique and expensive quantum channel, or merely observe everything that goes by, not caring to read the information, just making it unsuitable for use by Alice and Bob. Ekert�s concept of keeping shared EPR pairs in permanent storage (perhaps using a superconductor to warehouse keys when the quantum channel is open) is not yet feasible, and it will be necessary to keep these keys somewhere , but the security of keys is not a problem unique to quantum cryptography. I look forward to the resolution of these issues and the further development of the technology that will allow quantum cryptography to become a �practical� security mechanism. 1. C. Bennett. Science.. vol. 257, p. 752 (August, 1992). 2, C. Bennett, G. Brassard, and A. Ekert. Scientific American. p. 50 (Oct., 1992) 3. A. Ekert, Phys. Rev. Lett. vol. 67, p. 661 (1991) 4. C. Bennet, and G. Brassard, Phys. Rev. Lett. vol. 68, p. 557 (1992) 5. A. Ekert, J. Rarity, P. Tapster, and G. Palma, Phys. Rev. Lett. vol. 69, p. 1293, (1993). 6. A. Muller, J. Breguet, and N. Gisin. Europhs. Lett., vol. 23 (6), p. 383 (1993). 7. S. Barnett, and S. Phoenix. Phys. Rev. A, vol 48 (1), p. R5, (July, 1993). 8. C. Bennett. Phys. Rev. Lett. vol 68 (21), p. 3121 (1992) 9. D. Denning. Cryptography and Data Security. 10. Personal e-mail as a follow-up to a posting to sci.crypt. I have unfortunately lost the person�s name. From qwerty-remailer at netcom.com Wed Feb 2 15:01:01 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Wed, 2 Feb 94 15:01:01 PST Subject: New remailer up. Message-ID: <199402022259.OAA21968@mail.netcom.com> Out of personal curiousity concerning the claims of how trivial "traffic analysis" of the qwerty or catalyst remailers on Netcom would be for "anyone" to carry out, I offer $20 to the first person to reveal from which SITE this message originated from. Please do not announce my name or login ID. Just the site. I am logged into a friend's account and I am remailing this with no encryption just through qwerty at netcom.com. It is now 5:41 PM EST. You do not have to reveal your methods to receive the award, which I will mail to you. Happy hacking you WIMPS. If you wish to remain anonymous, mail the answer to qwerty at netcom.com and my lips are sealed except for announcing success. -Xenon From pmetzger at lehman.com Wed Feb 2 15:15:33 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 2 Feb 94 15:15:33 PST Subject: New remailer up. In-Reply-To: <199402022259.OAA21968@mail.netcom.com> Message-ID: <199402022311.SAA06225@snark> Tapping Netcom's net connections would take more than $20 of effort. Up it to $50,000 and I'll happily take on your offer. However, I am going to need assurances that the money will actually be paid. Perry Metzger qwerty-remailer at netcom.com says: > Out of personal curiousity concerning the claims of how trivial > "traffic analysis" of the qwerty or catalyst remailers on Netcom > would be for "anyone" to carry out, I offer $20 to the first > person to reveal from which SITE this message originated from. > Please do not announce my name or login ID. Just the site. I am > logged into a friend's account and I am remailing this with no > encryption just through qwerty at netcom.com. It is now 5:41 PM EST. > > You do not have to reveal your methods to receive the award, which > I will mail to you. Happy hacking you WIMPS. > > If you wish to remain anonymous, mail the answer to qwerty at netcom.com > and my lips are sealed except for announcing success. > > -Xenon From daemon at fidonet.fidonet.org Wed Feb 2 12:40:28 1994 From: daemon at fidonet.fidonet.org (Gateway Mail Daemon) Date: 02 Feb 94 15:40:28 -0500 Subject: Message returned to sender Message-ID: (Invalid host or address: cypherecho at f21.n216.z1.fidonet.org) The address you are trying to send to does not exist on this side of the gateway. If you have any problems, email the postmaster of this gateway for assistance. Please note that the biggest reason for bounced messages is due to a simple typo. Please, double check your spelling! A copy of the original message is listed below: -----8< cut here 8< ------------------------------------ >From owner-cypherpunks at toad.com Wed Feb 2 12:30:16 1994 Received: from relay2.UU.NET by zeus.ieee.org (4.1/Z-3.46-01.31.94) id AA12961; Wed, 2 Feb 94 12:30:16 EST Received: from toad.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwbnp25485; Wed, 2 Feb 94 12:25:12 -0500 Received: by toad.com id AA24880; Wed, 2 Feb 94 09:11:06 PST Received: by toad.com id AA24877; Wed, 2 Feb 94 09:11:05 PST Return-Path: Received: from ghostwheel.bga.com ([198.3.118.4]) by toad.com id AA24873; Wed, 2 Feb 94 09:10:58 PST Received: from wixer.UUCP by ghostwheel.bga.com with UUCP id AA05678 (5.65c/IDA-1.4.4 for cypherpunks at toad.com); Wed, 2 Feb 1994 11:09:24 -0600 Received: by wixer (5.65/1.35) id AA09079; Wed, 2 Feb 94 11:08:26 -0600 Message-Id: <9402021708.AA09079 at wixer> Subject: Archiving on Inet To: cypherpunks at toad.com Date: Wed, 2 Feb 94 11:08:26 CST From: Jim choate X-Mailer: ELM [version 2.3 PL11] I would like to ask all subscribers who are not addressing the issues of this question to please move their responces to private mail. I have no interest in exploring your personalities or views of others personalities. If a global network is to survive there must be a commen understanding of what is public domain and what is private or commercial. At the present time this is completely new ground. The fact is that the copyright laws of the US are of little interest to a net user in Moscow, Russia or Pretoria, S. Africa. If as a cpunk you don't feel that a anonymous regulatory agency can protect your privacy why do you feel they can protect your intellectual property? The issue has direct bearing on both intellectual property and the wide spread use of cryptographic techniques. As a active cpunk it seems to me that your first motivation after producing the actual code is to creat a atmosphere where it can be used for the betterment of all. To create a useable global community (what I am striving for) it seems to me that entries on that network must be public domain by default. Otherwise every country who joins, and by reduction every potential user, will have to agree on how to recompense each and every user who desires to be paid for their submissions. This, to me, leads incontrovertibly to the conclusion of a beurocratic nightmare that will not significanly assist anyone other than the regulatory agencies. The only other answer that seems even close to working (and I consider this a stretch of the imagination) is one where everyone is given access for free and the governments regulate the traffic completely and pat for it with tax dollars. As to the issue as it applies to community bbs'es. I run such a system and am in the process of getting it on the net. As part of this project I have 2 other systems that I will be providing feeds for. These systems are all run by individuals who have these boxes sitting in their den. By insisting on a priori copyright of all material it is my opinion that you are creating a situation which will prevent the growth of such systems. Now if we don't have regulatory agencies and the sites are indipendant (and I assume self supporting) how can we expect some Joe or Jill to put up a system to help the people in their neighborhood if they have to keep looking over thier shoulders for the copyright police? The answer is they won't put up such systems and we all loose. By providing strong crypto tools for business and individuals to protect their intellectual and commercial property we are creating an open door atmosphere which motivates people to join the network for their own enjoyment and edification. This to me is more important than keeping the present view (as applied to non-networked environments) of copyright. It is time that we as uses of Internet set a precedence before the legislators set one for us that will in the long run only assist those already in power by strangthening the need for regulatory agencies. I strongly suggest that you all consider this idea from the global and long term view. I think you will find that the view "information wants to be free' is the way to go. To this end I propose that organizations such as EFF and cpunks take the position of a priori public domain status of network submissions. Also that all individuals who wish to retain intellectual or commercial rights either use strong crypto w/ e-mail distribution of keys or a change be implimented in message headers such that sites who don't wish to carry such material can filter it, along with this should be a requirement that any such non- crptographicly secure material must contain a fair use policy at the beginning of each and every document. It is time we quite letting big brother tell us what we can do with our ideas and how to distribute them. From qwerty-remailer at netcom.com Wed Feb 2 16:01:02 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Wed, 2 Feb 94 16:01:02 PST Subject: New remailer up. Message-ID: <199402022358.PAA02516@mail.netcom.com> Perry Metzger wrote, "Tapping Netcom's net connections would take more than $20 of effort. Up it to $50,000 and I'll happily take on your offer. However, I am going to need assurances that the money will actually be paid." This is exactly the point I was trying to make. I wanted the word "trivial" to be clarified by those who were being so vocal about dismissing a remailer on Netcom. You'll also need a good lawyer when Netcom finds your tap ;-). But I'm sure some skilled hacker will be able to tell me the site and I'll happily be out $20, in say, a couple days? No use hacking my password, as I keep no logs (for now). The reason it's only $20, is that I am indeed honestly interested in knowing something about my remailer's security, and I don't know enough internet/Unix to risk being a total sucker. -Xenon From lefty at apple.com Wed Feb 2 16:06:13 1994 From: lefty at apple.com (Lefty) Date: Wed, 2 Feb 94 16:06:13 PST Subject: New remailer up. Message-ID: <9402030002.AA22907@internal.apple.com> >Tapping Netcom's net connections would take more than $20 of effort. >Up it to $50,000 and I'll happily take on your offer. However, I am >going to need assurances that the money will actually be paid. Oh, very, _very_ impressive. Hey, Xenon, _I'll_ do it for only $47,500, but I'll need 50% up front. "Oh, I don't mind a parasite; it's a _cut-rate_ one I object to..." -- Lefty (lefty at apple.com) C:.M:.C:., D:.O:.D:. From kshep at netcom.com Wed Feb 2 16:15:32 1994 From: kshep at netcom.com (Kirk Sheppard) Date: Wed, 2 Feb 94 16:15:32 PST Subject: List Scum and Other Dross (was: system logging) In-Reply-To: <199402022017.MAA20262@mail.netcom.com> Message-ID: On Wed, 2 Feb 1994 nobody at qwerty.org wrote: > PGP Slave, > > Could you please announce my full name, phone number, address, visa card > number, a giff of my signature, height, weight and driver's licence number > not only to the Cypherpunks mailing list but to many usenet groups as well, > since you obviously feel I no longer wish to be known to the masses as > Xenon, and I instead want them to start calling me and postal mailing me > asking for copies of PGP. Thanks asshole. I thought the people on this > list were concerned with privacy, but I was wrong. I mention Xenon in > my personal .plan, but I ask people to let me keep the small amount of > extra privacy I still retain. My sympathies to you. Others, too, on this list have no respect for privacy, as they post private e-mail to the list with out permission, but make threats in private unposted e-mail. This especially applies to those who violate privacy and make threats under pseudonyms at places and servers that don't support finger or netfind. It is ironic, but sadly this is what the "notorious" Detweiler was teaching us. Kirk Sheppard kshep at netcom.com P. O. Box 30911 "It is Better to Die on Your Feet Than to Bethesda, MD 20824-0911 Live On Your Knees." U.S.A. - Emiliano Zapata From bgold at tlcnet.aps.muohio.edu Wed Feb 2 16:21:02 1994 From: bgold at tlcnet.aps.muohio.edu (Bruce Goldflies) Date: Wed, 2 Feb 94 16:21:02 PST Subject: unsubscribe Message-ID: <9402030020.AA00850@tlcnet.aps.muohio.edu> please unsubscribe me from the list Thanks From pmetzger at lehman.com Wed Feb 2 16:21:14 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Wed, 2 Feb 94 16:21:14 PST Subject: New remailer up. In-Reply-To: <199402022358.PAA02516@mail.netcom.com> Message-ID: <199402030019.TAA06390@snark> qwerty-remailer at netcom.com says: > Perry Metzger wrote, > "Tapping Netcom's net connections would take more than $20 of effort. > Up it to $50,000 and I'll happily take on your offer. However, I am > going to need assurances that the money will actually be paid." > > This is exactly the point I was trying to make. I wanted the > word "trivial" to be clarified by those who were being so vocal > about dismissing a remailer on Netcom. Well, the problem is that NETCOM has logs that are good enough that THEY can trivally trace things if they want. Assuming they are doing normal SMTP logging tracking you down should be easy. I would require a network tap assuming that I wasn't going to have their help. However, make no mistake that Netcom can and will cooperate with the police if you use your remailer in a way that the government doesn't like, so it seems that the security afforded isn't that good. > But I'm sure some skilled hacker will be able to tell me the site and > I'll happily be out $20, in say, a couple days? Without any information out of the network logs or the network itself, no one is going to be able to say. Besides, $20 is a paltry sum for the amount of work involved. > No use hacking my password, as I keep no logs (for now). Netcom keeps logs. .pm From loki at nately.UCSD.EDU Wed Feb 2 16:41:03 1994 From: loki at nately.UCSD.EDU (Lance Cottrell) Date: Wed, 2 Feb 94 16:41:03 PST Subject: SASE Suggestion Message-ID: <9402030041.AA12425@nately.UCSD.EDU> :Lance Cottrell writes: : :> I have been meditating on this problem of return :> addresses, and have a proposal. The remailers :> can not be allowed to choose the return path, :> as any corrupted remailer will corrupt the rest :> of the path. : Jim Miller writes: :As I understand it, the remailers don't "chose" the return path, Bob (the :sender of the original message) choses the return path when he creates the :SASE. All the remailers do is interpret the part of the SASE that becomes :readable to them after decrypting the SASE portion sent to them from the :previous hop. If all is working, what becomes readable is the address of :the next hop (closer to Bob) and some misc other stuff (postage, maybe, :and perhaps another encryption key). : :Am I not understanding something correctly? : :Jim_Miller at suite.com : One SASE scheme recently suggested involved sending a request for a SASE to a ramailer, stating the number of jumps required. It then sent it to another remailer, and so on. Each adding a layer, and eventually sending the results to the desired correspondent. I mentioned that if the first remailer was corrupted, that the whole chain was (it would only send to other corrupt remailers). ---------------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki at nately.ucsd.edu PGP 2.3 key available by finger or server. "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche ---------------------------------------------------------- From qwerty-remailer at netcom.com Wed Feb 2 17:21:03 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Wed, 2 Feb 94 17:21:03 PST Subject: New remailer up. Message-ID: <199402030119.RAA17214@mail.netcom.com> Perry wrote, "However, make no mistake that Netcom can and will cooperate with the police if you use your remailer in a way that the government doesn't like, so it seems that the security afforded isn't that good." So you aren't interested unless you can commit serious felony crimes using a given remailer? I would be happy if criminals stayed away from my remailer. What do you mean by "security"? And if the police find out a personally owned machine was involved, I couldn't imagine them not just swooping in at midnight and taking it away at gunpoint. I hope those privately owned machines don't have logs ;-). In my mind, the whole secret to gaining privacy is not attracting attention in the first place. Using a remailer DOES allow a person to communicate anonymously with someone else, in two directions. If a party has enough power to tap Netcom, then sendmail logs or no sendmail logs, they will find you. and, "Besides, $20 is a paltry sum for the amount of work involved." Think of it as a trophy, which I'm sure most understood. I'm not offering you a job. I appreciate your view though, and since I've posted a request for remailer comments, might you help us all and send me some comments about the various remailers and what types of security each affords? If some wish to use remailers for serious underground activity, which should they use or not use? If they just want to keep bounced mail from telling their system postmaster who they're talking to, then that's a different type of security need. -Xenon From wisej at acf4.NYU.EDU Wed Feb 2 17:21:14 1994 From: wisej at acf4.NYU.EDU (wisej) Date: Wed, 2 Feb 94 17:21:14 PST Subject: fwd: Canadian gov't eavesdropping In-Reply-To: <9402021727.AA04813@netmail2.microsoft.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- On Wed, 2 Feb 1994, Mike Markley wrote: > | From: Eli Brandt > | > HIGH-TECH SNOOP GADGET. A super-secret branch of the Canadian Security > | > Intelligence Service has awarded three contracts to a Montreal firm to mak e > | > equipment that can quickly isolate key words and phrases from millions of > | > airborne phone, fax, radio signals and other transmissions. The hardware > | > has the "Orwellian potential to sweep through ... and keep records of all > | > conversations," said one CSIS critic. (CTV National News, 01/31/94 11:00 > | > pm). > | > | Dunno how feasible this kind of keyword recognition presently is, > | but here's another reason to encrypt. > > I'd be curious to see how they are going to do voice recognition on > random conversations. Unless I am very sadly out of date you need to > teach the pattern matcher individual voices. > You'd be surprised. For example, Plaintalk, a system extension bundled with the AV-series macintoshes, does voice recognition based solely on phonemes. Although it is not perfect yet, I can personally attest to having walked up to a model on display in a store, tried a few simple commands by voice, and had no problem with recognition. The technology _is_ there. Jim Wise wisej at acf4.nyu.edu jaw7254 at acfcluster.nyu.edu -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLVBRwzS8O1DgkhNpAQEQcgP/cQZm7qvbwTzRrHFVO7NeGtTKCoguSqng kH/6Mj2HOkndDydTpeZh5Zcb9JeuZHERagcD6ese71Yjihry/KTh6fNzDnYJhb/N 5vOlZZAa/8LgnLaF3IZWJJmrHqhTGlitD9AFMrFGrt420ij4GzTWsLN93Ctm7MBg sWZvuj9JL7o= =U/4B -----END PGP SIGNATURE----- From qwerty-remailer at netcom.com Wed Feb 2 17:31:14 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Wed, 2 Feb 94 17:31:14 PST Subject: New remailer up. Message-ID: <199402030131.RAA20660@mail.netcom.com> Sure, a vanilla user at netcom probably can't track the remailer logs, unless of course there are BUGS in SENDMAIL (gasp!) or SunOS or whatever. But remailers aren't just to keep random users from knowing who you are so you can post better anonymous letters to alt.sex.anonymous. At least some of us would like real privacy, and consider remailers a useful part of this, and this means that if you're using remailers to communicate with your sources for the newspaper article you're writing on the CIA's cocaine delivery shortfalls or the NSA/Trilateralist designs for the National Health Care ID Card or your mayor's child pornography habits, that nobody can track you or your sources down easily. That means that root at netcom.com can't do it using the root password, even if they want to comply with the subpoena, and the Secret Service can't do it after confiscating netcom's machines or wiretapping their phones. Non-encrypting remailers can never really get that good, but they can at least d part of the job, and encrypting remailer networks may get that good if there's enough traffic through the system. So meanwhile, are you giving root at netcom.com permission to try to identify the source of your mail and win the $20 for finding out whether you're really Xenon or you're really L.D.'s evil twin Skippy? (No idea if they'll try, or if they're even listening....) - Radon From frissell at panix.com Wed Feb 2 17:55:34 1994 From: frissell at panix.com (Duncan Frissell) Date: Wed, 2 Feb 94 17:55:34 PST Subject: Josh Quittner`s Newsday c Message-ID: <199402030153.AA21905@panix.com> Welcome to new lurkers (if any) from our recent NYT and Newsday publicity. To give you something a little more interesting than "Is Usenet in the Public Domain?" to read, here is my response to Joshua Quittner's column in Newsday. >Tuesday, 01 February 1994 > >CODING UP A BIT OF PRIVACY > >Time is running out for the Cypherpunks. Actually we have all the time in the world. One cannot build a New Information Infrastructure without including the tools that anyone can use to communicate privately. >This is their central question: In a future world where all information >is centralized on a network, where all information is tracked by the bit, >where every purchase you make and every communication can be monitored by >corporate America, how does privacy survive? More of a problem in the past than in the future. When P.J. O'Rourke had lived in a small New Hampshire town for a year or so and went to the store to shop for some clothes the clerk remarked, "That's not the brand of underwear you usually buy." One's life was more of an open book in the village and the tribe than it will be in the electronic village. Particularly since you can build private networks/"places" that exclude anyone you want. >"The whole information highway thing is now part of the public eye," >explain Eric Hughes, a founder of the Cypherpunk movement. "If we don't >change it now, it'll be impossible later." Misquote? It's usually better to do the job early than late but the nature of network communications is such that it's hard to control at any time. >They dread the coming commercial network of televisions and computers, >saying it will displace the Internet and destroy many of the freedoms they >now enjoy. Surely not the anarcho capitalists who probably represent a majority of active cypherpunks. >For the first time, virtually unbreakable codes are now possible, thanks to >computers. I won't say it. Certainly computers make it easier to *use* encryption. >The the U.S. government is concerned, as governments always are, about >the spread of powerful cryptography (terrorists could use it, kidnappers >could use it, drug dealers could use it, Communications intercepts are rarely used to prosecute crimes. >The (Clipper) chip is reviled by Cypherpunks and other civil libertarians >because it provides a back door that law-enforcement agencies could enter, >with the proper warrants, for surveillance. Warrants not required, just a certification that the law enforcement agency has proper authority to do a communications intercept. >"I'm starting a bank, and it's not going to be a U.S. bank," Hughes >says. >The bank will store depositors' money (he's thinking a $200 minimum >deposit) and disburse payments to anyone --- all over the Internet. It >will be based abroad, maybe in Mexico. Where did Mexico come from? >A Cypherpunk network bank is one way to pay for a network of truly >encrypted, private communications, you see. Along with lots of other nice things. Computers have been killing traditional banks for years (ever since they enabled the creation of Money Market Funds in the '70s). Netbank (and its many competitors) will continue the process. *********** Duncan Frissell You don't have to be nice to nation states you meet on the way up if you're not coming back down. --- WinQwk 2.0b#1165 From mediak at well.sf.ca.us Wed Feb 2 18:11:03 1994 From: mediak at well.sf.ca.us (Joseph Matheny) Date: Wed, 2 Feb 94 18:11:03 PST Subject: UNSUBSCRIBE Message-ID: <199402030210.SAA22612@well.sf.ca.us> Unsubscribe:mediak at well.sf.ca.us From qwerty-remailer at netcom.com Wed Feb 2 18:11:14 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Wed, 2 Feb 94 18:11:14 PST Subject: New remailer up. Message-ID: <199402030211.SAA00952@mail.netcom.com> "So meanwhile, are you giving root at netcom.com permission to try to identify the source of your mail and win the $20 for finding out whether you're really Xenon or you're really L.D.'s evil twin Skippy?" I have no answer to that. I don't know what "permission" means in this context. I never discluded Netcom employees though. I doubt they would wish to appear to have lax security by posting the answer though. Does L.D. have an evil twin? I hope he doesn't get a Unix account. Seriously, your comments were the first I've seen that really explain to me what sort of security problem a Netcom remailer faces. Now then, I ask you as well, might you fill in a few of the blanks in the remailer list I posted. I could send it to you if you missed it. What are the "serious" remailers, do they keep mail logs, and are they reliable? -Xenon From qwerty-remailer at netcom.com Wed Feb 2 18:16:14 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Wed, 2 Feb 94 18:16:14 PST Subject: anonymous mail bombers and what to do about them Message-ID: <199402030216.SAA01922@mail.netcom.com> Don't feed the animals. Generally, when one person is mail-bombing another, either there has been a fair amount of provocation by at least one of the parties, and escalation of childishness isn't as useful as trying to resolve some of your differences, though it can offer a certain amount of basic 4-year-old ego satisfaction. If somebody's mail-bombing you, and they're root, and they're not doing it anonymously, you don't need to either; the worst revealing your identity will do at that point is encourage them to mail-bomb you. And your system administrator probably already knows who you are by now, assuming the bombing has been at a high rate. If the bomber is root on his home machine, and the bombs include bad words that aren't mere reflections of your words to him, you could always complain to the phone company that you're receiving obscene phone calls. I doubt the policies or laws about that specify whether the calls have to be made in spoken English.... If the bomber is root on his business machine, you can complain to his management, assuming you can locate them. Some managers get very bent out of shape about this and do random clueless things, others conservatively protect their company images, others ask what state and federal laws have been broken and tell you to stifle yourself if the answer is "none". If the bomber is root on his home PC at a university, arbitrary randomness can occur. On the other hand, if you're really L- D-, and the person who is mailbombing you is Perry Metzger, expending large amounts of childishness in his direction will not accomplish anything positive for either of you, and if both of you start sending N copies of each others' mail to each other, exponential growth will not help either of your systems. If you're not really L- D-, but the person who is mailbombing you is still Perry, try talking rationally to him; he can do that just fine if he thinks it's worthwhile. If you're really L- D-, and the person is or is not Perry, we can help. Post your full name, home address with precise latitude and longitude, and we'll be happy to deliver some advanced plutonium products you may find useful in resolving your problems. "Deuterium" (oh - wait - maybe I'm "Tritium" today?) (or was that "Lithium"?) From CHRISTI1 at MUVMS6.WVNET.EDU Wed Feb 2 18:21:03 1994 From: CHRISTI1 at MUVMS6.WVNET.EDU (IGOR) Date: Wed, 2 Feb 94 18:21:03 PST Subject: anonymous mail Message-ID: <01H8FA8ERMXS001OXX@MUVMS6.WVNET.EDU> If there is an admin above him, speak with that admin, also mail cert at cert.org and mail the nsf explaining to them what has been happening, or mail kfithen at cert.org She is a really nice lady, and she could help you on this. If all else fails, do that and send the fakemail...if you are sure that you wont get caught. Bob \//// (0 0) *------------------------------oOO--(_)--OOo---------------------------------* | Bob Christian II "IGOR" * Internet:Christi1 at muvms6.mu.wvnet.edu| | Marshall University ***** E-Mail: Christi1 at muvms6.wvnet.edu | | Huntington, WV * GET HIGH....LEARN TO FLY! IP-ASEL | | Student/D.J 88.1 WMUL FM * Major:Undecided(CJ/LAW) Minor:AVT | *----------------------------------------------------------------------------* --I love flying because there is no speed limit(^10k) and Radar is your friend! --Marshall assumes no libility for what I say, because my words are MINE! From wcs at anchor.ho.att.com Wed Feb 2 18:35:34 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Wed, 2 Feb 94 18:35:34 PST Subject: Qwerty Remailer Delays Message-ID: <9402030231.AA03865@anchor.ho.att.com> It's not very clear how long the delays should be; depends on traffic to/from your remailer and to some extent to/from the other sites your remailer cooperates with and the machine it runs on. If the delay is near-zero, relative to the rest of your traffic, traffic-analysts can see mail going to your remailer, followed quickly by similar-sized mail going to another location, and guess that the two are related, especially if they're reading the mail itself. (For instance, if netcom is a bunch of machines on an Ethernet, and somebody breaks root on one of them, packet-sniffing the net may catch a non-trivial amount of your mail going in at least one direction. It's certainly easier than tapping all the phones if you don't have a warrant.) How much you need also depends on your threat model - do you expect monitoring by netcom users only, active monitoring by root, logfile examination without ongoing monitoring, etc....? If there are a bunch of other messages in between, especially if you're sending most of them to the same destination (e.g. instead of always choosing a random remailer to send through, you pick one remailer and send a batch of N messages to it; and maybe use a different remailer for the next batch) then it's harder to correlate incoming and outgoing messages. One strategy for batching is to accumulate N messages and send them at once, rather than delaying for N minutes. This may cause rather long delays, unless you either get lots of traffic or else give up and send the real message and some fake ones after rand{5..N} minutes. (If you use fixed N, it's easy to track when traffic is low.) Bill From wcs at anchor.ho.att.com Wed Feb 2 18:41:04 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Wed, 2 Feb 94 18:41:04 PST Subject: digital signatures/copyright Message-ID: <9402030239.AA03921@anchor.ho.att.com> -----BEGIN PGP SIGNED MESSAGE----- Brian Williams asks: > Could one make a case that the use of Digital signatures in > messages imply's copyright retention by the author? No - you can make a case that the author doesn't want his words to be forged or tampered with, and is using technology rather than law to enforce it. Doesn't affect the rest of the legal situation, though one could try to argue either that the author was or was not expecting copyright. -----BEGIN PGP SIGNATURE----- Version: 2.3z iQCVAgUBLU/2HdCcBnAsu2t1AQF15gP+IqS3o0gNeHng9BSqlk95KzmPwp3oo70p j2FVYHNOeUKgDSAAwvWr+p3/DOwTafSkJf4A5gW33NOKr0E9JZ4In349RAoueTku J94VMajT4i7yhOC8X41RPkVLlCltPDRo04SS8h5UFnEk/zFxiTkvXY9mpBcK3yUw vYY9pbmupSc= =KbXS -----END PGP SIGNATURE----- Bill From pgpkeys at wasabi.io.com Wed Feb 2 18:51:03 1994 From: pgpkeys at wasabi.io.com (PGP Slave Key Server) Date: Wed, 2 Feb 94 18:51:03 PST Subject: New server up. Message-ID: <199402022116.VAA20077@wasabi.io.com> PGP Slave, I hear and obey O Master. Could you please announce my full name, phone number, address, visa card number, a giff of my signature, height, weight and driver's licence number not only to the Cypherpunks mailing list but to many usenet groups as well, If you insist :-) (Can you give me a few more days to comply?...I`m having some trouble getting a copy of your signature. One of the guys in the chem faculty says he knows where he can get one at the weekend...) since you obviously feel I no longer wish to be known to the masses as Xenon, and I instead want them to start calling me and postal mailing me asking for copies of PGP. Thanks asshole. I thought the people on this list were concerned with privacy, but I was wrong. I mention Xenon in my personal .plan, but I ask people to let me keep the small amount of extra privacy I still retain. Hey bud, you`ve clearly misunderstood the whole point of the movement. You get whatever privacy you can make for yourself through technology. Any dolt who goes to the extent of using two remailers and a penet id to hide his identity then puts his nym`s secret key in his True Name signature file gets the privacy he deserves. Anyway, whats the big deal?...noone who read my post will have a clue who you are unless you tell them yourself; and anyone who could track you down from the two bits of info in that post is more than capable of tracking you down the same way I did from the public logs on netcom. I was just waving enough of a red rag at you to make the point forcefully... (remember your the one arguing against putting delays more than 15 minutes in a remailer system...) The point I was making was that you cannot rely on trust such as a lack of logs alone to keep things like remailer chains secure...you *have* to build the security into the technology and the protocols. You must assume that The Bad Guys (tm) have full access to all the logs of all the machines that run remailers...if not directly then by watching the wires. So any remailer scheme has to include dummy traffic, significant delays, and encrypted input way back at the sender`s end. And the protocol has to be such that a remailer chain is as strong as its strongest link, not as weak as its weakest link, meaning if 9 out of 10 remailers have been compromised but the 10`th is run by Honest Joe, then Honest Joe`s trustworthiness is sufficient to defeat the evil forces of TBG with there 9 bogus servers. You wrote, "qwerty account or not, the public logs on netcom show more than enough info to trivially track people down." Trivial? And so you hack out the info that a message went from remailer A through qwerty and on to remailer B, at a certain time. You haven't tracked down anyone my friend. Yo dude, I found *you* didn`t I? And it took me less than 5 minutes. So bite me. PS How to build your own mailer logs on netcom...just stay on long enough and keep typing `mailq`...no problemo...I can`t be bothered but if I could thats how I`d track traffic through qwerty for your $20... From qwerty-remailer at netcom.com Wed Feb 2 19:11:03 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Wed, 2 Feb 94 19:11:03 PST Subject: New remailer up Message-ID: <199402030311.TAA14987@mail.netcom.com> I haven't really kept track of which remailers are how reliable; they're almost all relatively new and experimental, people are hacking software, they go up and down a lot, and I almost never use them anyway. I also don't like keeping track of the syntax and which ::'s are followed by which ##s :-) Julf's anon.penet.fi remailer is serious; he's done a lot of work to get a private machine, payng for a reasonably expensive 64kbps line himself, and has it located somewhere that only 3 people know. (The original was located at a university, and somebody decided they wanted it Closed.) It's also outside the US, which is useful, . On the other hand, it works differently than the one-way anonymous remailers, uses up a substantial fraction of the net.bandwidth into FInland, and costs him real bucks - somebody ought to start a US equivalent and deload him. I'd guess tht extropia is also probably well-run, or at least has good features. But I haven't used it. From kevin at axon.cs.byu.edu Wed Feb 2 19:35:34 1994 From: kevin at axon.cs.byu.edu (Kevin Vanhorn) Date: Wed, 2 Feb 94 19:35:34 PST Subject: New remailer up. In-Reply-To: <199402030119.RAA17214@mail.netcom.com> Message-ID: <9402030335.AA16272@axon.cs.byu.edu> >> However, make no mistake that Netcom can and will cooperate with the >> police if you use your remailer in a way that the government doesn't >> like, so it seems that the security afforded isn't that good." > > So you aren't interested unless you can commit serious felony crimes > using a given remailer? I would be happy if criminals stayed away from Things "that the government doesn't like" and "serious felony crimes" are not the same. People in positions of governmental power have all too often in the past used that power to harrass others who have committed no crime. Remember how Nixon used to sic the IRS on his political enemies? And the ATF has a sordid history of harrassing harmless people, including trying to trick them into committing technical violations of obscure gun-control regulations. Often enough, government officials harrass people who have broken no law, but have only behaved in a way that those officials WANT to be made illegal. ----------------------------------------------------------------------------- Kevin S. Van Horn | It is the means that determine the ends. kevin at bert.cs.byu.edu | From remailer at merde.dis.org Wed Feb 2 20:01:04 1994 From: remailer at merde.dis.org (remailer bogus account) Date: Wed, 2 Feb 94 20:01:04 PST Subject: PGPTools Minor Bug Message-ID: <9402030359.AA28381@merde.dis.org> -----BEGIN PGP SIGNED MESSAGE----- There is a minor bug in PGPTOOLS.C which needs to be fixed. In pgp_extract_rsa, two lines need to be added. This variable was not being cleared. When the precision was later set to max, there was garbage left in the high-order bytes of the mpi. This caused the size of the MPI to be wrong, and the function would not decrypt 2.2 or earlier packets. It could also occasionally fail to decrypt a 2.3 packet. Sorry about that. Pr0duct Cypher /* Decrypts and extracts the key from an RSA-encrypted block */ /* Returns true if successful, false if not */ int pgp_extract_rsa(struct fifo *f,byte ideakey[16], struct pgp_pubkey *pk,struct pgp_seckey *sk) { struct mpi *p=safemalloc(sizeof(struct mpi)); struct mpi *c=safemalloc(sizeof(struct mpi)); unit *dp=safemalloc(sizeof(unitarr)); unit *dq=safemalloc(sizeof(unitarr)); unit *temp=safemalloc(sizeof(unitarr)); byte result; word16 checksum=0; byte *pp; byte type; word32 length; set_precision(MAX_UNIT_PRECISION); <--------- ADD mp_burn(p->value); <--------- ADD set_precision(bits2units(pk->n.bits+SLOP_BITS)); pgp_examine_packet(f,&type,&length); -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLU4ptsGoFIWXVYodAQG3GQQApg45mfrbfoUP4BhrtmvE+zRGdSp6zx9+ M7GDnJ+vpCVzQj6S7Z+y1RZ4FFAT6yX/63oeVvhW8FzNZ1s5xOZivbIZrhC6WPJU qZiuy/veXD7OrWpUJueucT5xPF/Nsjdx3w2DiAy2x7YtRycpzugMSpSdvJcCcOuK rGBkPV2eJDc= =+WVh -----END PGP SIGNATURE----- From fnerd at smds.com Wed Feb 2 20:15:34 1994 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Wed, 2 Feb 94 20:15:34 PST Subject: fwd: Canadian gov't eavesdropping Message-ID: <9402030355.AA05275@smds.com> Mike Markley says- > I'd be curious to see how they are going to do voice recognition on > random conversations. Unless I am very sadly out of date you need to > teach the pattern matcher individual voices. I remember a story from a conference in the sixties where someone wanted to prove the point that it's much easier to make a recognizer for all voices if you're only looking for a certain word. So he built a "watermelon" box. He sits this up on the podium with him and gives his talk, which naturally at some point gets to... "...a single word, for instance 'watermelon.'" *beep!* Then later there's a Q&A period, of course... A: Please step up to the microphone... Q: You mean all this thing does is recognize the word "watermelon," *beep!* and that it can recognize the word "watermelon" *beep!* no matter who says it? A: That's right, it's an any-speaker, "watermelon" *beep!* recognizer. Q2: Why the word... "watermelon" *beep!* exactly? ... -fnerd *BZZZT! AAAAARRRRROOOOGAH!* quote me - - cryptocosmology- sufficiently advanced communication is indistinguishable from noise - god is in the least significant bits -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE----- From matthew at gandalf.rutgers.edu Wed Feb 2 20:31:04 1994 From: matthew at gandalf.rutgers.edu (Matthew Bernardini) Date: Wed, 2 Feb 94 20:31:04 PST Subject: Archiving mail-lists... Message-ID: What do you call 1,000 copyright lawyers chained to the bottom of the ocean ? 1)A good start. 2)A drop in the bucket. 3)A boring Swim Party. I can't take five hundred messages in a week from people calling each other names and including 500 lines of previous posts !!!! Give my mailbox a rest, eh ? From remailer-admin at chaos.bsu.edu Wed Feb 2 20:41:04 1994 From: remailer-admin at chaos.bsu.edu (Anonymous) Date: Wed, 2 Feb 94 20:41:04 PST Subject: No Subject Message-ID: <199402030530.XAA11324@chaos.bsu.edu> Perry almost wrote: > Anyway, people who want to use the law to restrict distribution of > their software are extremely foolish. Your code is out there > it WILL be copied. Forever. You can't help it. If you don't want > people to use your software, don't write it. From newsham at uhunix.uhcc.Hawaii.Edu Wed Feb 2 21:26:04 1994 From: newsham at uhunix.uhcc.Hawaii.Edu (Tim Newsham) Date: Wed, 2 Feb 94 21:26:04 PST Subject: LPC on ADSP2105 Message-ID: <9402030525.AA18455@uhunix.uhcc.Hawaii.Edu> I have recently finished my senior project on low-bandwidth coding of speech. I outline an implementation of Linear Predictive Coding (LPC) on the ADSP2105. I am making the paper and the source code freely available in hopes that it may interest and possibly help someone. In order to avoid having to mail out copies seperately to everyone who is interested I am putting the paper temporarily on: ftp.uu.net:/tmp/lpc-paper.tar.gz If you know of an archive for which this paper is suitable please let me know how to submit it there or submit it yourself and let me know. The archive is a tar'ed collection of files, to unpack: gzip -d lpc-paper.tar.gz tar xvfp lpc-paper.tar The contents of the archive are: Makefile README a4.sty lpc.ps lpc.tex lpc4b.asm notes.tex schematic schematic.ps source.tex and contain postscript and LaTeX formats of the document. Here is the abstract: \begin{abstract} An implemenation of Linear Predictive Coding, a low-bandwidth speech encoding scheme, built around the ADSP-2105 signal processing CPU is described. The hardware schematics and software source code listing are included. \end{abstract} Tim N. (ps. I am no longer subscribed to the cypherpunks list so if you wish to reply, send the reply directly to me) From catalyst-remailer at netcom.com Wed Feb 2 22:25:35 1994 From: catalyst-remailer at netcom.com (catalyst-remailer at netcom.com) Date: Wed, 2 Feb 94 22:25:35 PST Subject: New remailer up. Message-ID: <199402030624.WAA23896@mail.netcom.com> -----BEGIN PGP SIGNED MESSAGE----- ndw1: mail qwerty at netcom.com Subject: Re: new server up. :: Request-Remailing-To: cypherpunks at toad.com (Skip to end for actual remailer discussion.) PGP Slave, "If you insist :-) (Can you give me a few more days to comply?...I'm having some trouble getting a copy of your signature. One of the guys in the chem faculty says he knows where he can get one at the weekend...)" Thanks again. Now everyone knows to never tell YOU any secrets, no matter how trivial they might be, since you will post them. Who's the 'punk? and, "Hey bud, you`ve clearly misunderstood the whole point of the movement. You get whatever privacy you can make for yourself through technology. Any dolt who goes to the extent of using two remailers and a penet id to hide his identity then puts his nym`s secret key in his True Name signature file gets the privacy he deserves." I'm not sure you understand what -----BEGIN PUBLIC KEY BLOCK----- means. Or were you fingering someone else? Am I missing something? I am using two remailers to help out with the lack of traffic, not to hide my identity. There are many levels of privacy, and the one I am concerned with does not involve anything other than that Usenetters who are NEWBIES being forced to contact me via e-mail. It also involves not having the people I work around who are not my close friends gossiping about, mindlessly, about "what I am trying to hide" with my use of PGP. This is a personal thing, and using a nickname on Usenet is as strong of security as I need to meet this need. When I joined this list and started using Cypherpunk remailers I decided to not maintain my anonymity in a vigorous manner. I think you are trying to show off what a super hacker you are by typing "last qwerty", or even just "finger qwerty" from outside, to see my local site that I telnet in from, then typing the master-hacker magic-line "rusers my.site". I am impressed that you too can type these commands, and you get the Xenon Hacker God Award for the entire year of 1994. However, I would rather talk about remailer security levels than trying to cope with someone embarrassing themselves posting their "discovery" of my "real identity". I am not "hiding my identity", I am maintaining a minimal amount of PERSONAL privacy, at a security level that fits my needs; I am using a NICKNAME. For this purpose, qwerty and catalyst serve me well. I'm not sure why you have so much fun disrespecting a person's privacy. I arrived here with a simple question, "Can I use your remailers for bulk mailing of 1-3MB a day to people wanting the PGP FAQ and MacPGP Guide? What are the qualities of each remailer?" I think I understand the movement quite well, but I understand there IS NO fully secure remailer network which I would bet my life on. And I understand and am acting upon what few seem to care about, which is getting a large number of people outside of the internet-skilled culture using secure encryption. There are 50-100 million Mac and Windows users, and the majority of those with a modem use their internet connection for simple e-mail ONLY. Many only HAVE e-mail in fact. PGP has mass media attention, but very few are using it since they can't get it by a 1-800 number. I hope ViaCrypt will change this, with Mac and Windows versions. -----BEGIN REMAILER DISCUSSION BLOCK----- and, "logs on netcom. I was just waving enough of a red rag at you to make the point forcefully... (remember your the one arguing against putting delays more than 15 minutes in a remailer system...)" Finally we are talking about remailers! Thank-you. My telnet log is public. Netcom's sendmail logs are not (?). There IS a difference. I was arguing against long delays, which should only be needed if no baseline traffic is going on. Many people will not be able to function well if say, mail is batched out at midnight. Rapid two-way communication is very important these days in getting ANYTHING done, be it above ground OR underground. and, "PS How to build your own mailer logs on netcom...just stay on long enough and keep typing `mailq`...no problemo...I can`t be bothered but if I could thats how I`d track traffic through qwerty for your $20..." Now you really do get an award, but not the $20 since that will go to the person who WAS downloading mailq logs from Netcom ;-). You seem to be absolutely right. Here is an outgoing piece of mail sent from qwerty: qwerty: mail alt.test at news.cs.indiana.edu Subject: Ignore ignore test. This is a test of 'mailq'. From catalyst-remailer at netcom.com Wed Feb 2 22:35:35 1994 From: catalyst-remailer at netcom.com (catalyst-remailer at netcom.com) Date: Wed, 2 Feb 94 22:35:35 PST Subject: New remailer up. Message-ID: <199402030633.WAA01347@mail.netcom.com> -----BEGIN PGP SIGNED MESSAGE----- (Skip to end for actual remailer discussion.) PGP Slave, "If you insist :-) (Can you give me a few more days to comply?...I'm having some trouble getting a copy of your signature. One of the guys in the chem faculty says he knows where he can get one at the weekend...)" Thanks again. Now everyone knows to never tell YOU any secrets, no matter how trivial they might be, since you will post them. Who's the 'punk? and, "Hey bud, you`ve clearly misunderstood the whole point of the movement. You get whatever privacy you can make for yourself through technology. Any dolt who goes to the extent of using two remailers and a penet id to hide his identity then puts his nym`s secret key in his True Name signature file gets the privacy he deserves." I'm not sure you understand what -----BEGIN PUBLIC KEY BLOCK----- means. Or were you fingering someone else? Am I missing something? I am using two remailers to help out with the lack of traffic, not to hide my identity. There are many levels of privacy, and the one I am concerned with does not involve anything other than that Usenetters who are NEWBIES being forced to contact me via e-mail. It also involves not having the people I work around who are not my close friends gossiping about, mindlessly, about "what I am trying to hide" with my use of PGP. This is a personal thing, and using a nickname on Usenet is as strong of security as I need to meet this need. When I joined this list and started using Cypherpunk remailers I decided to not maintain my anonymity in a vigorous manner. I think you are trying to show off what a super hacker you are by typing "last qwerty", or even just "finger qwerty" from outside, to see my local site that I telnet in from, then typing the master-hacker magic-line "rusers my.site". I am impressed that you too can type these commands, and you get the Xenon Hacker God Award for the entire year of 1994. However, I would rather talk about remailer security levels than trying to cope with someone embarrassing themselves posting their "discovery" of my "real identity". I am not "hiding my identity", I am maintaining a minimal amount of PERSONAL privacy, at a security level that fits my needs; I am using a NICKNAME. For this purpose, qwerty and catalyst serve me well. I'm not sure why you have so much fun disrespecting a person's privacy. I arrived here with a simple question, "Can I use your remailers for bulk mailing of 1-3MB a day to people wanting the PGP FAQ and MacPGP Guide? What are the qualities of each remailer?" I think I understand the movement quite well, but I understand there IS NO fully secure remailer network which I would bet my life on. And I understand and am acting upon what few seem to care about, which is getting a large number of people outside of the internet-skilled culture using secure encryption. There are 50-100 million Mac and Windows users, and the majority of those with a modem use their internet connection for simple e-mail ONLY. Many only HAVE e-mail in fact. PGP has mass media attention, but very few are using it since they can't get it by a 1-800 number. I hope ViaCrypt will change this, with Mac and Windows versions. -----BEGIN REMAILER DISCUSSION BLOCK----- and, "logs on netcom. I was just waving enough of a red rag at you to make the point forcefully... (remember your the one arguing against putting delays more than 15 minutes in a remailer system...)" Finally we are talking about remailers! Thank-you. My telnet log is public. Netcom's sendmail logs are not (?). There IS a difference. I was arguing against long delays, which should only be needed if no baseline traffic is going on. Many people will not be able to function well if say, mail is batched out at midnight. Rapid two-way communication is very important these days in getting ANYTHING done, be it above ground OR underground. and, "PS How to build your own mailer logs on netcom...just stay on long enough and keep typing `mailq`...no problemo...I can`t be bothered but if I could thats how I`d track traffic through qwerty for your $20..." Now you really do get an award, but not the $20 since that will go to the person who WAS downloading mailq logs from Netcom ;-). You seem to be absolutely right. Here is an outgoing piece of mail sent from qwerty: qwerty: mail alt.test at news.cs.indiana.edu Subject: Ignore ignore test. This is a test of 'mailq'. qwerty: mailq Mail Queue (58 requests) --Q-ID-- --Size-- -----Q-Time----- ------------Sender/Recipient------------ (much deleted....) UAA29300* 27 Wed Feb 2 20:13 qwerty alt.test at news.cs.indiana.edu And some incoming, as bounced off of hh at cicada.berkeley.edu: UAA29978* 6 Wed Feb 2 20:20 "|/u1/qwerty/remail/slocal.pl" slocal.pl is part of Hal's remailer scripts. So who has a remailer to send me that will avoid this? Looks like I'd not use qwerty or catalyst as the first or last stop in a remailing chain. But if the only way to track this is AS the mail arrives or goes out, I'd still classify qwerty/catalyst as being good for casual security uses such as my post to Usenet above. It would be a lot faster than anon.penet.fi! Then again, a person could blackmail someone for posting to alt.sex.bestiality. When can I and many others switch from Netcom to a pubic service Unix network that is private/secure? *Again, I'm trying to compile a list of remailers and what levels of security each entails. Such a list does not seem to exist. If you ever want more traffic.... -----END REMAILER DISCUSSION BLOCK----- PGP Slave, despite this misunderstanding, could we declare peace and get on with a discussion about REMAILERS, instead of my nickname. I'm out here to learn and try to contribute what I can. I am sending info about secure encryption to at least a dozen people a day, many of whom would not otherwise get their hands on PGP or even the PGP FAQ, and I have thus become the most prolific user of the Cypherpunk remailers. I am doing this randomly, chained between two remailer at a time. This volume could triple if I started advertising. I don't misunderstand the movement? -Nik (Xenon) -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLVBTPASzG6zrQn1RAQH2/QP/dexRZeXe7KRZpADn+hCBUoUExelRJ6hv A6kARzcymCAa3571u1XDauIcmNTPXDQTQ4bf3D5x94eR2AM43NjPcVBWkZcUYgEk ROGkIP3fAFnpBCbn0RZPOhIfYt8NnvWY53knRd5JxJbJ6jQxjRG9SfADs2ip8Fpl v4p6WPlnFHM= =j2FI -----END PGP SIGNATURE----- From qwerty-remailer at netcom.com Wed Feb 2 23:05:35 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Wed, 2 Feb 94 23:05:35 PST Subject: New remailer up. Message-ID: <199402030705.XAA03827@mail.netcom.com> I must thank Hal Finney for pointing me to 'gopher chaos.bsu.edu'. I will be much better informed about remailers for having found this site. I'm not sure why it's taken a week for someone on this list to tell me this. -Nik (Xenon) From nobody at pmantis.berkeley.edu Wed Feb 2 23:31:05 1994 From: nobody at pmantis.berkeley.edu (nobody at pmantis.berkeley.edu) Date: Wed, 2 Feb 94 23:31:05 PST Subject: A serious question of ethics Message-ID: <9402030727.AA27027@pmantis.berkeley.edu> Ok, I'm in a bit of a quandry. While surfing the net last week, I happened across an address addached to a machine that belongs the the federal reserve. No big deal. I telnetted there on a lark, and entered 'guest' for the account. It dropped me into a shell. It didn't ask for a password. Intrigued, I did a little looking around. Nothing special, a CDRom and about 80 accounts. But(!!), /etc/passwd was there and available and not using shadows. No, I didn't snatch a copy. Quandry(ies) 1) Should I alert someone there about the obvious (and, IMHO serious) seciruty hole? or 2) Should I ignore it? 3) Should I take advantage of it (well, maybe not) ---------- I don't like to see systems so open, no matter who they belong too, and the fact that the governments (whether you like them or not) has one this open REALLY bothers me. But, I also wonder what kind of trouble I could get into. Technically, I violated something just by being there as I didn't have permission, and the fact I accessed the passwd file makes it even worse. If I report it, I could be in deep shit. I could mail to them via a remailer (like penet.fi, so that they could answer for more information if needed). That is a little securer and Julf is out of jurisdiction of the FBI hunting me down. Yes, I'm a little paranoid, but Uncle Sam likes to make examples out of white-collar hackers, and for me it was pure and dumb luck (like a jury would believe a 22 year-old computer geek isn't trying to gain illegal access). Any suggestions? Please? I consider this to be serious (most may not). From gnu Wed Feb 2 23:41:05 1994 From: gnu (John Gilmore) Date: Wed, 2 Feb 94 23:41:05 PST Subject: Commodity Jurisdiction success for Kerberos Bones! Message-ID: <9402030739.AA08429@toad.com> ( ) United States Department of State ( State Dept ) Bureau of Politico-Military Affairs ( Logo ) Office of Defense Trade Controls ( ) Washington, D.C. 20522-0602 In reply refer to Feb 1 1994 OTDC Case: CJ-012-94 YOUR LETTER DATED: January 13, 1994 REQUEST FOR COMMODITY JURISDICTION FOR: "Kerberos 900104 bones.tar.Z patchlevel 6" software program This 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 falls under the licensing jurisdiction of the Department of Commerce. Please consult that agency's Office of Technology and Policy Analysis at (202) 482-4145 to determine their requirements prior to export. Should you require further assistance on this matter, please contact Maj. Gary Oncale at (703) 875-5655. Sincerely, (signed -- but it doesn't look anything like the name below) William B. Robinson Director Office of Defense Trade Controls John Gilmore Cygnus Support 1937 Landings Drive Mt. View, CA 94043 -- end of letter from State Department -- Now, what does it mean that we got a Commodity Jurisdiction for the Kerberos Bones? It means that the State Department has formally excused itself from worrying about us exporting the Bones. If the Commerce Department lets us do it, it's fine with the State Department. Exporting the Bones will not violate the International Traffic in Arms Regulations (ITAR). (Doing so might still violate other laws -- the State Dept has expressed no opinion on that.) This is no surprise, since the Kerberos Bones were deliberately emasculated to remove anything that might cause the State Department or the NSA to get upset. The letter just confirms that that effort was a success. I will do a formal check with the Commerce Department, as suggested in the State Department letter. My current understanding is that under Commerce rules (the Export Administration Act), publicly available software can be exported to any destination. In particular, I believe this means that there's nothing to fear from putting up the Bones for ordinary FTP. (There's a serious First Amendment issue being debated, over whether export control laws can prevent you from publishing software via FTP at all -- but even the most paranoid should now figure it's not an issue for the Bones.) I encourage people and companies who are interested in export issues to submit a commodity jurisdiction request for some software that you want to export, and go through the process. In public. The State Department and NSA don't publish their guidelines for what is exportable and what isn't, so the only way we-the-public are going to find out is by asking, and then telling each other. I've set up an FTP archive of such information on ftp://ftp.cygnus.com/pub/export. It includes `cjr.kit', which is the info you need to file your own CJ Requests, and three files regarding Commerce Department licensing. `commerce.gtda.license.faq' in particular is a FAQ from the Commerce Department about when the General license for Technical Data to All destinations lets you export without any paperwork. -- John Gilmore gnu at toad.com -- gnu at cygnus.com -- gnu at eff.org Can we talk in private? Join me in the Electronic Frontier Foundation. Not if the FBI and NSA have their way. Ask membership at eff.org how. From sameer at soda.berkeley.edu Thu Feb 3 00:36:05 1994 From: sameer at soda.berkeley.edu (Sameer) Date: Thu, 3 Feb 94 00:36:05 PST Subject: J. Michael Diehl's procmail-pgp Message-ID: -----BEGIN PGP SIGNED MESSAGE----- If J. Mike Diehl is out there (mail to the address I have for him is bouncing) or someone else has that procmail-pgp .procmailrc he has written, I would appreciate it if you sent it to me. Thanks! - -Sameer -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVCoZni7eNFdXppdAQHzQwP/eXkVO/lN0794NwREP/YXfpF3xVubCYAA TN6F+fjv3zpxkp95GRDbwpIxiw/Aytz/5qXjgJfV0Gatrc8CNPj/zbzBdB0Wc7Yq kcaLJYwoBCazhUy6gC+3w1A79H8Uav8bgbWfx2coBQMhp69+OYyH88GuNf+01m+4 LTNcml4sJEc= =InuS -----END PGP SIGNATURE----- From rpmartin at acs.ucalgary.ca Thu Feb 3 00:55:34 1994 From: rpmartin at acs.ucalgary.ca (Rob P. Martin) Date: Thu, 3 Feb 94 00:55:34 PST Subject: Qwerty Remailer Delays In-Reply-To: <9402030231.AA03865@anchor.ho.att.com> Message-ID: <9402030854.AA69861@acs2.acs.ucalgary.ca> > > It's not very clear how long the delays should be; depends on traffic > to/from your remailer and to some extent to/from the other sites > your remailer cooperates with and the machine it runs on. > > If the delay is near-zero, relative to the rest of your traffic, > traffic-analysts can see mail going to your remailer, > followed quickly by similar-sized mail going to another location, > and guess that the two are related, especially if they're > reading the mail itself. (For instance, if netcom is a bunch of I have an idea I don't think has been proposed before. There has been a lot of discussion of having "background noise" by having remailers mail random messages to various bit-buckets and other remailers on a constant basis. But why not do it this way. If a remailer recieves a message of size N, it holds that message for a short (< 15min) period of time, and then it sends out X (5 < rnd X <15) messages of size N, some going to remailers as noise messages, some going to bit buckets as dummy recipients, and of course one heading on it's origional route. One problem with this is that messages would multiply, ie. 'A' sends to remailer 'B' whichs sends 10 messages out, 5 to other remailers who in turn send out 10 messages a piece, 5 of which goes to other remailers who again multiply this. And you end up with one of those annoying commercials, where, he tells 5 friends, and they tell 5 friends until the network shuts down. So Remailers must establish some code (which would be send pgp encrypted) that would give a message a max possible life span of say 5-10 generations. (even that may be too much) Well it is just my $.02 (and Canadian cents at that!) Rob "Remeber, the day after tomorrow is the second day of the rest of your life." Unknown. From wcs at anchor.ho.att.com Thu Feb 3 01:21:05 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Thu, 3 Feb 94 01:21:05 PST Subject: A serious question of ethics Message-ID: <9402030916.AA06954@anchor.ho.att.com> Well, if the Federal Reserve has a guest account with no password, maybe they're inviting guests... Ok,, mailing them through a remailer might not hurt, though it might point out to them that remailers exist, if they haven't figured it out already. Personally, if I were logged on to one of their machines, I'd start looking for the "print" command :-) Signed, Anonymous -- From tcmay at netcom.com Thu Feb 3 02:21:06 1994 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 3 Feb 94 02:21:06 PST Subject: (fwd) Notes on key escrow meeting with NSA Message-ID: <199402031018.CAA19497@mail.netcom.com> This interesting report on the Clipper/Capstone/Tessera Key Escrow system was posted by Matt Blaze to several groups. I hope most of you have seen it already, but for those who haven't, here it is. Apologies for using bandwidth to reproduce an article here, but I think the machinations over Clipper and key escrow in general are pretty germane to the Cypherpunks charter. --Tim May Newsgroups: sci.crypt,talk.politics.crypto,comp.org.eff.talk,alt.privacy.clipper From: mab at research.att.com (Matt Blaze) Subject: Notes on key escrow meeting with NSA Organization: AT&T Date: Wed, 2 Feb 1994 21:02:55 GMT Message-ID: A group from NSA and FBI met the other day with a group of us at Bell Labs to discuss the key escrow proposal. They were surprisingly forthcoming and open to discussion and debate, and were willing to at least listen to hard questions. They didn't object when asked if we could summarize what we learned to the net. Incidentally, the people at the meeting seemed to base a large part of their understanding of public opinion on Usenet postings. Postings to sci.crypt and talk.politics.crypto seem to actually have an influence on our government. A number of things came out at the meeting that we didn't previously know or that clarified previously released information. What follows is a rough summary; needless to say, nothing here should be taken as gospel, or representing the official positions of anybody. Also, nothing here should be taken as an endorsement of key escrow, clipper, or anything else by the authors; we're just reporting. These notes are based on the collective memory of Steve Bellovin, Matt Blaze, Jack Lacy, and Mike Reiter; there may be errors or misunderstandings. Please forgive the rough style. Note also the use of "~ ~" for 'approximate quotes' (a marvelous Whit Diffie-ism). NSA's stated goals and motives for all this: * DES is at the end of its useful life * Sensitive, unclassified government data needs protection * This should be made available to US Citizens * US business data abroad especially needs protection * The new technology should not preclude law enforcement access They indicated that the thinking was not that criminals would use key escrowed crypto, but that they should not field a system that criminals could easily use against them. The existence of key escrow would deter them from using crypto in the first place. The FBI representative said that they expect to catch "~only the stupid criminals~" through the escrow system. Another stated reason for key escrow is that they do not think that even government-spec crypto devices can be kept physically secure. They do expect enough to be diverted to the black market that they feel they need a response. NSA's emphasis was on the foreign black market... There seems to be a desire to manipulate the market, by having the fixed cost of key escrow cryptography amortized over the government market. Any private sector devices would have to sell a much larger number of units to compete on price. (This was somewhere between an implication and an explicit statement on their part.) When asked about cryptography in software, "~...if you want US government cryptography, you must do it with hardware~". Clipper chips should be available (to product vendors) in June. You can't just buy loose chips - they have to be installed in approved products. Your application interface has to be approved by NIST for you to get your hands on the chips. An interesting point came up about the reverse-engineering resistance of the chips: they are designed to resist reverse engineering the data in the chip without destroying the chip. It is not clear (from the information presented at the meeting) whether the chips are equally resistant to destructive reverse-engineering to learn the skipjack algorithm. They said the algorithm was patented, but they may have been joking. ("~And if that doesn't scare you enough, we'll turn the patent over to PKP.~") The resistance to reverse engineering is not considered absolute by NSA. They do feel that "~it would require the resources of a national laboratory, and anyone with that much money can design their own cryptosystem that's just as strong.~" They repeated several times that there are "~no plans to regulate the use of alternate encryption within the US by US citizens.~" They also indicated they "~weren't naive~" and didn't think that they could if they wanted to. There were 919 authorized wiretaps, and 10,000 pen register monitors, in 1992. They do not have any figures yet on how often cryptography was used to frustrate wiretaps. They do not yet have a production version of the "decoder" box used by law enforcement. Initially, the family key will be split (by the same XOR method) and handled by two different people in the athorized agencies. There is presently only one family key. The specifications of the escrow exploitation mechanism are not yet final, either; they are considering the possibility of having the central site strip off the outer layers of encryption, and only sending the session key back to the decoder box. The escrow authorities will NOT require presentation of a court order prior to releasing the keys. Instead, the agency will fill out a form certifying that they have a legal authorization. This is also backed up with a separate confirmation from the prosecutor's office. The escrow agencies will supply any key requested and will not themselves verify that the keys requested are associated with the particular court order. The NSA did not answer a question as to whether the national security community would obtain keys from the same escrow mechanism for their (legally authorized) intelligence gathering or whether some other mechanism would exist for them to get the keys. The masks for the Clipper/Capstone chip are unclassified (but are protected by trade secret) and the chips can be produced in an unclassified foundry. Part of the programming in the secure vault includes "~installing part of the Skipjack algorithm.~" Later discussion indicated that the part of the algorithm installed in the secure vault are the "S-tables", suggesting that perhaps unprogrammed Clipper chips can be programmed to implement other 80-bit key, 32 round ciphers. The Capstone chip includes an ARM-6 RISC processor that can be used for other things when no cryptographic functions are performed. In particular, it can be used by vendors as their own on-board processor. The I/O to the processor is shut off when a crypto operation is in progress. They passed around a Tessera PCMCIA (type 1) card. These cards contain a Capstone chip and can be used by general purpose PC applications. The cards themselves might not be export controlled. (Unfortunately, they took the sample card back with them...) The card will digitally sign a challenge from the host, so you can't substitute a bogus card. The cards have non-volatile onboard storage for users' secret keys and for the public keys of a certifying authority. They are building a library/API for Tessera, called Catapult, that will provide an interface suitable for many different applications. They have prototype email and ftp applications that already uses it. They intend to eventually give away source code for this library. They responded favorably to the suggestion that they put it up for anonymous ftp. Applications (which can use the library and which the NSA approves for government use) will be responsible for managing the LEAF field. Note that they intend to apply key escrowed Skipjack to other applications, including mail and file encryption. The LEAF would be included in such places as the mail header or the file attributes. This implies that it is possible to omit sending the LEAF -- but the decrypt chip won't work right if it doesn't get one. When asked, they indicated that it might be possible wire up a pair of Clipper/Capstone chips to not transmit the LEAF field, but that the way to do this is "~not obvious from the interface we give you~" and "~you'd have to be careful not to make mistakes~". They gave a lot of attention to obvious ways to get around the LEAF. The unit key is generated via Skipjack itself, from random seeds provided by the two escrow agencies (approximately monthly, though that isn't certain yet). They say they prefer a software generation process because its correct behavior is auditable. Capstone (but not Clipper) could be configured to allow independent loading of the two key halves, in separate facilities. "~It's your money [meaning American taxpayers].~" The LEAF field contains 80 bits for the traffic key, encrypted via the unit key in "~a unique mode ~", 32 bits for the unit id, and a 16 bit checksum of some sort. (We didn't waste our breath asking what the checksum algorithm was.) This is all encrypted under the family key using "~another mode ~". They expressed a great deal of willingness to make any sort of reasonable changes that vendors needed for their products. They are trying *very* hard to get Skipjack and key escrow into lots of products. ***end of article*** From m5 at vail.tivoli.com Thu Feb 3 05:36:11 1994 From: m5 at vail.tivoli.com (Mike McNally) Date: Thu, 3 Feb 94 05:36:11 PST Subject: A serious question of ethics In-Reply-To: <9402030727.AA27027@pmantis.berkeley.edu> Message-ID: <9402031335.AA17716@vail.tivoli.com> This seems like a textbook example of an ideal use of a remailer. What makes you hesitant to use that method? As you say, it's unlikely that the government would go to the extensive trouble of trying to bust you if you go through penet. The worst that could happen would be that they'd ignore the blowing whistle, but that'd be their problem. Note that there may be some way that they could figure out where you telnetted in from once you alert them to the security hole. -- | 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 mg5n+ at andrew.cmu.edu Thu Feb 3 08:54:43 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Thu, 3 Feb 94 08:54:43 PST Subject: Canadian gov't eavesdropping In-Reply-To: <9402021727.AA04813@netmail2.microsoft.com> Message-ID: Eli Brandt sent the the following to cypherpunks: > > HIGH-TECH SNOOP GADGET. A super-secret branch of the Canadian > > Security Intelligence Service has awarded three contracts to a Montreal > > firm to make equipment that can quickly isolate key words and > > phrases from millions of airborne phone, fax, radio signals and other > > transmissions. The hardware has the "Orwellian potential to sweep > > through ... and keep records of all conversations," said one CSIS critic. > > (CTV National News, 01/31/94 11:00 pm). > > Dunno how feasible this kind of keyword recognition presently is, > but here's another reason to encrypt. VERY feasible. The US government has had this technology for several years; the Canadians are just catching up. In the late 80s the US military launched a satellite to spy on the Russians. The satellite was programmed to scan radio transmissions - especially cellular phones - searching for key words which might be related to military or government activities. It seems a few communist party members got a little too confortable with their cellular phones in their limosuines, and spoke very loosely about some secret government projects... They have mentioned this in the series "Space Age" which airs periodically on PBS. From CHRISTI1 at MUVMS6.WVNET.EDU Thu Feb 3 08:59:45 1994 From: CHRISTI1 at MUVMS6.WVNET.EDU (IGOR) Date: Thu, 3 Feb 94 08:59:45 PST Subject: Can you see.... Message-ID: <01H8G0JDA9FE001WLN@MUVMS6.WVNET.EDU> in VMS if someone goes into the sendmail services (i.e. port 25 and see what they send out?) Bob \//// (0 0) *------------------------------oOO--(_)--OOo---------------------------------* | Bob Christian II "IGOR" * Internet:Christi1 at muvms6.mu.wvnet.edu| | Marshall University ***** E-Mail: Christi1 at muvms6.wvnet.edu | | Huntington, WV * GET HIGH....LEARN TO FLY! IP-ASEL | | Student/D.J 88.1 WMUL FM * Major:Undecided(CJ/LAW) Minor:AVT | *----------------------------------------------------------------------------* --I love flying because there is no speed limit(^10k) and Radar is your friend! --Marshall assumes no libility for what I say, because my words are MINE! From pmetzger at lehman.com Thu Feb 3 08:59:46 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Thu, 3 Feb 94 08:59:46 PST Subject: No Subject In-Reply-To: <199402030530.XAA11324@chaos.bsu.edu> Message-ID: <199402031414.JAA10810@snark> Anonymous says: > > Perry almost wrote: > > > Anyway, people who want to use the law to restrict distribution of > > their software are extremely foolish. Your code is out there > > it WILL be copied. Forever. You can't help it. If you don't want > > people to use your software, don't write it. Of course, Perry didn't write that, and the person reading his messages obviously had an extremely weak understanding of what Perry had suggested in his messages (which was that if you are giving something away for free to all comers it is hard to argue economic damages have occured in "unauthorized" distribution), so it makes sense that the person replying would be too embarassed to use his own name. Perry From CHRISTI1 at MUVMS6.WVNET.EDU Thu Feb 3 08:59:46 1994 From: CHRISTI1 at MUVMS6.WVNET.EDU (IGOR) Date: Thu, 3 Feb 94 08:59:46 PST Subject: UNSUBSCRIBE Message-ID: <01H8G0CIH0LQ001WLN@MUVMS6.WVNET.EDU> UNSUBSCRIBE And yes I have tried the -request part. Bob \//// (0 0) *------------------------------oOO--(_)--OOo---------------------------------* | Bob Christian II "IGOR" * Internet:Christi1 at muvms6.mu.wvnet.edu| | Marshall University ***** E-Mail: Christi1 at muvms6.wvnet.edu | | Huntington, WV * GET HIGH....LEARN TO FLY! IP-ASEL | | Student/D.J 88.1 WMUL FM * Major:Undecided(CJ/LAW) Minor:AVT | *----------------------------------------------------------------------------* --I love flying because there is no speed limit(^10k) and Radar is your friend! --Marshall assumes no libility for what I say, because my words are MINE! From boone at psc.edu Thu Feb 3 08:59:46 1994 From: boone at psc.edu (Jon 'Iain' Boone) Date: Thu, 3 Feb 94 08:59:46 PST Subject: New remailer up. In-Reply-To: <199402022259.OAA21968@mail.netcom.com> Message-ID: <9402031518.AA22688@igi.psc.edu> qwerty-remailer at netcom.com writes: > Out of personal curiousity concerning the claims of how trivial > "traffic analysis" of the qwerty or catalyst remailers on Netcom > would be for "anyone" to carry out, I offer $20 to the first > person to reveal from which SITE this message originated from. > Please do not announce my name or login ID. Just the site. I am > logged into a friend's account and I am remailing this with no > encryption just through qwerty at netcom.com. It is now 5:41 PM EST. > > You do not have to reveal your methods to receive the award, which > I will mail to you. Happy hacking you WIMPS. > > If you wish to remain anonymous, mail the answer to qwerty at netcom.com > and my lips are sealed except for announcing success. Can someone from netcom mail me the syslog logs... Jon Boone | PSC Networking | boone at psc.edu | (412) 268-6959 PGP Public Key fingerprint = 23 59 EC 91 47 A6 E3 92 9E A8 96 6A D9 27 C9 6C From boone at psc.edu Thu Feb 3 09:04:43 1994 From: boone at psc.edu (Jon 'Iain' Boone) Date: Thu, 3 Feb 94 09:04:43 PST Subject: New remailer up. In-Reply-To: <199402030119.RAA17214@mail.netcom.com> Message-ID: <9402031548.AA23590@igi.psc.edu> qwerty-remailer at netcom.com writes: > > Perry wrote, > "However, make no mistake that Netcom can and will cooperate with the > police if you use your remailer in a way that the government doesn't > like, so it seems that the security afforded isn't that good." > > So you aren't interested unless you can commit serious felony crimes > using a given remailer? I would be happy if criminals stayed away from > my remailer. What do you mean by "security"? And if the police find out > a personally owned machine was involved, I couldn't imagine them not > just swooping in at midnight and taking it away at gunpoint. I hope > those privately owned machines don't have logs ;-). In my mind, the whole > secret to gaining privacy is not attracting attention in the first place. > Using a remailer DOES allow a person to communicate anonymously with > someone else, in two directions. If a party has enough power to tap > Netcom, then sendmail logs or no sendmail logs, they will find you. It seems that most (if not all) of netcom's unix machines are SunOS based. If that is the case, by installing NIT in the kernel, one would be able to grab all of the packets that flow across that ethernet (192.100.81) This includes your remailer mail. The "cost" to set this up would be the risk of being caught and the time and trouble to come up with root on one of their sun machines. Aside from the obvious legal risks, there are ethical considerations to keep in mind. While I personally would not attempt such a thing, there are many out there who feel otherwise. I won't hack into mail.netcom.com to demonstrate that it is possible to figure out who used your remailer. But, if one of the admins from netcom wants to send me their syslogs, I'll do my best to put together a correlation. > and, > "Besides, $20 is a paltry sum for the amount of work involved." > > Think of it as a trophy, which I'm sure most understood. I'm not offering > you a job. Yes, but the trophy is hardly worth the effort. Even though it wouldn't cost $50,000 in terms of actual equipment or time, it might well take such a sum to cause Perry to take the risk of being caught. Unless the netcom folks are real slouches, I would think that they would notice that their kernel had been re-compiled and the machine rebooted. Good luck not being detected... Of course, there is always the off chance that they already have NIT compiled into the kernel... Jon Boone | PSC Networking | boone at psc.edu | (412) 268-6959 PGP Public Key fingerprint = 23 59 EC 91 47 A6 E3 92 9E A8 96 6A D9 27 C9 6C From mg5n+ at andrew.cmu.edu Thu Feb 3 09:09:43 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Thu, 3 Feb 94 09:09:43 PST Subject: contemplating remailer postage In-Reply-To: <9402022200.AA01456@uu4.psi.com> Message-ID: Jim_Miller at suite.com wrote: > Seems simple enough. The major sticking point (to me) is the remailer's > "used stamp" archive. This could grow to be very large. Something needs > to be done to keep the archive from getting too large. > > One idea is to have the remailer periodically change the key it uses to > sign stamps. Changing the "stamp validation key" effectively invalidates > all unused stamps signed by that key. If you haven't used the stamp by > that time, you're out of luck. The remailer can purge its "used stamp" > archive whenever it changes its "stamp validation key". > > Of course, invalidating peoples' unused stamps out from under them is > not a nice thing for a remailer to do. The remailer could provide a > mechanism whereby people could get new stamps from old, unused > stamps. To make this work, the remailer would have to retain the > previous "used stamp" archive for a while to give people a chance to get > new stamps. However, there still needs to be a limit on how long the > remailer retains the "used stamp" archives for old validation keys. If > you wait too long, you would lose any chance to get new stamps from old. > > Comments welcome. How about this: Issue numbered stamps sequentially. Encrypt them and add a cryptographic checksum to each stamp. You then create a database such that one bit of data corresponds to one stamp. With a mere 64K database, you could issue and keep track of 524288 postage stamps. That ought to last you a few years. (At 100 letters a day, it would last over 14 years. Most cypherpunk remailers get considerably less than 100 emails a day.) From darrellp at cajal.uoregon.edu Thu Feb 3 11:19:43 1994 From: darrellp at cajal.uoregon.edu (Darrell Perko) Date: Thu, 3 Feb 94 11:19:43 PST Subject: Unsubscribe. Message-ID: <9402031918.AA05711@cajal.uoregon.edu> Please unsubscribe me. Thanks. From drzaphod at brewmeister.xstablu.com Thu Feb 3 12:09:44 1994 From: drzaphod at brewmeister.xstablu.com (DrZaphod) Date: Thu, 3 Feb 94 12:09:44 PST Subject: A serious question of ethics In-Reply-To: <9402030727.AA27027@pmantis.berkeley.edu> Message-ID: > 3) Should I take advantage of it (well, maybe not) How about offering your services to them as a security consultant.. grin. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - DrZaphod #Don't Come Any Closer Or I'll Encrypt! - - [AC/DC] / [DnA][HP] #Xcitement thru Technology and Creativity - - [drzaphod at brewmeister.xstablu.com] [MindPolice Censored This Bit] - - 50 19 1C F3 5F 34 53 B7 B9 BB 7A 40 37 67 09 5B - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From mg5n+ at andrew.cmu.edu Thu Feb 3 12:24:46 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Thu, 3 Feb 94 12:24:46 PST Subject: New remailer up. In-Reply-To: <9402031548.AA23590@igi.psc.edu> Message-ID: "Jon 'Iain' Boone" > Yes, but the trophy is hardly worth the effort. Even though it wouldn't > cost $50,000 in terms of actual equipment or time, it might well take > such a sum to cause Perry to take the risk of being caught. Unless the > netcom folks are real slouches, I would think that they would notice > that their kernel had been re-compiled and the machine rebooted. Good > luck not being detected... Of course, there is always the off chance > that they already have NIT compiled into the kernel... Ah, yes, but if you were a skilled machine lanugage hacker you could use a dissassembler to patch the code while it was in RAM. Very difficult to do, but also very difficult to detect. In theory, if you could steal their kernal (or had a similiar one) and you compiled it on your own Sun station, you could could probably isolate the routines you needed to patch, write a program to locate the processes running on root, scan memory looking for that subroutine, and then let you insert your own. The Netcom folks would have to look pretty hard to catch on to that type of attack...and if they rebooted - poof! - the evidence disappears! :) It's certainly more than $20 worth of work tho... and you'd still have to find a way to get to root (or at least grab control of the cpu chip for a few microseconds). What kind of cpu do Suns use anyway? (I've never used a sun before, and I don't know much about them.) I know NeXT used the 680x0... What about DEC? (I'm just a PC user type showing my ignorace about other systems. :-) From hkhenson at cup.portal.com Thu Feb 3 12:34:46 1994 From: hkhenson at cup.portal.com (hkhenson at cup.portal.com) Date: Thu, 3 Feb 94 12:34:46 PST Subject: San Jose BBS subject to Memphis standards? Message-ID: <9402031230.1.2582@cup.portal.com> Just got word a few minutes ago that Robert Thomas (who ran Amateur Action BBS) and his wife were picked up on a Federal warrant for obscenity from Memphis, TN. From what I hear from a local Postal inspector, they are going to extradited to TN to face charges there because the Feds have a choice of trying a person at either end of a transaction. This really sucks! I find it akin to busting a pron shop owner in New York for one of his customers taking "filthy pictures" back to Hicksvill. In operation Longarm the Feds argued that the person downloading stuff was responsible for knowing if it was illegal. This at least makes some sense. But, if BBS owners have to be responsible for knowing the what is considered obscene in all 50 states and each locality, then the onramps to the Information Superhighway are going to be choked off by the most backwater places in the country! Keith Henson (The entire tale of AA has been posted. I can repost if more than a few want it.) ---- The above was widely posted, this below is going to the cypherpunks list only. (for all the protection that may provide :) ) I have rather mixed feeling about the feds making these kinds of busts. I sort of wish they would not try to apply obscenity standards from the least enlightened parts of the country to all of the net community. ON the other hand, the serious adult bbs owners have enough computing resources (and now a strong motivation!) that encrypting, digital payments, "webs of trust," DC nets, etc. can be implemented at relatively low cost to them. If the feds persist, I suspect that adult bbs's are where--for all the trouble it may later cause--cypherpunk code will *really* get wide use. If you have things on which you want further information, please cc me by email as well as sending it to the list. I recently took on running Xanadu Operating Company, and am days behind reading the list Keith Henson From The.Ghost Thu Feb 3 12:54:46 1994 From: The.Ghost (The.Ghost) Date: Thu, 3 Feb 94 12:54:46 PST Subject: No Subject Message-ID: <9402032051.AA08204@banneker.Stanford.EDU> testing... From nobody at shell.portal.com Thu Feb 3 13:14:48 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Thu, 3 Feb 94 13:14:48 PST Subject: San Jose BBS subject to Memphis standards? Message-ID: <199402032112.NAA26624@jobe.shell.portal.com> This is one of the best essays I've seen concerning the burning of the Constitution and Bill of Rights. Looking just at porno isn't the big picture. It's consensual crimes in general. Too bad most people only care about their corner of the room, cause the house is on fire and it'll get to their corner soon. Subject: January 1994 -- Casualties of War Drug prohibition has shot gaping holes in the Bill of Rights. Magazine: Reason Issue: February 1994 Title: Casualties of War Drug prohibition has shot gaping holes in the Bill of Rights. Author: Steven B. Duke and Albert C. Gross At 2 a.m. on June 29, 1991, Tracy White of Los Angeles was awakened by the explosion of a diversionary grenade set off in a trash can outside her front door. She stumbled out into the upstairs hallway and was met by a shaft of light and a man's voice. "Freeze," he said. "Police." At that moment, her bedroom windows shattered and two men clad in black hoods swung into the room. Her three infants shrieked in fright. Several guns were pointed at her. More men dressed in black bounded through the bathroom window. One ran into an adjoining bedroom and pinned Tracy's sister Yolanda and her 12-year-old daughter behind a door. The youngster tried to squirm free and found the barrel of a pistol against her head. She closed her eyes and urinated on herself. "I thought," she later said, "he was going to kill me. The police had been searching for White's cousin, a reputed gang member, who did not live there and was not there when the raid occurred. The White apartment was left a shambles. Almost all the windows were gone, crystal glassware was reduced to shards, and a chunk was missing from a couch armrest. Six months after the raid, White and her children still refused to move back into the old apartment, unable to find peace of mind in a place that reminded them of hooded men crashing through their windows. The injuries inflicted on the Whites were mostly psychological, but some searches are lethal. In Atlanta, in 1991, a pre-Christmas raid by nine cops with guns drawn awakened Bobby Bowman as they broke down his door with a battering ram. Bowman, who says he thought he was being robbed, opened fire with a shotgun. A gunfight ensued, and Bowman's 8-year-old stepson, Xavier, who had been sleeping in the front room, was killed by a detective's bullet. The police found $780 worth of crack in Bowman's apartment. Teresa Nelson, Georgia director of the American Civil Liberties Union, questioned whether it was worth the life of an innocent 8-year-old to get evidence in a drug case, but Atlanta police defended the tactics, as do police across the country. They claim that surprise and overwhelming force are necessary to minimize destruction of evidence. Many also make the debatable claim that violent attacks reduce the danger to the police from counterattacks. Such raids and ransackings are standard procedure in most large cities and, except in the most outrageous cases, they receive the approval of courts. Police can get search warrants on the flimsiest of suspicion -- even the word of an anonymous informant. In many cases, though, the police don't even bother to get a warrant, since they are virtually unfettered by the risk of successful suits or other sanctions, especially if they confine their warrantless invasions to poor members of minority groups. The Fourth Amendment of the U.S. Constitution, which guarantees against "unreasonable searches and seizures" and prohibits warrants on anything but "probable cause," is a casualty of the drug war. Other provisions intended to protect Americans from overzealous law enforcement -- the right to defense counsel, the right to a fair trial, and the right to property -- are also in danger. The debris of the war on drugs may ultimately include shreds of the Constitution as well as splintered doors, shattered glass, and broken furniture. Since the early 1970s, almost all the searches and seizures reaching the U.S. Supreme Court have been upheld. The Court has held, for example, that a search made on an invalid warrant does not require any remedy so long as the police acted in "good faith." People may be stopped in their cars, in airports, on trains, or on buses, and subjected to questioning and dog sniffs of their persons and possessions. Police may search an open field without warrant or cause, even if it has "no trespassing" signs and the police incursion is a criminal offense. They may also, as in Orwell's 1984, conduct close helicopter surveillance of our homes and backyards. If it is outside the house, they may search our garbage without cause. If they have "reasonable suspicion," the police may even search our persons and possessions. Mobile homes, closed containers within cars, as well as cars themselves may be searched without a warrant. The Court has also held, in the 1985 case United States v. Montoya De Hernandez, that an international traveler, if a suspected "balloon swallower," may, without warrant or probable cause, be seized as she arrives at the airport, strip-searched, and ordered to remain incommunicado until she defecates over a wastebasket under the watchful eye of two matrons. In sanctioning such an 18-hour ordeal, Chief Justice William H. Rehnquist unabashedly listed other invasions that the Court had upheld: "[F]irst class mail may be opened without a warrant on less than probable cause.IAutomotive travelers may be stoppedInear the border without individualized suspicion even if the stop is based largely on ethnicityIand boats on inland waters with ready access to the sea may be hailed and boarded with no suspicion whatever." Those incursions, as well as detention for defecation, Rehnquist said, are responses to "the veritable national crisis in law enforcement caused by smuggling of illegal narcotics. In the compulsory defecation case, as in countless others, searches or seizures have been up- held on nothing more than "reasonable" or even "articulable" suspicion that drugs are being transported. That level of suspicion can be achieved by matching up the victim of the search or seizure with a few of the characteristics contained in secret "drug-courier profiles" that rely heavily upon ethnic stereotypes. As a result of such profiles, hundreds of innocent people are subjected to indignities every day. Twenty-seven-year-old Kurt Disser is an example. A diamond dealer, he frequently drives between San Diego and Los Angeles on business. Sixty-six miles from the Mexican border, on Interstate Route 5, near San Clemente, the Immigration and Naturalization Service maintains a checkpoint, allegedly to detect illegal aliens but increasingly serving in the drug war. Most of the 115,000 drivers who pass through the checkpoint each day are merely required to slow down while an officer glances at them. Disser, however, was stopped and searched 15 of the 30 times he traversed the route during a 17-month period. On several occasions, he was frisked and his car trunk was searched. Drug-sniffing dogs were given repeated whiffs of Disser's car. Several times, agents told him the dogs detected drugs and this led to a full search. No evidence of drugs or criminality of any kind was ever found. Disser has no criminal record. He was stopped and searched solely because of his appearance (he has long hair and drives an elderly Cadillac, both characteristics apparently found in the profiles). Hispanics and "hippie types" bear the brunt of the profiles near our southern border, but young African Americans suffer from them throughout the country. An African American who drives a car with an out-of-state license plate is likely to be stopped almost anywhere he goes in the United States. A survey of car stoppings on the New Jersey Turnpike revealed that, although only 4.7 percent of the cars were driven by blacks with out-of-state plates, 80 percent of the drug arrests were of such people. In 1991 the Pittsburgh Press examined 121 cases in which travelers were searched and no drugs were found. Seventy-seven percent of the people were black, Hispanic, or Asian. In Memphis, about 75 percent of the air travelers stopped by drug police in 1989 were black, yet only 4 percent of the flying public is black. Almost as offensive as relying on racial characteristics in a profile to justify searches or seizures is permitting the trivial and subjective profile characteristics to count as "reasonable" or "articulable" suspicion. Warren Ferguson, a judge on the U.S. Court of Appeals for the Ninth Circuit, has observed that the Drug Enforcement Administration's profiles have a "chameleon-like way of adapting to any particular set of observations." In one case, a suspicious circumstance (profile characteristic) was deplaning first. In another, it was deplaning last. In a third, it was deplaning in the middle. A one-way ticket was said to be a suspicious circumstance in one case; a round-trip ticket was suspicious in another. Taking a nonstop flight was suspicious in one case, while changing planes was suspicious in another. Traveling alone fit a profile in one case; having a companion did so in another. Behaving nervously was a tipoff in one case; acting calmly was suspicious in another. Another favorite basis for suspicion is that the suspect is traveling to or from a major source city for drugs, even though every U.S. city with a major airport qualifies for that designation. Even the same agents take contradictory positions. In Tennessee, the Pittsburgh Press reports, an agent testified that he was leery of a man because he "walked quickly through the airport." Six weeks later, the same agent swore that his suspicions were aroused by a man because he "walked with intentional slowness after getting off the bus. As even their users admit, the profiles are self-fulfilling. If the profiles are based on who is searched and found guilty, the guilty will necessarily fit the profiles. The DEA claims to catch 3,000 or more drug violators through the profiles, but no records are kept of how many people are hassled, detained, or searched to produce the 3,000. The DEA keeps no records of the profile system's failures. Some numbers, however, are available. Rudy Sandoval, a commander of Denver's vice bureau, estimated that his police conducted 2,000 airport searches in 1990, yielding only 49 arrests. In Pittsburgh, where records were kept, 527 people were searched in 1990, and 49 were arrested. In the Buffalo airport, in 1989, 600 people were stopped by police and only 10 were arrested. Said George Pratt, a judge on the U.S. Court of Appeals for the Second Circuit: "It appears that they have sacrificed the Fourth Amendment by detaining 590 innocent people in order to arrest 10 who are not -- all in the name of the `war on drugs.' When, pray tell, will it end? Where are we going? What the drug war has done to the Fourth Amendment, it has also done to the Sixth. The Sixth Amendment guarantees, among other things, that in "all criminal prosecutions" the accused shall enjoy "the assistance of counsel for his defense." No other right is as precious to one accused of crime as the right of counsel. A loyal, competent lawyer is essential for the protection of every other right the defendant has, including the right to a fair trial. In recognition of that fact, the definition of the enemy in the war against drugs has been expanded. Not only are drug sellers and drug users targets, so are their lawyers. Criminal-defense lawyers, especially if they practice in federal courts, have increasingly come to expect their law offices to be searched, their phones to be tapped, or their offices bugged. They are rarely surprised when they get Internal Revenue Service summonses seeking information about their criminal clients, about themselves, or about both. Prosecutors frequently serve subpoenas on defense lawyers prior to trial, requiring them to produce documents and testify about their client before a grand jury, in secret. Having thus driven a wedge between client and attorney, creating mistrust of the lawyer at least and a disqualifying conflict of interest at worst, the prosecutor is then in a strong position to coerce a guilty plea or, in intractable cases, to seek disqualification of the lawyer on the eve of trial, when no other lawyer has time to prepare a defense. The courts have upheld all these practices, the effect of which is to deprive the accused of his only real defensive armament. The Supreme Court added a powerful missile to the government's arsenal when it held, in the 1989 case Caplin & Drysdale v. United States, that federal authorities could freeze and later obtain the forfeiture of the assets of a person accused of a drug crime, so that he would have no money with which to pay a lawyer. The centuries-old tradition that confidential conversations between a lawyer and client cannot be divulged without the consent of the client also seems headed for the basement of American legal history. Courts have held that because "monitoring" of conversations in jails and prisons is well-known, any attorney-client conversations that are eavesdropped upon or tapped are fair game -- they have been implicitly "consented" to. This absurd fiction was even applied to Col. Manuel Noriega, who barely speaks English. After he was kidnapped in Panama and thrown in a Miami jail, his phone conversations with his lawyers were "monitored." A federal court found he waived his rights by talking on the phone. Courts have expanded other exceptions to the attorney-client privilege to the point that little is left of the privilege in criminal prosecutions. Two exceptions together almost swallow the privilege: 1) If the attorney's services were sought, in whole or in part, to aid in the commission of a crime or a fraud, the crime-fraud exception applies; 2) if necessary to clear himself of suspicion, the attorney can disclose privileged confidential communications, even if they bury the client. In short, if the interests of attorney and client are in conflict, the interests of the attorney prevail. Anyone accused of being involved with illegal drugs who is (or ever has been) guilty of the crime charged or any other acquisitive crime and hires a lawyer is necessarily seeking, at least in part, to cover up past crimes and to avoid future claims against his assets, such as tax claims, forfeiture claims, and the like. Courts have ruled that it's enough for prosecutors to show there is "probable cause" to believe the attorney is helping his client achieve such objectives, which are usually regarded as impermissible. (Probable cause can even be based on the attorney-client conversations themselves.) It is not possible to separate consultations concerning past money-making crimes, to which the attorney-client privilege supposedly still applies, and consultations about future crimes or frauds, to which the privilege does not apply. Faced with such overlaps, courts commonly find there is no privilege. Even if the crime-fraud exception does not destroy the privilege, the second, save-the-lawyer-at-any-cost exception often will. A prosecutor can apparently trump the privilege simply by making insinuations about the complicity of counsel in the client's alleged criminal activities. The lawyer can then betray the client to clear himself. That this rule permits the prosecutor to destroy the accused's privilege by a mere insinuation seems not to bother either courts or experts on legal ethics. Courts have also upheld recent requirements that criminal-defense lawyers report to the IRS anyone who pays them $10,000 or more in cash, whether a client or a third party. Attorneys who have refused to make such reports about their clients have been jailed. As of 1986, it is also a felony for anyone, including a lawyer, to accept money or property in excess of $10,000 that was derived from specified unlawful activity. It is no defense for a lawyer or any other recipient that the money or property was received for legitimate goods or services, even essential legal services. Nor is it a defense that the attorney had nothing to do with the illegal activity that generated the money or property. Nor is it a defense that the attorney was unaware of the specific kind of criminal activity that produced the money. It is not even a defense for the attorney that he had no actual knowledge that the money or property was illegally derived. "Willful blindness" is a substitute for knowledge, and the lifestyle of the client -- fitting stereotypes of how drug dealers comport themselves -- may go far toward establishing the attorney's guilty "knowledge" or "willful blindness." Thus, an attorney who represents a person who is charged with a drug offense who "looks like" a drug dealer is at risk of being indicted also. Defense lawyers therefore risk losing not only their fee but their freedom and their license to practice law for trying to protect the constitutional rights of their clients. And the possible charges against lawyers are not limited to accepting "tainted" money as payment of a fee. Lawyers who help their clients avoid indictment or who represent them in business dealings, such as real-estate transactions, can be indicted with the client for money laundering, tax evasion, or even drug trafficking. Attorneys who confine their professional activities solely to defending clients who have already been arrested on charges still risk their own indictment, for "obstruction of justice" if nothing else. Nobody knows what the limits of that crime are. Many prosecutors think that anything a defense attorney does that might be helpful in defending the client is such an obstruction. Courts have not yet embraced that interpretation, but neither have they repudiated it. According to Columbia University law professor H. Richard Uviller, a former prosecutor, it is almost possible to say that the statute threatens a five-year penalty for virtually any conduct that the government deems evasive, abusive, or inconvenient while a judicial proceeding is pending. It has always been difficult for persons accused of drug crimes to find competent attorneys willing to bear the stigma of being "a drug dealer's lawyer." But now that such attorneys also risk losing both their fees and their freedom, privately retained drug-defense lawyers are on their way to extinction -- which is what the Congress and the Supreme Court appear to want. Court opinions that chisel away at specific constitutional guarantees ought to be alarming to all who value liberty, but such decisions are at least visible and are subject to intense scrutiny and criticism. Legal scholar Steven Wisotsky calls the result of this chiseling process "the Emerging `Drug Exception' to the Bill of Rights." A less visible and therefore more ominous "drug exception" corrodes the amorphous right to a fair trial protected by the Fifth and 14th Amendments' Due Process clauses. In most drug prosecutions, the trial proceedings are ignored by the press and no opinions are written by the trial judges justifying or explaining their rulings. Those accused of crime must rely on the integrity of appellate judges to scrutinize the record and ensure that the trial proceedings were fair and consistent with due process. Yet in many courts criminal convictions and long prison sentences are routinely upheld without even hearing argument of the appeal and without even the writing of an appellate opinion. In such cases, there is no basis for believing that the appellate judges bothered to read the briefs or understood the issues, much less that they dealt with them fairly. The prevailing, although rarely acknowledged, attitude in American courts is that almost any trial is too good for a person accused of a drug crime. That attitude was succinctly displayed in a remark by one of the most liberal Supreme Court justices. In a 1987 interview with Life, Thurgood Marshall said, "If it's a dope case, I won't even read the petition. I ain't giving no break to no dope dealer." That statement caught the attention of some in the legal profession, but it produced neither a bark of criticism nor a paragraph of protest. The pressures that the drug war have brought to bear on already overburdened courts have produced a breakdown in both their integrity and the respect in which they are held. Many defense lawyers and scholars are convinced that appellate judges will say anything to uphold a drug conviction. If such judges don't affirm without writing any opinion at all, they often issue unsigned opinions and, because such opinions are so shoddy, forbid their publication. The courts will not even allow lawyers to cite such "opinions" as precedent in other cases. Finally, when they do publish their opinions, judges often invent nonexistent "facts" to support their affirmances. Respect for the American judiciary by lawyers who appear before them has probably never been lower. Occasionally, a judge rails against the trampling of rights under the tanks of the drug war. Usually, this is done as part of a multi-judge panel, where a judge can dissent from the decision of the majority while having no discernible effect on the outcome. Such dissenting opinions can ring the bells of freedom while the majority orders the defendant packed off to prison. The dissenter has little responsibility for what he says, since he is not deciding the case. Protests by judges at the trial level, where a single judge is responsible for the outcome, require more courage and happen less often. One such judge was U.S. Magistrate Peter Nimkoff of Miami. Nimkoff frequently offended prosecutors and other judges by granting bail to defendants accused of major drug crimes. Most judges either order the defendant detained without any bail at all -- a power given to them by the 1984 Bail Reform Act -- or find out how much bail the defendant can post and then set bail at five or 10 times that amount. Nimkoff asserted that the Constitution presumes the innocence of all persons accused of crime, even a drug crime. In a 1984 case, he blasted as "outrageous" the tactics of a DEA agent who, posing as a friend of a lawyer's client, tried to get the Miami attorney to divulge confidential communications from his client. DEA agents then tried to implicate the lawyer himself in an escape plot. Failing that, they obtained a search warrant on a fraudulent affidavit and thus were able to read privileged letters between attorney and client. In another case, Nimkoff denounced the DEA's use of a female informant who set up at least 40 men, enticing them into drug deals after developing a sexual relationship with them. The "boyfriend" would be busted, and the "girlfriend" would get paid by the DEA. Finally, in 1986, Nimkoff had enough. He resigned to protest the relentless erosion of rights and the governmental abuses of power with which he was daily confronted. In a press conference, he decried the view "that there are two constitutions -- one for criminal cases generally and another for drug cases." Such a view is not only wrong, he said. It "invites police officers to behave like criminals. And they do." Nimkoff's lamentations had the impact of a flower falling in the forest. Miami's major newspaper, the Herald, found nothing about his resignation or his press conference that warranted reporting. The drug war's threats to the Bill of Rights extend not only to those civil liberties favored by ACLU liberals but also to property rights. The signers of the Declaration of Independence believed, with John Locke, that the right of property was fundamental, inalienable, an aspect of humanity. They regarded liberty as impossible without property, which was the guardian of every other right. These beliefs are reflected in constitutional text. The Fifth Amendment declares that "no person shall be deprived of life, liberty or property without due process of law; nor shall private property be taken for public use, without just compensation." Under forfeiture statutes enacted since 1970, however, both deprivations occur routinely, with the approval of courts. Under federal statutes, any property is subject to forfeiture if it is "used, or intended to be used, in any manner or part, to commit or to facilitate the commission" of a drug crime. (See "Ill-Gotten Gains," August/September 1993.) No one need be convicted or even accused of a crime for forfeiture to occur. Forfeiture is a "civil" matter. Title vests in the government instantly upon the existence of the use or the intention to use the property in connection with a drug offense. All the government needs to establish its right to seize the property is "probable cause," the same flimsy standard needed to get a search warrant. The government can take a home on no stronger a showing than it needs to take a look inside. Hearsay or even an anonymous informant can suffice. No legal proceedings are required before personal property may be seized. If the police have "probable cause" concerning a car, a boat, or an airplane, they just grab it. Although a hearing has to take place before property can be repossessed at the behest of a conditional seller, before a driver's license can be revoked, before welfare benefits can be terminated, and before a state employee can be fired, persons can have their motor homes confiscated without any proceedings of any kind, if the confiscation is a drug forfeiture. There may be a right to contest the forfeiture after the seizure, but even this right is lost if not promptly asserted. Moreover, the costs of hiring a lawyer and suing to recover the seized property may be prohibitive unless the seized property is of great value. As construed by the courts, the forfeiture statutes also encourage police to make blatantly unconstitutional seizures. Property may be seized without probable cause -- on a naked hunch -- and still be retained and forfeited. Courts hold that illegally seized property may be forfeited if the police establish probable cause at the forfeiture proceeding itself. It doesn't matter that there was no cause whatever for the seizure; it doesn't matter that the seizure was illegal, even unconstitutional. If the government can later establish probable cause (through the seized property itself or investigation occurring after the seizure), that is sufficient to uphold a forfeiture. If the government wants to seize real property without notice, it has to get a court's approval, but that is as easy as getting a search warrant. A seizure warrant is obtained in the same way as a search warrant and on the same hearsay grounds. In 1988, a six-story apartment building in New York, containing 41 apartments, was seized on such a warrant, which the appellate court upheld. No civilized country imposes criminal punishment for mere evil intentions, but the forfeiture statutes -- since they are "civil," not "criminal" -- are apparently subject to no such limitation. In 1991 the U.S. Court of Appeals for the Third Circuit held that a home was forfeitable because the owner, when he applied for a home equity loan, "intended" to use the proceeds to buy drugs. By the time the loan actually came through, he had used other funds for that purpose, but that didn't matter, the court said, because he had intended to use the home to secure a loan, the proceeds of which he intended to use for drugs. The home was therefore no longer his. It would apparently have made no difference if he never even applied for the loan, as long as he thought about it. Any activities within a home that relate to drugs are sufficient for forfeiture of the home: a phone call to or from a source; the possession of chemicals, wrappers, paraphernalia of any kind; the storing or reading of any how-to books on the cultivation or production of drugs. The operative question is whether any of these activities was "intended" to facilitate a drug offense. If a car is driven to or from a place where drugs are bought or sold and is then parked in a garage attached to a home, the home has been used to store the car, which facilitated the transaction, and is probably forfeitable along with the car. If the home is located on a 120-acre farm, the entire farm goes as well. If only a few square feet of land in a remote section of a farm are devoted to marijuana plants, the grower loses not only the entire farm, but, if it is on the same land as the farm, his home as well. Once any property qualifies for forfeiture, almost any other property owned or possessed by the same person can fall into the forfeiture pot. Notions about how otherwise "innocent" property can "facilitate" illegal activities are almost limitless. In a 1991 Hawaii case, when drug proceeds were deposited in a bank account that contained several hundred thousand dollars in "clean" funds, the entire account was declared forfeit on the theory that the "clean" funds facilitated the laundering of the tainted funds. In a 1989 case involving a drug dealer who owned and operated a ranch in Georgia, his quarter horses -- all 27 of them -- were forfeited on the theory that, as part of a legitimate business, the livestock helped create a "front" for the owner's illegal activities. On this theory, the more "innocent" one's use of property is, the more effective it is as a "front" or "cover" and therefore the more clearly forfeitable. Entire hotels have been forfeited because one or more rooms were used by guests for drug transactions. Entire apartment houses have been lost because drug activities occurred in some apartments. In 1991 proceedings were brought to forfeit fraternity houses at the University of Virginia because some of the members sold drugs there. Those seizures created a stir, but they pale when compared to the potential. Imagine the government taking over New York's Plaza Hotel or one of the giant casino hotels in Atlantic City or Las Vegas on the same theory. Or taking over a company town because of a single drug sale or backyard marijuana plant. Harvard University is also available for the taking. There are certainly drug sales, drug use, even drug manufacturing taking place on campus. Under federal law, property owners can defeat civil forfeiture if they can prove either that the claimed offending use did not occur and was not even intended, or that the offending use occurred or was intended "without the knowledge or consent of that owner." Unfortunately, even this seemingly clear provision provides little protection for innocent owners. Courts have treated "knowledge" and "willful blindness" as equivalents and have then merged "willful blindness" into "negligence. Despite the plain language of the statute, most courts are unwilling to lift a forfeiture unless the owners can prove that the offending activity not only occurred without their knowledge or consent, but also that they did all that "reasonably could be expected to prevent the proscribed use of the property." The owner has been conscripted as a police officer to ensure that no improper use is made of the property. In a 1990 Milwaukee case, the owner of a 36-unit apartment building plagued by dope dealing evicted 10 tenants suspected of drug use, gave a master key to the police, forwarded tips to the police, and even hired two security firms. The city seized the building anyway. If owners discover that their property is being used to "facilitate" drug use or sale, what can they do to ensure that they will not lose their property to forfeiture? Nothing, probably. If they call the police and inform on their tenants, they have established their knowledge, as of the date they informed, which will usually be sufficient for forfeiture. Informing the police may go far toward establishing that owners did not "consent" to the illicit use, but many courts have held that the owner must both lack knowledge and not consent to the illicit use. As scary as forfeiture already is, it is spreading to other offenses. When it is extended to new areas, the punishment becomes drastically disproportionate to the offense and the constitutional safeguards of criminal procedure are circumvented. Already, federal forfeiture statutes apply to pornography, gambling, and several other offenses, as well as drugs. Some state forfeiture laws apply to property used in any felony. The forfeiture of cars used in sex offenses is commonplace. Hartford, Connecticut, recently began confiscating the cars of johns who cruise neighborhoods looking for prostitutes. Some states take one's car for drunk driving. Where will it end? Why not extend forfeiture to income-tax evasion and take the homes of the millions -- some say as many as 30 million -- who cheat on their taxes? The statutory basis for forfeiting homes and businesses of tax evaders is already in place. The Internal Revenue Code reads: "It shall be unlawful to have or possess any property intended for use in violating the provisions of the Internal Revenue Service LawsIor which has been so used, and no property rights shall exist in any such property. Although use of this provision has mainly been limited to seizures of moonshine and gambling equipment, and sometimes businesses, there is no reason, given the breadth of the drug forfeiture decisions, why it can't be employed to take the homes and offices of tax evaders and even those of their accountants and lawyers. A congressman who failed to pay Social Security tax on wages of his housekeeper could lose his home. Moreover, unlike drug forfeiture, the tax forfeiture statutes have no innocent-owner defense. If there is a shard of moral justification for forfeiture, it is that an owner, duly forewarned, chooses to use or permit his property to be used illegally and therefore voluntarily "waives" his constitutional rights of property. But such a "waiver" theory can be extended to destroy all rights and all liberty. It is a cancer on the Constitution, certain to metastasize if not eliminated soon. Steven B. Duke is Law of Science and Technology Professor at Yale Law School. Albert C. Gross is an attorney and writer in San Diego. This article is adapted from their book, America's Longest War: Rethinking Our Tragic Crusade Against Drugs (Putnam). ------------------------------------------------------------ The contents of this file are copyright 1993 by the publisher in whose directory this file appeared. Unauthorized copying of this information is strictly forbidden. Please read the general notice at the top menu of the Gopher Server for the Electronic Newsstand. For information regarding reprints, please send mail to REPRINTS at Enews.Com ------------------------------------------------------------ From pgpkeys at wasabi.io.com Thu Feb 3 13:14:48 1994 From: pgpkeys at wasabi.io.com (PGP Slave Key Server) Date: Thu, 3 Feb 94 13:14:48 PST Subject: PGP KEYS NOW BY FINGER! *** STOP PRESS *** Message-ID: <199402031525.PAA03435@wasabi.io.com> pgp key server functionality just took a great leap forward today when io.com's email server suddenly went interactive! finger @wasabi.io.com for details ^^^^^^ Note the 'wasabi' - finger @io.com won't work. You can get a list of users by doing: finger user at wasabi.io.com or even: finger user at host@wasabi.io.com And once you find their Key ID from the summary listing, you can then do: finger 0x123456 at wasabi.io.com ^^^^^^ The hex digits from the keyid Have fun! The Mgt. PS The finger requests to this server are *NOT* logged. (At least by us. Who knows what the NSA is up to :-) ) From qwerty-remailer at netcom.com Thu Feb 3 13:29:44 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Thu, 3 Feb 94 13:29:44 PST Subject: New remailer up. Message-ID: <199402032127.NAA18079@mail.netcom.com> -----BEGIN PGP SIGNED MESSAGE----- qwerty at netcom.com gains a bit bucket. :: Request-Remailing-To: /dev/null Bye bye mail. "BB" entered into my counter. Comments? Are slashes OK in a header line? - -Nik (Xenon) -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLVElIwSzG6zrQn1RAQE1qAP9Fu4tDpJclibx3CuzHGICpshNwULdYmn2 zfBMC+wuHGWvDvTtDX0+0HxfxLouOKAvvESJFt35Y0YSszT8KZmarSz5msOA179v +trsnSPw/BhjNvKQlhxHm7HpOr8JNoL3gB2zHz3EISEkdDtvRE3LRj4wu20P8DaP 7reDXreuDE4= =n99G -----END PGP SIGNATURE----- From hlin at nas.edu Thu Feb 3 13:54:46 1994 From: hlin at nas.edu (Herb Lin) Date: Thu, 3 Feb 94 13:54:46 PST Subject: Study of National Cryptography Policy Message-ID: <9401037603.AA760322850@nas.edu> February 3, 1994 To: Whom It May Concern Subject: A Study of National Cryptography Policy This message should be forwarded to any and all individuals or groups that may be interested. ----------------------------------------------- In a message broadcast electronically and by fax in December 1993, the Computer Science and Telecommunications Board (CSTB) of the National Research Council (NRC) issued a call for nominations of possible committee members who would undertake a study of national policy with respect to the use and regulation of cryptography. This report was requested by the U.S. Congress in the Defense Authorization Bill for FY 1994. That message said that ALL committee members (and associated staff) would have to be cleared at the "SI/TK" level. Since that time, there has been some discussion of a study that would only require SOME members of the study committee to be cleared. Thus, in the interests of casting the broadest possible net to capture the necessary expertise, we are re-issuing the call for nominations to find those people who otherwise fit the criteria below but who would have been reluctant to accept security clearances or to undergo the required investigation. It is expected that the study committee will be a high-level group that will command credibility and respect across the range of government, academic, commercial, and private interests. The committee will include members with expertise in areas such as: - relevant computer and communications technology; - cryptographic technologies and cryptanalysis; - foreign, national security, and intelligence affairs; - law enforcement; - commercial interests (both users and technology vendors); and - privacy and consumer interests. Committee members will be chosen for their stature, expertise, and seniority in their fields; their willingness to listen and consider fairly other points of view; and their ability to contribute to the formulation of consensus positions. The committee as a whole will be chosen to reflect the range of judgment and opinion on the subject under consideration. Note that NRC rules regarding conflict of interest forbid the selection as committee members of individuals that have substantial personal financial interests that might be significantly affected by the outcome of the study; in addition, individuals currently employed by the federal government are ineligible to serve on the study committee. Please forward suggestions for people to participate in this project to CSTB at NAS.EDU by February 11, 1993; please include their institutional affiliations, their field(s) of expertise, a note describing how the criteria described above apply to them, and a way to contact them. For our administrative convenience, please put in the "SUBJECT:" field of your message the words "crypto person". If you would like a copy of the original solicitation, please send a request to CSTB at NAS.EDU. On the National Research Council The National Research Council (NRC) is the operating arm of the Academy complex, which includes the National Academy of Sciences, the National Academy of Engineering, and the Institute of Medicine. The NRC is a source of impartial and independent advice to the federal government and other policy makers that is able to bring to bear the best scientific and technical talent in the nation to answer questions of national significance. In addition, it often acts as a neutral party in convening meetings among multiple stakeholders on any given issue, thereby facilitating the generation of consensus on controversial issues. The Computer Science and Telecommunications Board (CSTB) of the NRC considers technical and policy issues pertaining to computer science, telecommunications, and associated technologies. CSTB monitors the health of the computer science, computing technology, and telecommunications fields, including attention as appropriate to the issues of human resources and information infrastructure and initiates studies involving computer science, computing technology, and telecommunications as critical resources and sources of national economic strength. A list of CSTB publications is available on request. From jim at bilbo.suite.com Thu Feb 3 15:14:49 1994 From: jim at bilbo.suite.com (Jim Miller) Date: Thu, 3 Feb 94 15:14:49 PST Subject: contemplating remailer postage Message-ID: <9402032304.AA18410@bilbo.suite.com> Matthew J Ghio writes: > How about this: > > Issue numbered stamps sequentially. Encrypt them and > add a cryptographic checksum to each stamp. You then > create a database such that one bit of data corresponds to > one stamp. With a mere 64K database, you could issue and > keep track of 524288 postage stamps. That ought to last > you a few years. (At 100 letters a day, it would last over 14 > years. Most cypherpunk remailers get considerably less > than 100 emails a day.) > > > If the remailer constructs the stamp, rather than just signs it blindly, it could keep a log of which stamps were issued to which users. The remailer could then use this information to figure out the original sender of a stamped message regardless of how many other remailers the message passed through. To thwart this, users would have to purchase stamps anonymously. However, this begs the question: How does the user anonymously purchase stamps for the first remailer? I suppose you could use "free" remailers to send anonymous purchase requests to stamp-issuing remailers. The system I described does not require you to purchase stamps anonymously. You can purchase stamps directly from each remailer without giving the remailer the opportunity to record which stamp went to which user. To understand why this is true you need to understand how blind signatures work. The book "Applied Cryptography (Bruce Schneier)" gives a good description of the properties of blind signatures. That is how I learned about them. The remailer could still record the fact that you purchased stamps, thus alerting the bad guys that you plan to use the remailer system. However, I don't think it is possible to prevent the bad guys from learning that you use remailers. I assume the bad guys will be logging all traffic to the remailers and would learn about your use of remailers, stamps or no stamps. Jim_Miller at suite.com From mg5n+ at andrew.cmu.edu Thu Feb 3 15:14:49 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Thu, 3 Feb 94 15:14:49 PST Subject: No Subject In-Reply-To: <9402032051.AA08204@banneker.Stanford.EDU> Message-ID: The.Ghost at toad.com writes: > Received: by toad.com id AA04069; Thu, 3 Feb 94 12:51:58 PST > Received: from banneker.Stanford.EDU ([36.14.0.77]) by toad.com id AA04063; Thu, 3 Feb 94 12:51:55 PST > Received: by banneker.Stanford.EDU (5.57/Ultrix3.0-C) > id AA08204; Thu, 3 Feb 94 12:51:14 -0800 > Date: Thu, 3 Feb 94 12:51:14 -0800 > From: The.Ghost at toad.com > Message-Id: <9402032051.AA08204 at banneker.Stanford.EDU> > Apparently-To: cypherpunks at toad.com > > testing... Wow, look, someone at Stanford figured out how to use port 25! I hope that's a new anonymous remailer that you're testing there... :) From hughes at ah.com Thu Feb 3 15:24:48 1994 From: hughes at ah.com (Eric Hughes) Date: Thu, 3 Feb 94 15:24:48 PST Subject: ADMIN: list statistics Message-ID: <9402032319.AA20066@ah.com> I gathered some list statistics for the subscriber base as of Thursday, February 3, 1994, 12:00 noon. 657 subscription addresses total. 49 contain the string 'cypher' and are suspected gateways, either to individuals or large groups, so the exact amount is extremely hard to pin down. Here are the subscribers, broken down by top-level domain 300 com USA commercial 204 edu USA educational 25 org USA organizational 18 ca Canada 15 net networks 13 us USA geographical 10 uk United Kingdom 9 uucp UUCP links 8 se Sweden 7 gov USA government 7 au Australia 6 fi Finland 5 no Norway 4 de Denmark 3 mil USA military 3 it Italy 2 fido Fidonet 2 za South Africa 2 mx Mexico 1 ve Venezuela 1 su USSR (er, someone call a NIC) 1 si ( ? Slovenia ? ) 1 sg Singapore 1 nl Netherlands 1 jp Japan 1 in India 1 ie Ireland 1 hk Hong Kong 1 gb United Kingdom 1 fr France 1 es Spain 1 ee ? 1 ec Ecuador If anybody knows for sure where SI and EE are, I'd love to know. My list of ISO country codes is a little old. Here are the top individual domain names. We can see who has market share, at least. 51 netcom.com 16 aol.com 9 mcimail.com 8 well.sf.ca.us 7 delphi.com 6 world.std.com 5 umich.edu 5 shell.portal.com 5 microsoft.com 5 cleveland.Freenet.Edu 5 CompuServe.COM 4 phantom.com 4 panix.com 4 gnu.ai.mit.edu 4 crl.com 4 apple.com 3 ucsu.Colorado.EDU 3 toad.com 3 prodigy.com 3 nyx.cs.du.edu 3 mason1.gmu.edu 3 engin.umich.edu 3 ecf.toronto.edu 3 anon.penet.fi 3 access.digex.com 3 CUNYVM.CUNY.EDU Happy lack of trails. Eric From ravage at wixer.bga.com Thu Feb 3 15:24:49 1994 From: ravage at wixer.bga.com (Jim choate) Date: Thu, 3 Feb 94 15:24:49 PST Subject: Message returned to sender (fwd) Message-ID: <9402031634.AA14363@wixer> Forwarded message: From jim at bilbo.suite.com Thu Feb 3 15:39:44 1994 From: jim at bilbo.suite.com (Jim Miller) Date: Thu, 3 Feb 94 15:39:44 PST Subject: SASE Suggestion Message-ID: <9402032330.AA18898@bilbo.suite.com> Lance Cottrell writes: > One SASE scheme recently suggested involved sending a > request for a SASE to a ramailer, stating the number of > jumps required. It then sent it to another remailer, and > so on. Each adding a layer, and eventually sending the > results to the desired correspondent. I mentioned that > if the first remailer was corrupted, that the whole chain > was (it would only send to other corrupt remailers). > Oh, I see. I was confused as to which scheme you were talking about. You were refering (I think) to the "prepaid mailer" idea Tim May described in his "Re: Anonymous Anonymous ftp" post of Jan 27. Jim_Miller at suite.com From hayden at krypton.mankato.msus.edu Thu Feb 3 15:54:48 1994 From: hayden at krypton.mankato.msus.edu (Robert A. Hayden) Date: Thu, 3 Feb 94 15:54:48 PST Subject: ADMIN: list statistics In-Reply-To: <9402032319.AA20066@ah.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- On Thu, 3 Feb 1994, Eric Hughes wrote: > 1 si ( ? Slovenia ? ) > 1 ee ? > If anybody knows for sure where SI and EE are, I'd love to know. My > list of ISO country codes is a little old. si = Slovenia (you were right) ee = Estonia Source: The Big Dummy's Guide to the Internet Adam Gaffin and Jorg Heitkotter Available at ftp.eff.org ____ Robert A. Hayden <=> hayden at krypton.mankato.msus.edu \ /__ -=-=-=-=- <=> -=-=-=-=- \/ / Finger for Geek Code Info <=> In the United States, they \/ Finger for PGP 2.3a Public Key <=> first came for us in Colorado... - -=-=-=-=-=-=-=- (GEEK CODE 1.0.1) GAT d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++ n-(---) h+(*) f+ g+ w++ t++ r++ y+(*) -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVGO553BsrEqkf9NAQFd6AQAiu8TlrJ5ZU52vpfvMrS/YMYaCZCc6uZ2 yLoUcWBsv4FSbk2pXwjMTacWBvvFonKntwUT3GtWB0GRUqRzLCOYRG5cqcb0iPgC uK8BXhyTXcHxZXAfSW+qI53z+4dwCb9Tc/WRihkNuS+RaPWIBIllLRxtyiUQKopr fTDAVeWr7OM= =Jhqu -----END PGP SIGNATURE----- From Tomaz.Borstnar at arnes.si Thu Feb 3 15:54:48 1994 From: Tomaz.Borstnar at arnes.si (Tomaz Borstnar) Date: Thu, 3 Feb 94 15:54:48 PST Subject: ADMIN: list statistics In-Reply-To: <9402032319.AA20066@ah.com> Message-ID: <9402032349.AA06456@toad.com> In-reply-to: Your message dated: Thu, 03 Feb 1994 15:19:11 PST > 1 si ( ? Slovenia ? ) Good. :) Yeah, it's Slovenia. :) Tomaz From hughes at ah.com Thu Feb 3 16:04:48 1994 From: hughes at ah.com (Eric Hughes) Date: Thu, 3 Feb 94 16:04:48 PST Subject: ADMIN: list statistics In-Reply-To: <9402032319.AA20066@ah.com> Message-ID: <9402040000.AA20195@ah.com> Followups to me have yielded the following info: SI = Slovenia EE = Estonia One subscriber each. Thanks to Tomaz and Stephen for the info. Eric From pgpkeys at wasabi.io.com Thu Feb 3 16:49:44 1994 From: pgpkeys at wasabi.io.com (PGP Slave Key Server) Date: Thu, 3 Feb 94 16:49:44 PST Subject: A question of ethics. Message-ID: <199402031859.SAA03790@wasabi.io.com> >Ok, I'm in a bit of a quandry. While surfing the net last week, I >happened across an address addached to a machine that belongs the the >federal reserve. No big deal. I telnetted there on a lark, and entered >'guest' for the account. It dropped me into a shell. It didn't ask for >a password. Intrigued, I did a little looking around. Nothing special, >a CDRom and about 80 accounts. But(!!), /etc/passwd was there and >available and not using shadows. No, I didn't snatch a copy. > >Quandry(ies) > >1) Should I alert someone there about the obvious (and, IMHO serious) >seciruty hole? > > or > >2) Should I ignore it? > >3) Should I take advantage of it (well, maybe not) > >---------- > >I don't like to see systems so open, no matter who they belong too, and >the fact that the governments (whether you like them or not) has one this >open REALLY bothers me. > >But, I also wonder what kind of trouble I could get into. Technically, I >violated something just by being there as I didn't have permission, and >the fact I accessed the passwd file makes it even worse. If I report it, >I could be in deep shit. > >I could mail to them via a remailer (like penet.fi, so that they could >answer for more information if needed). That is a little securer and >Julf is out of jurisdiction of the FBI hunting me down. > >Yes, I'm a little paranoid, but Uncle Sam likes to make examples out of >white-collar hackers, and for me it was pure and dumb luck (like a jury >would believe a 22 year-old computer geek isn't trying to gain illegal >access). > >Any suggestions? Please? I consider this to be serious (most may not). Go to a COCOT and call Ms Flanagan below. *Not* the Tech contact, who is most likely the person who fucked up and will want to cover his butt. The admin contact should be more sympathetic... 20th and C Streets, NW Washington, DC 20551 Domain Name: FRB.GOV Administrative Contact: Flanagan, Elizabeth R. (ERF7) erf at FED.FRB.GOV (202) 452-2672 Technical Contact, Zone Contact: Drzyzgula, Robert P. (RPD5) rcd at FED.FRB.GOV (202) 452-3425 Record last updated on 14-Aug-91. Domain servers in listed order: NS.UU.NET 137.39.1.3 UUCP-GW-1.PA.DEC.COM 16.1.0.18 UUCP-GW-2.PA.DEC.COM 16.1.0.19 From cmckie at ccs.carleton.ca Thu Feb 3 17:29:44 1994 From: cmckie at ccs.carleton.ca (Craig McKie) Date: Thu, 3 Feb 94 17:29:44 PST Subject: Canadian voice recognition article Message-ID: <9402040124.AA03270@superior.YP.nobel> Spy Agency works on eavesdropping device for phones, faxes New snoop gadget would identify voices carried through air The Canadian Press Used on page 1, Ottawa Citizen, Monday January 31, 1994 An elite wing of Canada's spy agency is secretly developing devices that can monitor and identify voices carried through the air by phone, fax and radio signals, according to a broadcast report citing government documents. The Communications Security Establishment is a super-secret branch of the Canadian Security Intelligence Service that specializes in gathering signals intelligence - SIGINT to insiders. Since 1989, the CSE has awarded three contracts worth $1.1 million to a Montreal firm to make machines that can quickly isolate key words and phrases from the millions of signals the CSE monitors each day, CTV reported Sunday. In May 1983, the CSE awarded the Centre de Recherche Informatique de Montreal a contract to develop a "speaker identification system," which can pick voices from the electronic haze and identify them. "Its frightening," says Bill Robinson, a researcher with the peace group, Project Ploughshares. "It has Orwellian potential to sweep through everybody's conversations. As computers get faster and faster, theoretically, one would be able to keep records of all conversations." The CSE is supposed to provide the federal government with foreign intelligence, but parliamentarians have often voiced concerns about the agency's potential to violate the privacy of Canadians. Liberal MP Derek Lee, the head of a Commons committee that oversees Canada's spy agency, said the CSE is overstepping its mandate. "Have they been asked, or have they decided for themselves to take on a new role that requires them to analyse the human voice? And if they have, they've gone beyond what I think they've told us." The CSE is accountable to Parliament through the defence minister. But Defense Minister David Colonette told CTV her was unaware of the CSE's latest electronic snooping projects. "This is the first I've heard of this," Collenette said. "It is certainly something I'll discuss with my officials." While in Opposition, the Liberals pledged to make the CSE more accountable. With a budget of about $250 milliojn and more than 800 employees the CSE operates out of a building on Heron Road in Confederation Heights surrounded by a barbed-wire fence. Its work is considered so sensitive that employees are told not to take commercial flights, in case the plane is hijacked and they are held hostage. From anonymous at extropia.wimsey.com Thu Feb 3 17:49:44 1994 From: anonymous at extropia.wimsey.com (anonymous at extropia.wimsey.com) Date: Thu, 3 Feb 94 17:49:44 PST Subject: Remailer Tearline Conventions Message-ID: <199402040132.AA19447@xtropia> * Reply to msg originally in CYPHERPUNKS Uu> From: edgar at spectrx.saigon.com (Edgar W. Swank) Uu> Someone (not me) asked about remailer tearline conventions to Uu> eliminate automatic sigs: Uu> I'm the one who brought this up "months ago" and the short answer to Uu> your question is "no." Uu> Hall Remailer Uu> added a "cut line" of Uu> --ignore-- Uu> At the time I brought this up, the attitude of most remailer operators Uu> (Chael Hall and Miron Cuperman notably excepted) was that anyone who Uu> couldn't figure out how and remember to turn off their auto sig didn't Uu> deserve any privacy. An astonishing bit of Internet provincial fuckheadedness, I must say! When one considers that there are _many_ other nets that gate into Internet these days and innumerable store-and-forward host systems whose message handling processes are _completely_ beyond the control of the end user (even smug Cypherpunk geniuses), this attitude mystifies me. Uu> I recommend that you always use the wimsey (extropia) remailer as the Uu> first (or only) leg of a remailer chain. It is also the only Uu> Cypherpunks remailer outside the USA (it's in Canada) which will make Uu> tracing msgs a little more difficult for USA authorities. That remail at extropia.wimsey.com is in Canada specifically makes communications with it fair game for NSA interception, however. From kshep at netcom.com Thu Feb 3 19:04:49 1994 From: kshep at netcom.com (Kirk Sheppard) Date: Thu, 3 Feb 94 19:04:49 PST Subject: Remailer Tearline Conventions In-Reply-To: <199402040132.AA19447@xtropia> Message-ID: On Thu, 3 Feb 1994 anonymous at extropia.wimsey.com wrote: > > That remail at extropia.wimsey.com is in Canada specifically makes > communications with it fair game for NSA interception, however. NSA interception is world wide. Kirk Sheppard kshep at netcom.com P. O. Box 30911 "It is Better to Die on Your Feet Than to Bethesda, MD 20824-0911 Live On Your Knees." U.S.A. - Emiliano Zapata From jim at bilbo.suite.com Thu Feb 3 19:19:44 1994 From: jim at bilbo.suite.com (Jim Miller) Date: Thu, 3 Feb 94 19:19:44 PST Subject: On return addresses Message-ID: <9402040310.AA22295@bilbo.suite.com> Eric Hughes writes: > I've been troubled for many months by an invariant in all forms of > return address schemes: The outside world contains sufficient > _persistent_ information to find a real adress. > > [stuff deleted] > > So how do we solve it? By abandoning return addresses and > using mail spool facilities. > > [more stuff deleted] > > 1. I have a machine and I'll sell you an address on it... > > 2. When mail come in for you, it sits in a spool... > > 3. Your mail sits in the spool until you access it with... a > mail server command of "send me a mailbox file of my > waiting mail". > > [even more stuff deleted] > > The elimination of persistent identifying information > for return paths is a worthwhile design objective. I > propose that we start thinking about it more thoroughly. > > Eric > Let me see if I understand your idea correctly. I am picturing something like the following: There will exist a bunch of remailers that, in addition to forwarding mail, will also sell mailboxes. (I'm combining the remailer with the mail spools to add to the mix of messages to and from). The "mailboxes" are actually e-mail addresses referring to a pseudo-account on some machine that hosts a remailer/mail spooler. Bob would purchase a number of mailboxes scattered throughout the remailer/mail spooler system. Bob would give out the address of one of these mailboxes to people so they can send "reply" messages to him. Messages addressed to Bob's "public" mailbox would be spooled by the remailer hosting that mailbox. Periodically (perhaps frequently), Bob would send an anonymous message (via other remailers) to the remailer hosting his public mailbox to command the remailer to send the contents of his mailbox to one of his other mailboxes. The remailer wouldn't necessarily know it's sending to another mailbox, it's just sends to an address supplied in the command message. Bob repeats this process to move his messages from his second mailbox to his third mailbox, and so on. Eventually, he moves his messages from his Nth mailbox to his "real" address. Is this approximately what you had in mind? I left out IP redirectors and POP clients because I'm not familiar with them. Jim_Miller at suite.com From fringeware at illuminati.io.com Thu Feb 3 20:04:49 1994 From: fringeware at illuminati.io.com (FringeWare List) Date: Thu, 3 Feb 94 20:04:49 PST Subject: CRYPTO - New US keyserver now fully operational - Message-ID: <199402031618.KAA29816@illuminati.IO.COM> Sent from the cyberdeck of: pgpkeys at wasabi.io.com (PGP Slave Key Server) The US-based keyserver 'pgp-public-keys at io.com' is now open to the public. Come one, come all! Here is the current file as returned by 'Subject: help'. This site is a PGP key server SLAVE site. It behaves very similarly to the European PGP master sites, but there are a few small differences which will be noted below. The most noticable difference is that it answers your requests immediately instead of waiting for a daily batch job to run :-) The particular installation at io.com does *not* log the details of requests for keys, however the fact that you have sent mail to the key server at all is logged in the daily sendmail logs. These logs will be erased automatically after one week. PGP Public Keyservers --------------------- There are PGP public key servers which allow one to exchange public keys running through the Internet and UUCP mail systems. This service is NOT supported in any way whatsoever by the schools or organizations on which these servers run. It is here only to help transfer keys between PGP users. It does NOT attempt to guarantee that a key is a valid key; use the signators on a key for that kind of security. This service can be discontinued at any time without prior notification. Each keyserver processes requests in the form of mail messages. The commands for the server are entered on the Subject: line. To: pgp-public-keys at io.com From: johndoe at some.site.edu Subject: help Sending your key to ONE server is enough. After it processes your key, it will forward your add request to other servers automagically. For example, to add your key to the keyserver, or to update your key if it is already there, send a message similar to the following to any server: To: pgp-public-keys at io.com From: johndoe at some.site.edu Subject: add -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 -----END PGP PUBLIC KEY BLOCK----- COMPROMISED KEYS: Create a Key Revocation Certificate (read the PGP docs on how to do that) and mail your key to the server once again, with the ADD command. Valid commands are: Command Message body contains ---------------------- ------------------------------------------------- ADD Your PGP public key (key to add is body of msg) *** Note: your update is forwarded to a master server and may take a few days to reappear INDEX List all PGP keys the server knows about (-kv) VERBOSE INDEX List all PGP keys, verbose format (-kvv) GET Get the whole public key ring GET 0xA1B2C3 Get a single key by Key ID *** Note: the master servers allow you to omit the 0x in front of the Key ID. The slave servers do not. GET userid Get a single key by User ID MGET substr List all keys which match "substr" *** Note: this is different from the master servers which return the keys themselves, not just a listing of their Key IDs. Also the master servers accept a wild-card expression; at the moment we do not. LAST days Get the keys updated in the last `days' days *** Note: not yet implemented ------------------------------------------------------------------------ Examples for the MGET command: MGET michael Lists all keys which have "michael" in them MGET @iastate.edu Lists all keys which contain "@iastate.edu" Check the Usenet newsgroup alt.security.pgp for updates to this system and for new sites. Based on a document originally by Michael From jdblair at nextsrv.cas.muohio.EDU Thu Feb 3 20:14:49 1994 From: jdblair at nextsrv.cas.muohio.EDU (jdblair at nextsrv.cas.muohio.EDU) Date: Thu, 3 Feb 94 20:14:49 PST Subject: Prodigy Hard Drive Scans Message-ID: <9402040414.AA25368@ nextsrv.cas.muohio.EDU > I heard from a friend that Prodigy was scanning user's hard drives. Basically, when you logged on Prodigy made a complete directory of your hard drive and uploaded it. Prodigy was using this to find out what applications you used so they could direct the appropriate advertising towards you. Apparently, they're suffering several lawsuits now because of it. My friend heard this on the trailing end of a radio talk show. If it was really happening, it sounds horrible. Could Secure Drive be set up to stop this kind of attack? Can anyone tell me if this is more than a rumour? If it is more than a rumour, would you be able to point me towards some information about this? -john. jdblair at nextsrv.cas.muohio.edu From tcmay at netcom.com Thu Feb 3 20:39:44 1994 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 3 Feb 94 20:39:44 PST Subject: Prodigy Hard Drive Scans In-Reply-To: <9402040414.AA25368@ nextsrv.cas.muohio.EDU > Message-ID: <199402040436.UAA14470@mail.netcom.com> > I heard from a friend that Prodigy was scanning user's hard drives. > Basically, when you logged on Prodigy made a complete directory of your > hard drive and uploaded it. Prodigy was using this to find out what > applications you used so they could direct the appropriate advertising > towards you. Apparently, they're suffering several lawsuits now because > of it. > > My friend heard this on the trailing end of a radio talk show. If it was > really happening, it sounds horrible. Could Secure Drive be set up to > stop this kind of attack? > > Can anyone tell me if this is more than a rumour? If it is more than a > rumour, would you be able to point me towards some information about this? Just a rumor, disposed of several years ago. A hot topic of debate around 1990. This rumor arose because Prodigy set aside a block of user disk space for its own files. Sometimes this block had random stuff in it (recall that "erasing" a file doesn't actually overwrite the disk, it just removes pointers to the stuff being erased and allows other stuff to later be overwritten over it). Prodigy used part (a small part, given 1200- and 2400-baud modems in use then) of this block to send back to the main computers, so in principle it could see miscellaneous scraps of erased data. But this was accidental, was a tiny fraction of the disk, was not used or even looked at by Prodigy, and would have absolutely no value in determining applications used. (Think about what a samll random chunk of "erased" disk space would really mean in terms of telling outsiders what applications you use!) Ironically, an old college buddy of mine is now in charge of e-mail for Prodigy, in White Plains, New York. He visited me last summer and I showed him a _real_ computer service (Netcom) and we had a few good chortles about this Prodigy Conspiracy. --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. From nobody at shell.portal.com Thu Feb 3 20:59:44 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Thu, 3 Feb 94 20:59:44 PST Subject: New remailer up. Message-ID: <199402040459.UAA04387@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- Jon Boone expressed what seems to be a consensus, " I won't hack into mail.netcom.com to demonstrate that it is possible to figure out who used your remailer. But, if one of the admins from netcom wants to send me their syslogs, I'll do my best to put together a correlation." Netcom logs mail. The mail queue is viewable by most anyone willing to set up a mail queue logging routine. If someone wants to see the mail logs after it is no longer in the mail queue they have to be root on Netcom or illegally hack in. If the FDA wants your illegal smart drugs, they might get Netcom to hand over mail logs. If a hacker or the NSA taps into root, they don't need mail logs; they'll just "wiretap" the qwerty account, including its secret key and pass phrase. Is there any OTHER serious but unrelated problems with a Netcom remailer? Now I know what warnings and hints to put in qwerty's .plan: "Since Netcom keeps mail logs, people should only have contact with qwerty via other remailers or send mail out from qwerty only to public sites like Usenet or a mailing list, so the real addresses of the users never shows up on Netcom's logs or in the mail queue. It is also best to use encryption in case someone is reading the contents instead of just the logs." Routing through qwerty will add another layer of difficulty to someone trying to track down a message sender, since if forces them to get Netcom's sendmail logs after the fact or to make their own logs every day of the year from an account on Netcom. Is this legal for say the FDA to do? How about my new idea for a company called "Netlog!" in which I log the mail queue on Netcom and offer to sell CD ROMs containing a year's mail logs from Netcom? These tricks could be made more difficult with traffic analysis countermeasures. However, the issue seems more touchy than this rationalization for the existance of Netcom remailers. Not assuming qwerty remains in its current state, will adding qwerty to a mailing chain, say between extropia to hfinney at shell, using encryption, add to or decrease security? The question needs to be answered, with the assumption that someone IS collecting mail queue logs. How would you have me alter qwerty so that this link ADDED to the security of a chain? More than an hour delay must be avoided by making the scheme more sophisticated, in my view. If I add a 0-30 min. random delay, with added dummy traffic going out from qwerty in a circle through other remailers and back to qwerty's bit bucket, every few minutes, would this make it useful also to SERIOUS remailer users? Before I start throwing out ideas that I'm sure aren't new to readers here, I have a simple question that perhaps I should post to comp.unix.questions or comp.lang.perl, but.... Can I, and how would I, get a perl script to kick in and send out mail every few minutes when I am NOT logged in. Is this possible on Netcom? The question is pretty general, and involves any public access or personal account machine. So send me a remailer or tell me how to patch Hal's. -Nik (Xenon) -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLVGOgQSzG6zrQn1RAQFGLAP+N31dNMjnArEOklm4AeruT7pu6LgfNdUM OawRDPY8CYgxYi5kJ4yByh7+uD+Asr7FCMaKacln8YwO6oOz3FlceNupC1czWFI5 NWuS9b4r5ZPKpLClv9K3oY1QvRePc1r0Ypl4SYCtZux/7U787BoyT/VUHmkfwple I6X6+irFXns= =6Klu -----END PGP SIGNATURE----- From wcs at anchor.ho.att.com Thu Feb 3 23:04:52 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Thu, 3 Feb 94 23:04:52 PST Subject: Remailer Tearline Conventions Message-ID: <9402040701.AA23632@anchor.ho.att.com> > > That remail at extropia.wimsey.com is in Canada specifically makes > > communications with it fair game for NSA interception, however. > > NSA interception is world wide. On the other hand, extropia uses PGP encrypted messages to its remailer, and NSA PGP-breaking is distinctly *not* world-wide. I assume it doesn't use PGP encryption for the anonymous outgoing side, but you can always encrypt the message before encrypting it for extropia. From wcs at anchor.ho.att.com Thu Feb 3 23:14:52 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Thu, 3 Feb 94 23:14:52 PST Subject: finger user@wasabi.io.com Message-ID: <9402040712.AA23739@anchor.ho.att.com> Neat stuff! You can finger billstewart at wasabi.io.com, even though I don't exactly have an account there... Is the source code available for your finger daemon? It doesn't seem to have any regular-expression matching; it mostly matches exact character strings, presumably case-insensitive. I couldn't figure out how to get it to match spaces, though: requesting 'bill stewart' got all the bills and all the stewarts, rather than getting the lines with bill stewart in them. Thanks! From hfinney at shell.portal.com Thu Feb 3 23:19:44 1994 From: hfinney at shell.portal.com (Hal) Date: Thu, 3 Feb 94 23:19:44 PST Subject: Running regularly Message-ID: <199402040708.XAA17954@jobe.shell.portal.com> > Before I start throwing out ideas that I'm sure aren't new to readers here, > I have a simple question that perhaps I should post to comp.unix.questions > or comp.lang.perl, but.... Can I, and how would I, get a perl script to > kick in and send out mail every few minutes when I am NOT logged in. Is this > possible on Netcom? Most public Unix systems will not let you do this, in my experience. The two Unix commands which usually give you the ability to run programs at regular intervals are "at" and "crontab". You can read the man pages and try running these to see if they are enabled for you. I had an idea for how to get around this, so that people could run batching remailers which sent out mail, say, every 30 minutes or whatever. (Unlike Xenon, I am of a generation which is accustomed to waiting more than a few seconds for mail to travel across the country!) The idea was simply for someone who DID have an account which would let them use at or cron, to run a program which would simply send a "ding" message (not to be confused with a "ping" message :) at regular intervals to a list of subscribers. This message could have a special header field so that the remailer programs could easily recognize it and take whatever action they wanted, like running Karl Barrus' script to scan a directory for pending outgoing remailer mail and send it out. (Karl has had batching running for months, as well as postage-stamp-based remailers (albeit with non-anonymous stamps). He is way ahead of most of this discussion.) Hal From hfinney at shell.portal.com Thu Feb 3 23:24:53 1994 From: hfinney at shell.portal.com (Hal) Date: Thu, 3 Feb 94 23:24:53 PST Subject: contemplating remailer postage Message-ID: <199402040715.XAA18357@jobe.shell.portal.com> As Jim points out, Matthew's scheme for one-bit-per-stamp has the problem that it requires non-anonymous stamps. Jim suggested a variant on Chaum's digital cash where the stamp numbers would be re-blinded by the recipient so that the remailer would not recognize them (but could verify their validity). Matthew's bitmap idea could still be used, though. The incoming stamp numbers could be hashed down to, say, 24 bits. This could then be an index into a 2^24-bit file, which would take 2 MB. Set the bit when the stamp is used, and reject the mail if the bit is already set. Granted, this would create false rejections. But email is already not perfectly reliable. You could send 160,000 messages before you had as many as 1% false rejections (2^24 / 100). I think this would be better than trying to save this many digital stamps and check through the list each time for duplications. Hal From catalyst-remailer at netcom.com Thu Feb 3 23:34:53 1994 From: catalyst-remailer at netcom.com (catalyst-remailer at netcom.com) Date: Thu, 3 Feb 94 23:34:53 PST Subject: Remailer FAQ. Details. Message-ID: <199402040732.XAA02211@mail.netcom.com> I hope I can get a bit more attention to this, now that it has become more sophisticated. Please code warriers, take a break and let the human race know what the existing remailers are all about. I know exactly why they don't have enough traffic; knowledge about them is still insider knowledge. A list of remailer addresses and year-old partial info from a request made my Tim May was all I could find. Specs needed. I will send this to Gary Edstrom for the PGP FAQ if I don't have to spend the rest of my life compiling it. Mail info to qwerty at netcom.com. I'm interested in hearing from users as well as operators. -Nik (Xenon) Xenon's Full Disclosure Remailer List. Remailer Fast? OpLog SysLog Subj Batch RD NL CPU Phys PGP BitB ?what else? --------- ------ ----- ------ ---- ----- -- -- --- ---- --- ---- ----------- bsu-cs + ? ?/? + ? ? ? ? ? 23a ? catalyst + N? SM/MQ - - ? - PA M 23a - choas + ? ?/? + ? ? ? ? ? - - cicada ++ ? ?/? - - - - ? ? - - dis.org - ? ?/? - ? ? ? ? ? 23a ? extropia ? ? ?/? + ? ? ? Pr? ? 23a ? jarthur +/-- St SM/MQ? - ? ? ? Un ? 23a - menudo -- ? ?/? - t1 ? ? ? ? - ? merde -/-- ? ?/? - ? ? ? ? ? - ? penet.fi -- St ?/? - t? 24 + Pr H - - pmantis ++ ? ?/? - ? - - ? ? - - qwerty + C SM/MQ - - - - PA M 23a + rosebud ++/- ? ?/? - - - ? ? ? 23a ? remba ? ? ?/? ? ? ? ? ? ? 23a ? shell ++/+/- St ?/? - ? ? ? ? ? 23a - soda ++/- St+? ?/? - ? ? ? ? ? - Subj: Strips Subject header? NL: Non-linear remailing? 123->231. RD: Random delay added (max, in hours)? Batch: Batched remailing? t2 means twice daily. n5 means after 5 messages. CPU: Pr = private. PA = account on public access machine. Un = university. Phys: Physical security of the CPU, especially at night. H/M/L. BitB: BitBucket feature? Fast?: ++ <5 min + 5-10 min. - ~10-30 min delay -- Pinging isn't practical due to long delays, but may be more secure. +/- Sometimes +, sometimes - Normal internet mail delays are common, and are not equivalent in the two directions between any two remailers. Mail still gets through. OpLog: F: Full copies of all mail is archived. My large volume mailing should help put a stop to this. St: Stats logs of when mail was remailed. St+: Stats logs of when and where mail was remailed. St-: Simple counter. N: Operator keeps no logs. SysLog: SM: sendmail logs of when and where mail was exchanged. Root access. MQ: mailqueue accessible by anyone on the site. Could make logs. bsu-cs nowhere at bsu-cs.bsu.edu catalyst catalyst at netcom.com chaos remailer at chaos.bsu.edu cicada hh at cicada.berkeley.edu dis.org remailer at dis.org extropia remail at extropia.wimsey.com jarthur ebrandt at jarthur.claremont.edu menudo nobody at Menudo.UH.EDU merde remailer at merde.dis.org penet.fi anon.penet.fi pmantis hh at pmantis.berkeley.edu qwerty qwerty at netcom.com rosebud elee7h5 at rosebud.ee.uh.edu shell hfinney at shell.portal.com soda hh at soda.berkeley.edu Discontinued remailers still on some lists out there: phantom at mead.u.washington.edu remail at tamaix.tamu.edu sameer at netcom.com (spelling?) sameer at berkeley.edu (spelling?) cdodhner at indirect.com remailer at entropy.linet.org?? 00x at uclink.berkeley.edu? remail at tamaix.tamu.edu? remailer at entropy.linet.org? Background on each remailer: bsu-cs: Run by Chael Hall. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: History: ?? catalyst: Run by Scott Collins. Machine: personal dial-up account on Netcom. Problems policy: Outgoing address blocking, with proof of ID. Contact catalyst at netcom.com. Software: Customized Hal's ? Security: Netcom keeps sendmail logs, which root at netcom.com can read. Any Netcom user could also compile his own sendmail logs, by constantly logging mail as it arrives and leaves. Comments: History: ?? chaos: Run by ?? Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: Comments: Finger remailer.help at chaos.bsu.edu for info using any remailer. ?? gopher chaos.bsu.edu for a collection of info about Cypherpunks. Comments: History: ?? cicada: Run by Eric Hollander. Machine: ??? Problems policy: ?? Contact ?? Software: ?? Security: Tread lightly. Being "phased out". dis.org: Run by ?? Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: History: ?? extropia: Run by ?? Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: Only accepts PGP remailing. ::/Encrypted:PGP header is optional. Privately owned, in Canada. History: ?? jarthur: Run by Eli Brandt. Machine: Sequent Symmetry. Problems policy: Destination blocking is available w/ sufficient ID. Contact ebrandt at jarthur.claremont.edu. Software: the usual, tweaked for MMDF. Hal's? Security: jarthur keeps sendmail logs. Comments: History: Set up late '92. PGP added mid-'93. menudo: Run by ?? Maching: ?? Problems policy: ?? Contact ?? Software: ?? Security: Stores messages and sends them at midnight?? Comments: History: ?? merde: Run by ?? Maching: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: History: ?? penet.fi: Run by Julf (last name?) Machine: ?? Operator owned. Problems policy: Account revokation. Contact ??@anon.penet.fi. Software: custom. Security: Comments: By far the most popular remailer, dwarfing in a day what the entire Cypherpunk remailers combined carry in a month. Supports easy return addresses as well as non-anonymous mailing to someone's anonymous address (na1234... instead of an1234...). Your real address is kept on Julf's hard disk, but is fairly safe there, especially if you do not abuse your anonymity to harass someone. On a bad day your mail and especially Usenet posts may be delayed up to two days. Very reliable though. Sends error messages back to you for failed mail. Limited to 48K mail. History: ?? pmantis: Run by Eric Hollander. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: Tread lightly. Being "phased out". Comments: History: ?? qwerty: Run by Xenon. Machine: dial-up account on Netcom. Problems policy: "What problems?". Contact qwerty at netcom.com. Software: Hal's remailer. Security: Netcom keeps sendmail logs, which root at netcom.com can read. Any Netcom user could also compile his own sendmail logs, by constantly logging mil as it arrives and leaves. Comments: You must use na1234 at anon.penet.fi not an1234 at anon.penet.fi. Finger qwerty at netcom.com for a blurb on the remailer and updates on its software. Request-Remailing-To: /dev/null is a bit bucket. whitehouse.gov gets blocked and fully logged. History: Up 2/94. Set up by Xenon who needed more remailers to use to send PGP info to people with, since anon.penet.fi was overloaded. rembe: Run by ? Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: ?? History: ?? rosebud: Run by Karl Barrus. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: History: ?? shell: Run by Hal Finney. Machine: ?? Problems policy: ?? Contact ?? Software: Hal's Remailer. Security: ?? Comments: whitehouse.gov blocked and fully logged. hal at alumni.caltech.edu forwards all mail to shell. History: ?? soda: Run by Eric Hollander. Run by: ?? Machine: ?? Problems policy: ?? Blocking of addresses. Mail sent to problem causer. Contact ?? Software: custom. ?? Security: ?? Comments: History: ?? Remailer Public Keys: (I've got these...) From jkreznar at ininx.com Fri Feb 4 00:44:53 1994 From: jkreznar at ininx.com (John E. Kreznar) Date: Fri, 4 Feb 94 00:44:53 PST Subject: New remailer up In-Reply-To: <199402030311.TAA14987@mail.netcom.com> Message-ID: <9402040838.AA06813@ininx> -----BEGIN PGP SIGNED MESSAGE----- > Julf's anon.penet.fi remailer is serious; he's done a lot of work > to get a private machine, payng for a reasonably expensive > 64kbps line himself, and has it located somewhere that only 3 people know. How can this be? What about the people who operate his connection point to the net? Wouldn't they know where his machine is located? What is the physical embodiment of his 64kbps line? Can't that line be traced to its terminus? John E. Kreznar | Relations among people to be by jkreznar at ininx.com | mutual consent, or not at all. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVIJS8Dhz44ugybJAQHzdAP+JXuFhoq8mksb733rTgfLQJMVZrLzZsjI qxRd+ijfS7EjqELajoNivY+gOjvjJ6V1LpXhTTnC+1Zkcaf6C7JK+qgLuH3GbrQp XkWMeuoIxw3ThyVAYF6mFqPQ5ARAda+HckMeTRS/Cm3Nl2p6LK8s2c1lxbXWg/Dl C5ZLsqF6dWY= =UlVb -----END PGP SIGNATURE----- From mech at eff.org Fri Feb 4 01:54:53 1994 From: mech at eff.org (Stanton McCandlish) Date: Fri, 4 Feb 94 01:54:53 PST Subject: info on local/regional groups & sublists Message-ID: <199402040948.EAA19495@eff.org> For my OUTPOSTS list/FAQ, if you have any (public) inforation about local cypherpunks groups and sublists, like the Austin lists, or the UK branch, please let me know via personal email. Need to put out a new version of the FAQ soon, and am missing much info. All I have so far is: Main general: hughes at soda.berkeley.edu Main subscribe requests: cypherpunks-request at toad.com Main FTP: soda.berkeley.edu, pub/cypherpunks Hardware general: jdblair at nextsrv.cas.muohio.edu Hardware requests: cp-hardware-request at nextsrv.cas.muohio.edu Wonks general: cypherwonks-owner at lassie.eunet.fi Wonks requests: majordomo at lists.eunet.fi (message body of: subscribe cypherwonks [1st & last name] [address]) Austin general: Jim McCoy Doug Barnes Austin req. austin-cypherpunks-request at bongo.cc.utexas.edu austin-cypherpunks-announce-request at bongo.cc.utexas.edu Austin FTP: ftp.cc.utexas.edu, pub/cypherpunks Any info on other CP groups, corrections to what little I have, pointers to other CP file sites, gopher/WWW/Wais servers, etc. all appreciated. Even some BBS number, snailmail addresses for any local groups that are getting less virtually, more physically organized, etc. That, and relevant other lists (anything that might be consider "online activist" or civil libertarian in nature) and resources. Again, please send via email to mech at eff.org rather than on the list. Muchas gracias in advance! -- 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 boone at psc.edu Fri Feb 4 05:05:03 1994 From: boone at psc.edu (Jon 'Iain' Boone) Date: Fri, 4 Feb 94 05:05:03 PST Subject: ADMIN: list statistics In-Reply-To: <9402032319.AA20066@ah.com> Message-ID: <9402041301.AA04130@igi.psc.edu> hughes at ah.com (Eric Hughes) writes: > > 1 si ( ? Slovenia ? ) Yep, this is correct. > 1 ee ? This is estonia. Jon Boone | PSC Networking | boone at psc.edu | (412) 268-6959 | PGP Key # B75699 PGP Public Key fingerprint = 23 59 EC 91 47 A6 E3 92 9E A8 96 6A D9 27 C9 6C From CCVARGA at delphi.com Fri Feb 4 05:55:03 1994 From: CCVARGA at delphi.com (CCVARGA at delphi.com) Date: Fri, 4 Feb 94 05:55:03 PST Subject: CONTENT AND QUALITY NET DISCUSSION. Message-ID: <01H8HCEZOUGI91W5VO@delphi.com> GENTLEMEN, MOST OF MEANINGFUL DISCUSSION ON THE NET HAVE BEEN BOTH WELL THOUGHT AND INTELLECTUALLY "NON'TRIVIAL". THE REMAILING OF MULTIPLE COPIES OF HIGH NOISE INFORMATION DRIBBLE WOULD CAUSE ME TO LOOK AT THE TRAFFIC ON THE NET AND AS : IS IT WORTH IT? RIGHT NOW, THE NUMBER OF UNSUBSCRIBE MESSAGES LEADS ME TO BELIEVE THAT IT IS NOT. IF THIS IS WHAT TOAD WANTS, SO BE IT. IF THERE IS AN INDIVIDUAL AMONG YOU THAT WOULD LIKE TO MAKE A CASE FOR CONTINUED SUBSCRIPTION, I WOULD REALLY APPRECIATE SERIOUS REPLY'S. CCVARGA at DELPHI.COM From jwc00 at cas.org Fri Feb 4 06:15:06 1994 From: jwc00 at cas.org (Jim Cooper jwc00@cas.org; 614-447-3600 ext 3581) Date: Fri, 4 Feb 94 06:15:06 PST Subject: Subscribe Message-ID: <9402040913.AA4494@cas.org> Subscribe cypherpunks Jim Cooper From davidm at smtplink.chey.com Fri Feb 4 06:49:50 1994 From: davidm at smtplink.chey.com (David Michel) Date: Fri, 4 Feb 94 06:49:50 PST Subject: Prodigy Hard Drive Scans Message-ID: <9402040948.A03416@smtplink.chey.com> Prodigy durring installation sets up a temp/swap file on your hard disk. Now this part is a funtion of DOS, Delete a file and all the data is there just the FAT entry is gone. So what ever is on the disk at the location of the temp/swap file is what can be seen at the prodigy end. davidm at chey.com From dmandl at lehman.com Fri Feb 4 06:50:04 1994 From: dmandl at lehman.com (David Mandl) Date: Fri, 4 Feb 94 06:50:04 PST Subject: CONTENT AND QUALITY NET DISCUSSION. Message-ID: <9402041446.AA05230@disvnm2.lehman.com> > From: CCVARGA at delphi.com > > GENTLEMEN, MOST OF MEANINGFUL DISCUSSION ON THE NET HAVE BEEN BOTH > WELL THOUGHT AND INTELLECTUALLY "NON'TRIVIAL". THE REMAILING OF > MULTIPLE COPIES OF HIGH NOISE INFORMATION DRIBBLE WOULD CAUSE ME TO > LOOK AT THE TRAFFIC ON THE NET AND AS : IS IT WORTH IT? > RIGHT NOW, THE NUMBER OF UNSUBSCRIBE MESSAGES LEADS ME TO BELIEVE > THAT IT IS NOT. IF THIS IS WHAT TOAD WANTS, SO BE IT. IF THERE IS > AN INDIVIDUAL AMONG YOU THAT WOULD LIKE TO MAKE A CASE FOR > CONTINUED SUBSCRIPTION, I WOULD REALLY APPRECIATE SERIOUS REPLY'S. > CCVARGA at DELPHI.COM So--another noisemaker complaining about noise on the list. Why don't you decide for yourself whether it's worth continuing your subscription? Would you actually base your decision on the number of people who tell you that it's worth continuing? If you're new to the list, why don't you stick around for a while and see what you think? If not, you're probably fully capable of deciding for yourself now whether this is the place for you. Related issue: The number of people unsubscribing because of excessive noise who are so rude and clueless as to post their unsubscribe requests to the entire list (thereby increasing noise) is really getting to me. Almost no tangential or "off-topic" thread pollutes this list as much as unsubscribe requests that everyone has to read. The cypherpunks welcome message clearly states that unsubscribe messages should be sent to cypherpunks-request at toad.com. Simple. Again, the list administrator is a human being, not a machine, so those requests may take a couple of days to process. Big deal. Losing your patience and whining to the list is as useful as pushing the elevator call button a hundred times, and has the added disadvantage of getting hundreds of people really angry. It also makes you look like a clueless newbie. I usually send these messages to individuals, not the whole list, but it seems that there's been an increase in unsubs sent to all of us. Again, folks, if you want to unsubscribe (which I'm not encouraging you to do), it's cypherpunks-request at toad.com --Dave. From SERPE at morgan.com Fri Feb 4 06:59:52 1994 From: SERPE at morgan.com (SERPE at morgan.com) Date: Fri, 4 Feb 94 06:59:52 PST Subject: unsubscribe Message-ID: <94Feb4.095752est.41748@gateway.morgan.com> please unsubscribe me. Thanks and good luck!! From sdw at meaddata.com Fri Feb 4 07:09:50 1994 From: sdw at meaddata.com (Stephen Williams) Date: Fri, 4 Feb 94 07:09:50 PST Subject: New remailer up In-Reply-To: <9402040838.AA06813@ininx> Message-ID: <9402041508.AA18037@jungle.meaddata.com> > > -----BEGIN PGP SIGNED MESSAGE----- > > > Julf's anon.penet.fi remailer is serious; he's done a lot of work > > to get a private machine, payng for a reasonably expensive > > 64kbps line himself, and has it located somewhere that only 3 people know. > > How can this be? What about the people who operate his connection point > to the net? Wouldn't they know where his machine is located? What is > the physical embodiment of his 64kbps line? Can't that line be traced > to its terminus? That started me down an interesting line of thought... You can get spread spectrum radio/data modems that do 256Kbits/sec (Cylink) and can go up to 30 Miles. It is unlicensed in the US because it is limited to .8watts (I think). I believe 10 miles is the limit with an omnidirectional antenna. Spread spectrum should be pretty hard to triangulate on. Remember that the technology came from unjammable military radios. I think you'd have to have a fairly sophisticated scanner to even pick it up. Using a creative arrangement, this could provide a good cover for physical location. (If you could get the server in the back of a city bus or something...) > John E. Kreznar | Relations among people to be by > jkreznar at ininx.com | mutual consent, or not at all. 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 matthew at gandalf.rutgers.edu Fri Feb 4 07:45:06 1994 From: matthew at gandalf.rutgers.edu (Matthew Bernardini) Date: Fri, 4 Feb 94 07:45:06 PST Subject: Running regularly Message-ID: > > Before I start throwing out ideas that I'm sure aren't new to readers here, > > I have a simple question that perhaps I should post to comp.unix.questions > > or comp.lang.perl, but.... Can I, and how would I, get a perl script to > > kick in and send out mail every few minutes when I am NOT logged in. Is this > > possible on Netcom? > > Most public Unix systems will not let you do this, in my experience. > The two Unix commands which usually give you the ability to run programs > at regular intervals are "at" and "crontab". You can read the man pages > and try running these to see if they are enabled for you. > > I had an idea for how to get around this, so that people could run batching > remailers which sent out mail, say, every 30 minutes or whatever. (Unlike > Xenon, I am of a generation which is accustomed to waiting more than a few > seconds for mail to travel across the country!) The idea was simply for > someone who DID have an account which would let them use at or cron, to > run a program which would simply send a "ding" message (not to be confused > with a "ping" message :) at regular intervals to a list of subscribers. > This message could have a special header field so that the remailer programs > could easily recognize it and take whatever action they wanted, like running > Karl Barrus' script to scan a directory for pending outgoing remailer mail > and send it out. (Karl has had batching running for months, as well as > postage-stamp-based remailers (albeit with non-anonymous stamps). He is > way ahead of most of this discussion.) > > Hal > > Perhaps this is too rudimentary ..... Why not make two shell scripts, one that sleeps for so long (say 20 minutes) using the unix sleep command, and then calls the remailer scripts in an infinite while loop. This would work if you set it up as a background process,and you don't need to be root for it to work. Only downsides are that when the machine crashes you have to log back in and restart script, your sleep command will always be in the top window if your sys-admin is watching, and you have to be careful not to spawn to many processes and bring the system down. Matt From mech at eff.org Fri Feb 4 07:49:50 1994 From: mech at eff.org (Stanton McCandlish) Date: Fri, 4 Feb 94 07:49:50 PST Subject: White House crypto briefings: Clipper, FIPS, escrow agents, export Message-ID: <199402041548.KAA22031@eff.org> Briefings on Federal Encryption Policy/Telecommunications Security Today (Feb 4), the Administration will hold 2 briefings about cryptography and the Clipper chip. The briefings will "report on a review of federal policies and procedures for encryption and telecommunications security-related products and technologies." The first briefing, at 11am EST (i.e., in less that half an hour of this posting), will update Congressional committee staff, and the second will address concerns of industry reps, public interest groups, privacy advocates and other non-government parties. EFF will attend this second meeting, at 1pm EST. EFF will share what it learns about the results of either briefing as soon as possible. An early "heads up" from the the Administration indicates that the main subjects for the briefings will be: Administration will announce Clipper/Skipjack Federal Information Processing Standard (FIPS) Justice Dept. key escrow procedures to be announced Announcement of Treasury and NIST as Escrow Agents Decisions on encrytion products that fit under current export standards announced. Other topics also likely to be addressed (unconfirmed): State Dept. will, surprisingly, streamline procedures for export of Clipper Administration not going forward with DSS licensing agreement with PKP/RSADSI. -- 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 rondavis at datawatch.com Fri Feb 4 08:15:07 1994 From: rondavis at datawatch.com (Ron Davis) Date: Fri, 4 Feb 94 08:15:07 PST Subject: d3des code question Message-ID: <9402041113.aa05790@gateway.datawatch.com> Has anyone had any experience using the DES code by Richard Outerbridge that appears in the back of Applied Crypto, and is available via ftp from ripem.msu.edu? Specifically can someone send me an example of how to call the functions? Thanks. ___________________________________________________________________________ "I want to know God's thoughts...the rest are details." -- Albert Einstein _________________________________________ Ron Davis rondavis at datawatch.com Datawatch, Research Triangle Park, NC (919)549-0711 From schneier at chinet.com Fri Feb 4 08:45:09 1994 From: schneier at chinet.com (Bruce Schneier) Date: Fri, 4 Feb 94 08:45:09 PST Subject: Review of APPLIED CRYPTOGRAPHY in Cryptologia Message-ID: The following review of APPLIED CRYPTOGRAPHY appeared in the January 1994 issue of Cryptologia (v. 18, n. 1). Written by Louis Kruh. The past twenty years have seen an explosive growth in public research into cryptology, accompanied by an unprecedented public awareness of matters cryptologic. Programmers and engineers trying to benefit from the fruits of this research, to solve real-world problems, have often been stymied by not knowing where to start looking, let alone when to stop. This book is for them. Written as a "comprehensive reference work for modern cryptology" the book succeeds both as an encyclopedia survey of the past twenty hears of public research and as a hansom "how-to" cookbook of the state-of-the-art. It could well have been subtitled "The Joy of Encrypting." The author's style is colloquial and informal, but never imprecise. Theory takes a back seat to clarity and directness, without deliberate misrepresentation; unabashed informed opinion wins out over academic hesitations. Since the work is a practical snapshot of the field, circa mid-to- late 1993, several of the book's recommendations may prove timely: new results seem to be reported monthly. While his political axe is never concealed the book is written as a whetstone for others rather than a soapbox rant, and the focus is manifestly practical solutions and the tools with which to achieve them. After a forward from Whitfield Diffie the author explains foundations; examined protocols; discusses techniques; presents algorithms; explores the real world (including legal and political aspects); and finishes up by printing read-to-run C source code programs of several of the algorithms, including ENIGMA, DES and IDEA. Reflecting the confused nature of the real world, a set of IBM PC disks containing the sources published in the book is available from the author--but only to residents of the USA and Canada. Drawing on 908 references and the collected experience of contributors throughout the Internet and around the world, this book will be a useful addition to the library of any active or wouldbe security practitioner. It's the first review of the book that has appeared in print, and I am very pleased with it. The book has turned out to fill two very different niches. One, it is the book that people are being handed to read when they want to learn about the field. Two, it is the reference work that people are turning to first if they want to find out about some aspect of cryptography. The third important niche, which the book does not fill, is that of a textbook. This field sorely needs a textbook. Anyone interested? Bruce From qwerty-remailer at netcom.com Fri Feb 4 09:25:09 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Fri, 4 Feb 94 09:25:09 PST Subject: New remailer up. Message-ID: <199402041723.JAA29445@mail.netcom.com> >Before I start throwing out ideas that I'm sure aren't new to readers here, >I have a simple question that perhaps I should post to comp.unix.questions >or comp.lang.perl, but.... Can I, and how would I, get a perl script to >kick in and send out mail every few minutes when I am NOT logged in. Is this >possible on Netcom? Rather than try to run in some asynchronous mode as you suggest, why not do the following when each message arrives: place message in your queue, designating random hold time foreach message in the queue that's been held long enough send random number (1<=n<=3) dummy messages send the queued message send random number (1<=n<=5) dummy messages The whole thing remains data-driven while you're not logged in and can be manually flushed if you are logged in. So long as there is a steady stream of traffic, messages won't get stalled for long times. You could even send some 'activation' messages at controlled intervals from some comfortable site (where you can use cron), routed via another remailer. Just some ideas off the top of my head. From richardr at netcom.com Fri Feb 4 09:39:48 1994 From: richardr at netcom.com (Richard L. Robertson) Date: Fri, 4 Feb 94 09:39:48 PST Subject: Practical Pencil & Paper Encryption (computerizable) Message-ID: <199402041738.JAA19453@mail.netcom.com> Bruce Schneier in Message-ID: Date: Wed, 13 Oct 1993 05:04:13 GMT Subject: Pencil and paper encryption algorithm proposed a pencil-and-paper encryption algorithm that could be used without computers, but was still secure against computer-aided attacks. I answered with what I felt were several practical usage problems with his proposed methodology that made it infeasible to reliably encrypt and decrypt messages in a finite time. During a much needed vacation from the practical realities of work and life, I have attempted to come up with a simplified message encryption algorithm that meets Bruce's criteria and is practical in use. I took as design constraints that an inexpensive (< $30) pocket calculator was acceptable for performing any necessary calculations, but that something as big and complex as an HP-48 or an Apple Newton was unacceptable. I also changed the requirement from "secure against computer-aided attacks" to "highly resistant against computer aided attacks". My first attempt used a simple, multiple memory, non-programmable Radio Shack checkbook pocket calculator. While the methodology met the "resistance" criterion, it failed the practical test of error- free calculation in a finite time. It turned out to be possible to get reliable encryption and decryption by applying the result cross-checking techniques used in hand pencil-and-paper calculation, however the time required for error-free encryption was exorbitant. By relaxing the design constraints to allow limited programmability in the pocket calculator, I was able to adequately address the problem of speed of error-free encryption calculations. The constraint that I adopted was that the calculator's program steps must be simple and compact enough for the user to be able to memorize and to be able to re-enter the program into the calculator each time that it was used to encrypt or decrypt a message. I believe that this satisfies the reasonable requirement that there be no incriminating evidence left lying around in the calculator between encryption sessions. The following encryption procedure was tested using an $18 Radio Shack Model EC-4021 programmable scientific calculator. The algorithms were modified as necessary to conform to the practical limitations of the calculator keypad and limited programming capabilities. With only moderate training time (a couple of hours) I was able to reliably encrypt and decrypt messages at a rate of 8-10 characters per minute. The primary speed limitation was the actual tran- scription on the results by pencil onto paper. I would appreciate any and all comments, criticisms, error corrections and suggestions for improvements. Richard Robertson richardr at netcom.com ------------------------------------------------------------ A "Pencil and Paper" Encryption Algorithm for Pocket Calculators Copyright 1993 Richard L. Robertson Contents A: Encryption Confusion Generators B: Substitution Cipher Technique C: Transposition Cipher Technique D: Encryption Key Management E: Cryptographic Hardness F: Message Encryption Example G: Sample Message Key Generation A: Encryption Confusion Generators The core confusion generator chosen is a variation on the non- linear equation Logistic Difference Equation (LDE). This is selected for its adequate PRNG properties and its simplicity of calculation. The standard basic LDE can be written as X[n+1] = R * X[n] * (1 - X[n]) where R = 4, and 0 < X[n] < 1 While the output of the LDE has reasonable unpredictability, this basic formulation has limited cryptographic usefulness, partly because of limited sequence length and partly because the seed can be derived with sufficient information about successive values, even if "jitterized" (as described by Terry Ritter). By revising the constraints slightly to 3.99 < R < 4.0 the resulting output is "sub-chaotic" but still has very good PRNG properties. Another advantage of using R < 4.0 is that rounding errors in calculations do not cause any numerical values that result in the PRNG sequence degenerating from calculation errors. Extensive numerical trials on a 486 PC with 15-digit (decimal) floating point calculations have not uncovered any values of R or X[n] that result in short or degenerate PRNG sequences. The average length of a pseudo-random sequence from a (modified) LDE is a function of the number of digits of precision used in the calculations. For 9-digit fractional numbers, the expected length of a pseudo-random sequence is ~ 3 * 10^4 and there are ~ 3 * 10^4 independent sequences. The sequence length is adequate for pencil and paper encryption since messages would rarely exceed 200 characters. To develop a reasonably secure cryptographic methodology using the modified LDE as the confusion generator, proceed as follows: 1 - Select two non-linear (LDE) confusion generators G1 = R * X * (1 - X), and G2 = R'* Y* (1 - Y) where R' = 0.999 * R (used because of limitations in the number of memory registers in the pocket calculator) 2 - The cryptographic key (or seed) consists of the values R, X[0] and Y[0], where 0 < X[0] < 1 is a 9-digit key 0 < Y[0] < 1 is a 9-digit key 3.99 < R < 4.0 is a 7-digit key The total key length is 25 digits, giving a key space size of 10^25. The keys are short enough to be easily memorized. (If you are not convinced of this assertion, consider how many phone numbers, PIN numbers, bank account numbers, etc that the average person routinely commits to memory) 3 - Select a non-linear combiner for the output of two confusion generators. This is the first level of serious cryptographic strength. We will chose the function K = G1 <*> G2 where <*> is the floating point multiplication operator with rounding (see Knuth, Seminumerical Algorithms for details). At little inspection will show that it is not possible to recover the values G1 and G2 from a given K because K is not uniquely factorable. The rounding performed during the multiplication discards information necessary for factoring. In fact, for any 0 < K < 1, *all* values of G1 > K are valid factors of K. Rephrased, for any K {0 < K < 1} and for any p {1 > p > K, there exists at least one q {1 > q > K} such that K = p <*> q. Note: Because of rounding, numbers of the form K = (1/b)^n (where b is the base) are the only exceptions to this statement. For K = (1/b)^n, q = 1-(1/b)^n is not a factor of K. Recovering a sequence of G1 and G2 values from a sequence of K values, and from that recovering the cryptographic keys R, X[0] and Y[0], requires solving a series of simultaneous non- linear high-order polynomial equations. I am not aware of any practical way to do this in the literature. Brute force recovery of the sequence of n-digit G1 and G2 values requires checking a minimum of 10^(n*3) n-tuples {G1,G2,G'1,G'2,G''1,G''2} to determine which are possible solutions for the generator functions G1 and G2. 4 - Choose a domain transformation from quasi-continuous floating point to the finite to select digits from K to use for data encryption. This is the second level of serious cryptographic strength. Choose any algorithm for selecting a cipher value K' of either 1 or 2 digits from "around the middle" of the value K to use for performing the encryption. Because the confusion generators G1 and G2 are independent and have reasonably uniform digit distributions, the nonlinear combination K = G1 <*> G2 also has a reasonably uniform digit distribution. For any particular 1-digit value K', there are 10^8 possible values of K that could have generated it. For any particular 2-digit value K', there are 10^7 possible corresponding values for K. 5a - Use the sequence {K'} as the key for a Vigenere cipher 5b - Use the sequence {K'} to control a pseudo-random transposition cipher. 5c - Combine (5a) and (5b). Use (5a) to "bit-level" the message text, then use (5b) to superencipher the output of (5a). This would require two complete encryption steps and is probably too labor and time intensive to be worth while for pencil and paper encryption. In summary, the steps for calculating the encryption sequence K' are as follows: X [n+1] = R * X[n] * (1 - X[n]) Y [n+1] = .999 * R * Y[n] * (1 - Y[n]) K [n+1] = X[n+1] * Y[n+1] K'[n+1] = 1 or 2 low-order digits of int (10^5 * K[n+1]) B: Substitution Cipher Technique In this system, the key consists of a series {K'} of 2-digit values that is as long as the message. These are added to the plaintext message characters modulo 100, considered the alphabet as numbered from Sp=00, A=01 to Z=26, etc. This is your basic Vigenere cipher with the cipher key as long as the message. Decryption performs the same series of steps on the ciphertext message characters except that subtraction modulo 100 is used. Given that the K' form an unpredictable sequence, this is equivalent to a one-time pad Vernam cipher where the one-time pad does not have to be transmitted to the receiver. The message recipient can regenerate the series {K'} from knowledge of the cipher key . The only problems that need to be addressed are the resistance of the sequence {K'} to computer-assisted attack and how to manage the necessary set of secret keys {}, since one key-tuple is consumed by each message. In summary, the steps for encrypting a message M are as follows: compute K[n] as described above C[n] = 2 low-order digits of int (10^5 * K[n]) + M[n] where M[n] is the nth plaintext character, and C[n] is the nth ciphertext character and the steps for decrypting a ciphertext C are as follows: compute K[n] as described above M[n] = 2 low-order digits of int (100001 - (10^5 * K[n]) + C[n]) where M[n] is the nth plaintext character, and C[n] is the nth ciphertext character C: Transposition Cipher Technique In this system, the key consists of a series {K'} of 1-digit values that is longer than the message. 1 - Write down the plaintext message into blocks of length 10 (because the calculator operates in decimal mode). Repeat the message at least once because the algorithm will encipher more characters than are in the message. The exact number of excess characters enciphered is random but bounded. If the message text is: "Now is the time for all good men to come to the aid of their party." then this is written in blocks of 10 as: 1234567890 |Now is the| | time for | |all good m| |en to come| | to the ai| |d of their| | party.Now| | is the ti| |me for all| Repeat the message text as required. 2 - Calculate the sequence of 1-digit numbers {K'} 3 - For each value K', select and output the next unused character in column K'. Mark the selected character as used. 4 - Repeat this process until all characters in the base message have been transmitted. Decryption proceeds as follows: 1 - Calculate the sequence of 1-digit numbers {K'} 2 - Get the next ciphertext character and place it in the next available column K' 3 - Repeat this process for all ciphertext characters. 4 - The row in which that last character is placed is the last row of the message. Discard any rows following that row because they are just random padding added by the encryption algorithm. Transposition ciphers are substantially harder to attack than substitution ciphers and normally require a lot of hand work. Normally they are attacked by anagramming when there is some knowledge of the expected message contents. I would assert, based on a moderate literature search, that this pseudo-random transposition has no known effective methods for attack because there are no fixed column boundaries and character positions are pseudo-random. If the cryptographic key is changed with each message there should be no way short of brute force anagramming or a brute force key space search to break this cipher because the cryptographic cipher values are never exposed for cryptanalysis. D: Key Management To make the subsitution cipher encryption useful the key must be changed with each message because it is a one-time pad method. The encryption method has already addressed and eliminated the need for the sender to transmit a copy of the OTP to the receiver by having the receiver independently recreated the OTP used to encrypt the message. While having a separate, unique encryption key for each message is less important for the transposition cipher, it does strengthen the cipher against any attack if the key can be easily changed for each message. In order to not have to transmit each key used to generate the OTP for each message to the receiver, a technique must be developed that provides a similar facility. If this can be accomplished, then the only secret that the sender and receiver must share is a single, small master key. Sharing a small amount of secret information is a fairly easy problem to solve in practice. Inspection of the method for generating the encryption confus*ion sequence shows a way to accomplish the desired key management. Consider the sequence of values {K[i]}. It is obvious from the earlier discussion that there are only two ways to be able to predict subsequent values K[n+1] from the series of values {K[1] ... K[n]}: - obtain the generating seeds for G1 and G2 by brute force examining sets of possible values {G1[i],G2[i]} obtained by factoring {K[i]}. This would require examining at least ~ 10^24 (2^80) possible sets {G1[i],G2[i]} and as such is not feasible with current computing technology. - obtain the generating seeds for G1 and G2 by solving a set of simultaneous high-order nonlinear system of equations. This is an extremely hard problem that is not (as far as my literature search has taken me) amenable to solution at this time. In order to make the problem slightly harder for the crypt- analyst, the key generation algorithm chosen will not use the sequence {K[i]} directly so as not to expose the actual values K[n], but will use K[n] as a starting point for another nonlinear combiner. Again, the algorithms have been adjusted to compensate for the limitations of the pocket calculator. To generate a cryptographically (reasonably) secure sequence of encryption keys using the modified LDE as the confusion generator, proceed as follows: 1 - Select two non-linear (LDE) confusion generators G1 = R * X * (1 - X), and G2 = R'* Y* (1 - Y) where R' = 0.999 * R (used because of limitations in the number of memory registers in the pocket calculator) 2 - The master cryptographic key (or seed) consists of the values R, X[0] and Y[0], where 0 < X[0] < 1 is a 9-digit key 0 < Y[0] < 1 is a 9-digit key 3.99 < R < 4.0 is a 7-digit key The total key length is 25 digits, giving a key space size of 10^25. The keys are short enough to be easily memorized. (If you are not convinced of this assertion, consider how many phone numbers, PIN numbers, bank account numbers, etc that the average person routinely commits to memory) 3 - Select a non-linear combiner for the output of two confusion generators. This is the first level of serious cryptographic strength. We will chose the function K = G1 <*> G2 where <*> is the floating point multiplication operator with rounding (see Knuth, Seminumerical Algorithms for details). 4 - To generate the Nth message key iterate the basic sequence generator N times. Then use the values K[N] ... to alter the generator parameters R, X and Y as follows: R <- 3.99 + (K[n]/100) X <- K'[n+1] where K'[i] <> K[i] because the generating parameters are different Y <- K'[n+2] R <- 3,99 + (K'(n+3)/100) 5 - The final resulting values become the cryptographic key for the Nth message being encrypted or decrypted and are used as described above for message encryption and decryption. Only the value N must be transmitted with the message, not the values of the message key , because the receiver can recreate the message key from N and the master key shared by the sender and receiver. The only additional requirement for security is that no key be reused. This is easy to implement by having the sender number the messages as they are encrypted. The receiver verifies that a message is valid by rejected any message where the message number N is less than the message number of the last message received. This will prevent replay attacks in the event that an opponent obtains a message key. In summary, the steps for calculating the encryption key for the Nth message are as follows: Repeat N times: X [i+1] = R * X[i] * (1 - X[i]) Y [i+1] = .999 * R * Y[i] * (1 - Y[i]) K [i+1] = X[i+1] * Y[i+1] {end repeat} R <- 3.99 + (K[N]/100) calculate K[N+1] X <- K'[N+1] calculate K'[N+2] Y <- K'[N+2] calculate K'[N+3] R <- 3.99 + (K'[N+3]/100) The message encryption key conists of the values at the conclusion of this calculation. E: Cryptographic Hardness Key space searches: The key space size is ~ 10^25 (~ 2^80), which is too large for brute force search with currently available computing resources. Because the key values are random 9-digit numbers there is no possible dictionary attack. Known Plaintext: A known plaintext attack will immediately give the cipher sequence {K'}. However, an absolute minimum of 3 sequential values of the sequence {K} are needed to derive the encryption key . For the 2-digit sequence {K'} used in the substitution cipher, this requires checking the validity of the encryption keys derived from the (at least) 10^21 (2^70) possible triples {K1,K2,K3}. This is well beyond current computational capabilities. Since each key is used only once, possession of the key for one message does not give the opponent any direct value in a known plaintext attack. To determine the key for subsequent messages, at least 3 successive keys must be accumulated in order for the cryptanalyst to attack the key management. Chosen Plaintext: No advantage over known plaintext. Key Management: Same problems (or worse) for the cryptanalyst as aKnown Plaintext attack. Differential Cryptanalysis: I don't see that this is applicable because the key changes with each message. F: Message Encryption Example: Sample message to be enciphered "Now is the time for all good men to come to the aid of their party." Message buffer is padded with repeats of the message, but it would be better to pad with randomly chosen text. The encryption calculations were performed on a Radio Shack Model EC-4021 programmable scientific calculator. Image of Message Text Buffer ========================================= : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 : ========================================= 0 | N | O | W | | I | S | | T | H | E | +---+---+---+---+---+---+---+---+---+---+ 1 | | T | I | M | E | | F | O | R | | +---+---+---+---+---+---+---+---+---+---+ 2 | A | L | L | | G | O | O | D | | M | +---+---+---+---+---+---+---+---+---+---+ 3 | E | N | | T | O | | C | O | M | E | +---+---+---+---+---+---+---+---+---+---+ 4 | | T | O | | T | H | E | | A | I | +---+---+---+---+---+---+---+---+---+---+ 5 | D | | O | F | | T | H | E | I | R | +---+---+---+---+---+---+---+---+---+---+ | | P | A | R | T | Y | . | N | O | W | <- Message ends at ========================================= this line 7 | | I | S | | T | H | E | | T | I | +---+---+---+---+---+---+---+---+---+---+ Buffer is loaded with 8 | M | E | | F | O | R | | A | L | L | repeated copies of the +---+---+---+---+---+---+---+---+---+---+ message text 9 | | G | O | O | D | | M | E | N | | +---+---+---+---+---+---+---+---+---+---+ 10 | T | O | | C | O | M | E | | T | O | +---+---+---+---+---+---+---+---+---+---+ 11 | | T | H | E | | A | I | D | | O | +---+---+---+---+---+---+---+---+---+---+ 12 | F | | T | H | E | I | R | | P | A | +---+---+---+---+---+---+---+---+---+---+ 13 | R | T | Y | . | N | O | W | | I | S | +---+---+---+---+---+---+---+---+---+---+ 14 | | T | H | E | | T | I | M | E | | +---+---+---+---+---+---+---+---+---+---+ 15 | F | O | R | | A | L | L | | G | O | +---+---+---+---+---+---+---+---+---+---+ 16 | O | D | | M | E | N | | T | O | | +---+---+---+---+---+---+---+---+---+---+ 17 | C | O | M | E | | T | O | | T | H | +---+---+---+---+---+---+---+---+---+---+ 18 | E | | A | I | D | | O | F | | T | +---+---+---+---+---+---+---+---+---+---+ 19 | H | E | I | R | | P | A | R | T | Y | +---+---+---+---+---+---+---+---+---+---+ ============================================================ Substitution Encipherment of Sample Text The Message Encryption Key X[0] = 0.123456789 register K1 R = 3.995678901 register K2 Y[0] = 0.234567891 register M Calculator set to No Rounding (2nd Fn - Tab - .) ie, show all decimal digits Substitution Cipher Character Translation Table Sp 00 J 10 T 20 A 01 K 11 U 21 B 02 L 12 V 22 C 03 M 13 W 23 D 04 N 14 X 24 E 05 O 15 Y 25 F 06 P 16 Z 26 G 07 Q 17 . 27 H 08 R 18 I 09 S 19 Plain Text converted to decimal representation ========================================= : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 : ========================================= 0 | 14| 15| 23| 00| 09| 19| 00| 20| 08| 05| +---+---+---+---+---+---+---+---+---+---+ 1 | 00| 20| 09| 13| 05| 00| 06| 15| 18| 00| +---+---+---+---+---+---+---+---+---+---+ 2 | 01| 12| 12| 00| 07| 15| 15| 04| 00| 13| +---+---+---+---+---+---+---+---+---+---+ 3 | 05| 14| 00| 20| 15| 00| 03| 15| 13| 05| +---+---+---+---+---+---+---+---+---+---+ 4 | 00| 20| 15| 00| 20| 08| 05| 00| 01| 09| +---+---+---+---+---+---+---+---+---+---+ 5 | 04| 00| 15| 06| 00| 20| 08| 05| 09| 18| +---+---+---+---+---+---+---+---+---+---+ 6 | 00| 16| 01| 18| 20| 25| 27| * | <- * := EOM +---+---+---+---+---+---+---+---+ Cipher Text in decimal representation ========================================= : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 : ========================================= 0 | 03| 96| 69| 02| 83| 49| 28| 31| 22| 13| +---+---+---+---+---+---+---+---+---+---+ 1 | 21| 63| 92| 03| 90| 45| 72| 08| 26| 34| +---+---+---+---+---+---+---+---+---+---+ 2 | 15| 65| 62| 01| 34| 84| 50| 12| 62| 83| +---+---+---+---+---+---+---+---+---+---+ 3 | 07| 41| 71| 33| 72| 64| 38| 96| 73| 25| +---+---+---+---+---+---+---+---+---+---+ 4 | 16| 96| 06| 57| 93| 39| 8 | 47| 60| 96| +---+---+---+---+---+---+---+---+---+---+ 5 | 29| 49| 88| 37| 39| 37| 61| 24| 68| 38| +---+---+---+---+---+---+---+---+---+---+ 6 | 60| 90| 25| 96| 67| 84| 65| * | <- * := EOM +---+---+---+---+---+---+---+---+ ============================================================ Transposition Encrypted Message Text The Message Encryption Key X[0] = 0.123456789 register K R = 3.995678901 register K2 Y[0] = 0.234567891 register M Set calculator rounding to 0 decimal digits (2nd Fn - Tab - 0) ie, show only integer portion of answer Encrypted message in blocks of 10 letters |HO T NR IT||AM ES OWOT| | FE D EMLD||IF LOG M | |HC ORN AE||OIOTOE MEI| |TFTN TA LO||TE APH. DR| |OSC ITW IE||Y|* <-* := EOM ========================================= : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 : ========================================= 0 | H | O | | T | | N | R | | I | T | +---+---+---+---+---+---+---+---+---+---+ 1 | A | M | | E | S | | O | W | O | T | +---+---+---+---+---+---+---+---+---+---+ 2 | | F | E | | D | | E | M | L | D | +---+---+---+---+---+---+---+---+---+---+ 3 | I | F | | L | O | G | | | M | | +---+---+---+---+---+---+---+---+---+---+ 4 | H | C | | O | R | N | | | A | E | +---+---+---+---+---+---+---+---+---+---+ 5 | O | I | O | T | O | E | | M | E | I | +---+---+---+---+---+---+---+---+---+---+ 6 | T | F | T | N | | T | A | | L | O | +---+---+---+---+---+---+---+---+---+---+ 7 | T | E | | A | P | H | . | | D | R | +---+---+---+---+---+---+---+---+---+---+ 8 | O | S | C | | I | T | W | | I | E | +---+---+---+---+---+---+---+---+---+---+ 9 | Y | * | <- * := EOM +---+---+ ============================================================ Decrypted Transposition Message ========================================= : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 : ========================================= 0 | N | O | W | | I | S | | T | H | E | +---+---+---+---+---+---+---+---+---+---+ 1 | | T | I | M | E | | F | O | R | | +---+---+---+---+---+---+---+---+---+---+ 2 | A | L | L | | G | O | O | D | | M | +---+---+---+---+---+---+---+---+---+---+ 3 | E | N | | T | O | | C | O | M | E | +---+---+---+---+---+---+---+---+---+---+ 4 | | T | O | | T | H | E | | A | I | +---+---+---+---+---+---+---+---+---+---+ 5 | D | | O | F | | T | H | E | I | R | +---+---+---+---+---+---+---+---+---+---+ 6 | | P | A | R | T | Y*| . | N | O | W | * := Last char +---+---+---+---+---+---+---+---+---+---+ received 7 | | I | S | | | | T | I | +---+---+---+---+ +---+---+---+ all partially 8 | M | E | | F | | A | L | filled rows +---+---+ +---+ +---+---+ after the row 9 | | | O | | E | with the last +---+ +---+ +---+ char received 10 | T | | C | | | are discarded +---+ +---+ +---+ 11 | | | D | +---+ +---+ 12 | | +---+ The actual shape of any particular received message block will vary randomly with the key and the length of the message transmitted. ============================================================ Transposition column selection table The Message Encryption Key X[0] = 0.123456789 register K1 R = 3.995678901 register K2 Y[0] = 0.234567891 register M Set calculator rounding to 0 decimal digits (2nd Fn - Tab - 0) ie, show only integer portion of answer ========================================= : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 : ========================================= 0 | 9 | 2 | 7 | 2 | 4 | 1 | 9 | 1 | 5 | 8 | +---+---+---+---+---+---+---+---+---+---+ 1 | 1 | 4 | 4 | 1 | 6 | 6 | 6 | 3 | 8 | 4 | +---+---+---+---+---+---+---+---+---+---+ 2 | 4 | 4 | 0 | 1 | 8 | 9 | 5 | 9 | 2 | 1 | +---+---+---+---+---+---+---+---+---+---+ 3 | 3 | 7 | 1 | 3 | 7 | 5 | 6 | 1 | 1 | 0 | +---+---+---+---+---+---+---+---+---+---+ 4 | 6 | 7 | 1 | 8 | 4 | 2 | 3 | 8 | 9 | 8 | +---+---+---+---+---+---+---+---+---+---+ 5 | 5 | 9 | 3 | 2 | 9 | 7 | 4 | 0 | 0 | 0 | +---+---+---+---+---+---+---+---+---+---+ 6 | 1 | 4 | 5 | 8 | 8 | 9 | 8 | 2 | 9 | 3 | +---+---+---+---+---+---+---+---+---+---+ 7 | 6 | 8 | 5 | 3 | 2 | 7 | 7 | 8 | 8 | 0 | +---+---+---+---+---+---+---+---+---+---+ 8 | 4 | 3 | 4 | 1 | 2 | 5 | 0 | 8 | 0 | 2 | +---+---+---+---+---+---+---+---+---+---+ 9 | 6 | 7 | 2 | 1 | 1 | 2 | 6 | 4 | 1 | 3 | +---+---+---+---+---+---+---+---+---+---+ 10 | 2 | 6 | 6 | 1 | 8 | 9 | 5 | 1 | 2 | 8 | +---+---+---+---+---+---+---+---+---+---+ G: Sample Message Key Generation The Master Encryption Key X[0] = 0.567890123 register K1 R = 3.998901234 register K2 Y[0] = 0.345678912 register M Calculator set to No Rounding (2nd Fn - Tab - .) ie, show all decimal digits Calculate the Message Encryption Key for the 5th message Repeat calculation of K[i] 5 times K[1] = 0.886684581 K[2] = 0.025546435 K[3] = 0.246545962 K[4] = 0.268216342 K[5] = 0.589846665 R <- 3.99 + (K[5]/100) = 3.995898467 K'[6] = 0.337260078 X <- K'[6] = 0.337260078 K'[7] = 0.83623299 Y <- K'[7] = 0.83623299 K'[8] = 0.208478335 R <- 3.99 + (K'[8]/100) = 3.992084783 The resulting Message Encryption Key for message #5 is: X[0] = 0.381353099 register K1 R = 3.992084783 register K2 Y[0] = 0.546680583 register M  From sameer at soda.berkeley.edu Fri Feb 4 09:45:09 1994 From: sameer at soda.berkeley.edu (Sameer) Date: Fri, 4 Feb 94 09:45:09 PST Subject: removing a key from the keyserver. (eeps) Message-ID: -----BEGIN PGP SIGNED MESSAGE----- I seem to have a bit of a problem-- There's about 4 different public keys with my name on them, and I only use of them these days. I don't have the secret keys for the unused keys-- they've been retired to the great bit bit bucket in the sky.. Is there some way I can get these keys off the servers? -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVKIAni7eNFdXppdAQGhcwQAgzqGzRmirI/7hfkcZj1UzXdloM1PjWw1 M+GbREctd4pkUTTZNQQI15bOFf7OQRNvE3/Yi7HqlqNlEbXGjS/RYG262SX+zi+5 QLF8fs2kzQc5gH/CRQUHMhnr8tceokhFzTU1sF2yDRb/h+5hJbFG4cTYv+W0A0se IDCzSfgBa00= =UDOy -----END PGP SIGNATURE----- From blake.coverett at canrem.com Fri Feb 4 09:55:09 1994 From: blake.coverett at canrem.com (Blake Coverett) Date: Fri, 4 Feb 94 09:55:09 PST Subject: San Jose BBS subject to M In-Reply-To: <199402032112.NAA26624@jobe.shell.portal.com> Message-ID: <60.2831.6525.0C1938ED@canrem.com> > This is one of the best essays I've seen concerning the burning of the > Constitution and Bill of Rights. Looking just at porno isn't the big > picture. It's consensual crimes in general. Too bad most people only > care about their corner of the room, cause the house is on fire and > it'll get to their corner soon. Hmm... wish I had the exact original handy to mis-quote, They came for the drug dealers, but I wasn't a drug dealer so I said nothing They came for the pornographers, but I wasn't a pornographer so I said nothing They came for the gamblers, but I wasn't a gambler so I said nothing Then they came for me, but there was no one left to say a thing -Blake (who is feeling very cynical about life in general) ... * ATP/DJgcc 1.42 * blake.coverett at canrem.com, disclaimers? fooey! From PURTEB at vaxc.hofstra.edu Fri Feb 4 09:59:51 1994 From: PURTEB at vaxc.hofstra.edu (PURTEB at vaxc.hofstra.edu) Date: Fri, 4 Feb 94 09:59:51 PST Subject: Information Message-ID: <01H8HL3EC4ZS94EJ83@vaxc.hofstra.edu> To Whom It May Concern: I'd like some information/literature on you cryptography software. My friend, Brian, is the one who is actually interested, so please send any info to: BRIAN T.L. STRAUSS 357 Doris Avenue Franklin Square, NY 11010 Or, if necessary, you may email any info to the vax account listed at the bottom of this letter. Thank you. Theresa Barley _______________________________________________________________________________ Theresa Barley Hofstra University "Only visiting this planet." Purchasing Department purteb at vaxc.hofstra.edu From wex at media.mit.edu Fri Feb 4 10:29:52 1994 From: wex at media.mit.edu (Alan (Miburi-san) Wexelblat) Date: Fri, 4 Feb 94 10:29:52 PST Subject: CERT advisory Message-ID: <9402041825.AA27913@media.mit.edu> [Some items of interest to C-punks include CERT's advocacy of stopping cleartext transmission of password (no shit sherlock), and their proposed solutions, including the use of one-time passwords which I had queried about on this list a few months back. Of course they don't mention any sort of real encryption, let alone PGP. How hard would it be to build in PGP security to the transmission layer of something like FTP? Seems like a fairly simple problem, given that any site which supports anonymous FTP can publish a public key. Even if we assume that encryption would slow down the file transmission too much, we could still use it for the login/authentication part of the session... --AW] Begin forwarded message: From: CERT Advisory Date: Thu, 3 Feb 94 21:14:40 EST To: cert-advisory at cert.org Subject: CERT Advisory - Ongoing Network Monitoring Attacks Organization: Computer Emergency Response Team : 412-268-7090 ============================================================================= CA-94:01 CERT Advisory February 3, 1994 Ongoing Network Monitoring Attacks ----------------------------------------------------------------------------- In the past week, CERT has observed a dramatic increase in reports of intruders monitoring network traffic. Systems of some service providers have been compromised, and all systems that offer remote access through rlogin, telnet, and FTP are at risk. Intruders have already captured access information for tens of thousands of systems across the Internet. The current attacks involve a network monitoring tool that uses the promiscuous mode of a specific network interface, /dev/nit, to capture host and user authentication information on all newly opened FTP, telnet, and rlogin sessions. In the short-term, CERT recommends that all users on sites that offer remote access change passwords on any network-accessed account. In addition, all sites having systems that support the /dev/nit interface should disable this feature if it is not used and attempt to prevent unauthorized access if the feature is necessary. A procedure for accomplishing this is described in Section III.B.2 below. Systems known to support the interface are SunOS 4.x (Sun3 and Sun4 architectures) and Solbourne systems; there may be others. Sun Solaris systems do not support the /dev/nit interface. If you have a system other than Sun or Solbourne, contact your vendor to find if this interface is supported. While the current attack is specific to /dev/nit, the short-term workaround does not constitute a solution. The best long-term solution currently available for this attack is to reduce or eliminate the transmission of reusable passwords in clear-text over the network. ----------------------------------------------------------------------------- I. Description Root-compromised systems that support a promiscuous network interface are being used by intruders to collect host and user authentication information visible on the network. The intruders first penetrate a system and gain root access through an unpatched vulnerability (solutions and workarounds for these vulnerabilities have been described in previous CERT advisories, which are available anonymous FTP from info.cert.org). The intruders then run a network monitoring tool that captures up to the first 128 keystrokes of all newly opened FTP, telnet, and rlogin sessions visible within the compromised system's domain. These keystrokes usually contain host, account, and password information for user accounts on other systems; the intruders log these for later retrieval. The intruders typically install Trojan horse programs to support subsequent access to the compromised system and to hide their network monitoring process. II. Impact All connected network sites that use the network to access remote systems are at risk from this attack. All user account and password information derived from FTP, telnet, and rlogin sessions and passing through the same network as the compromised host could be disclosed. III. Approach There are three steps in CERT's recommended approach to the problem: - Detect if the network monitoring tool is running on any of your hosts that support a promiscuous network interface. - Protect against this attack either by disabling the network interface for those systems that do not use this feature or by attempting to prevent unauthorized use of the feature on systems where this interface is necessary. - Scope the extent of the attack and recover in the event that the network monitoring tool is discovered. A. Detection The network monitoring tool can be run under a variety of process names and log to a variety of filenames. Thus, the best method for detecting the tool is to look for 1) Trojan horse programs commonly used in conjunction with this attack, 2) any suspect processes running on the system, and 3) the unauthorized use of /dev/nit. 1) Trojan horse programs: The intruders have been found to replace one or more of the following programs with a Trojan horse version in conjunction with this attack: /usr/etc/in.telnetd and /bin/login - Used to provide back-door access for the intruders to retrieve information /bin/ps - Used to disguise the network monitoring process Because the intruders install Trojan horse variations of standard UNIX commands, CERT recommends not using other commands such as the standard UNIX sum(1) or cmp(1) commands to locate the Trojan horse programs on the system until these programs can be restored from distribution media, run from read-only media (such as a mounted CD-ROM), or verified using cryptographic checksum information. In addition to the possibility of having the checksum programs replaced by the intruders, the Trojan horse programs mentioned above may have been engineered to produce the same standard checksum and timestamp as the legitimate version. Because of this, the standard UNIX sum(1) command and the timestamps associated with the programs are not sufficient to determine whether the programs have been replaced. CERT recommends that you use both the /usr/5bin/sum and /bin/sum commands to compare against the distribution media and assure that the programs have not been replaced. The use of cmp(1), MD5, Tripwire (only if the baseline checksums were created on a distribution system), and other cryptographic checksum tools are also sufficient to detect these Trojan horse programs, provided these programs were not available for modification by the intruder. If the distribution is available on CD-ROM or other read-only device, it may be possible to compare against these volumes or run programs off these media. 2) Suspect processes: Although the name of the network monitoring tool can vary from attack to attack, it is possible to detect a suspect process running as root using ps(1) or other process-listing commands. Until the ps(1) command has been verified against distribution media, it should not be relied upon--a Trojan horse version is being used by the intruders to hide the monitoring process. Some process names that have been observed are sendmail, es, and in.netd. The arguments to the process also provide an indication of where the log file is located. If the "-F" flag is set on the process, the filename following indicates the location of the log file used for the collection of authentication information for later retrieval by the intruders. 3) Unauthorized use of /dev/nit: If the network monitoring tool is currently running on your system, it is possible to detect this by checking for unauthorized use of the /dev/nit interface. CERT has created a minimal tool for this purpose. The source code for this tool is available via anonymous FTP on info.cert.org in the /pub/tools/cpm directory or on ftp.uu.net in the /pub/security/cpm directory as cpm.1.0.tar.Z. The checksum information is: Filename Standard UNIX Sum System V Sum -------------- ----------------- ------------ cpm.1.0.tar.Z: 11097 6 24453 12 MD5 Checksum MD5 (cpm.1.0.tar.Z) = e29d43f3a86e647f7ff2aa453329a155 This archive contains a readme file, also included as Appendix C of this advisory, containing instructions on installing and using this detection tool. B. Prevention There are two actions that are effective in preventing this attack. A long-term solution requires eliminating transmission of clear-text passwords on the network. For this specific attack, however, a short-term workaround exists. Both of these are described below. 1) Long-term prevention: CERT recognizes that the only effective long-term solution to prevent these attacks is by not transmitting reusable clear-text passwords on the network. CERT has collected some information on relevant technologies. This information is included as Appendix B in this advisory. Note: These solutions will not protect against transient or remote access transmission of clear-text passwords through the network. Until everyone connected to your network is using the above technologies, your policy should allow only authorized users and programs access to promiscuous network interfaces. The tool described in Section III.A.3 above may be helpful in verifying this restricted access. 2) Short-term workaround: Regardless of whether the network monitoring software is detected on your system, CERT recommends that ALL SITES take action to prevent unauthorized network monitoring on their systems. You can do this either by removing the interface, if it is not used on the system or by attempting to prevent the misuse of this interface. For systems other than Sun and Solbourne, contact your vendor to find out if promiscuous mode network access is supported and, if so, what is the recommended method to disable or monitor this feature. For SunOS 4.x and Solbourne systems, the promiscuous interface to the network can be eliminated by removing the /dev/nit capability from the kernel. The procedure for doing so is outlined below (see your system manuals for more details). Once the procedure is complete, you may remove the device file /dev/nit since it is no longer functional. Procedure for removing /dev/nit from the kernel: 1. Become root on the system. 2. Apply "method 1" as outlined in the System and Network Administration manual, in the section, "Sun System Administration Procedures," Chapter 9, "Reconfiguring the System Kernel." Excerpts from the method are reproduced below: # cd /usr/kvm/sys/sun[3,3x,4,4c]/conf # cp CONFIG_FILE SYS_NAME [Note that at this step, you should replace the CONFIG_FILE with your system specific configuration file if one exists.] # chmod +w SYS_NAME # vi SYS_NAME # # The following are for streams NIT support. NIT is used by # etherfind, traffic, rarpd, and ndbootd. As a rule of thumb, # NIT is almost always needed on a server and almost never # needed on a diskless client. # pseudo-device snit # streams NIT pseudo-device pf # packet filter pseudo-device nbuf # NIT buffering module [Comment out the preceding three lines; save and exit the editor before proceeding.] # config SYS_NAME # cd ../SYS_NAME # make # mv /vmunix /vmunix.old # cp vmunix /vmunix # /etc/halt > b [This step will reboot the system with the new kernel.] [NOTE that even after the new kernel is installed, you need to take care to ensure that the previous vmunix.old , or other kernel, is not used to reboot the system.] C. Scope and recovery If you detect the network monitoring software at your site, CERT recommends following three steps to successfully determine the scope of the problem and to recover from this attack. 1. Restore the system that was subjected to the network monitoring software. The systems on which the network monitoring and/or Trojan horse programs are found have been compromised at the root level; your system configuration may have been altered. See Appendix A of this advisory for help with recovery. 2. Consider changing router, server, and privileged account passwords due to the wide-spread nature of these attacks. Since this threat involves monitoring remote connections, take care to change these passwords using some mechanism other than remote telnet, rlogin, or FTP access. 3. Urge users to change passwords on local and remote accounts. Users who access accounts using telnet, rlogin, or FTP either to or from systems within the compromised domain should change their passwords after the intruder's network monitor has been disabled. 4. Notify remote sites connected from or through the local domain of the network compromise. Encourage the remote sites to check their systems for unauthorized activity. Be aware that if your site routes network traffic between external domains, both of these domains may have been compromised by the network monitoring software. --------------------------------------------------------------------------- The CERT Coordination Center thanks the members of the FIRST community as well as the many technical experts around the Internet who participated in creating this advisory. Special thanks to Eugene Spafford of Purdue University for his contributions. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in Forum of Incident Response and Security Teams (FIRST). Internet E-mail: cert at cert.org Telephone: 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Past advisories, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. --------------------------------------------------------------------------- Appendix A: RECOVERING FROM A UNIX ROOT COMPROMISE A. Immediate recovery technique 1) Disconnect from the network or operate the system in single- user mode during the recovery. This will keep users and intruders from accessing the system. 2) Verify system binaries and configuration files against the vendor's media (do not rely on timestamp information to provide an indication of modification). Do not trust any verification tool such as cmp(1) located on the compromised system as it, too, may have been modified by the intruder. In addition, do not trust the results of the standard UNIX sum(1) program as we have seen intruders modify system files in such a way that the checksums remain the same. Replace any modified files from the vendor's media, not from backups. -- or -- Reload your system from the vendor's media. 3) Search the system for new or modified setuid root files. find / -user root -perm -4000 -print If you are using NFS or AFS file systems, use ncheck to search the local file systems. ncheck -s /dev/sd0a 4) Change the password on all accounts. 5) Don't trust your backups for reloading any file used by root. You do not want to re-introduce files altered by an intruder. B. Improving the security of your system 1) CERT Security Checklist Using the checklist will help you identify security weaknesses or modifications to your systems. The CERT Security Checklist is based on information gained from computer security incidents reported to CERT. It is available via anonymous FTP from info.cert.org in the file pub/tech_tips/security_info. 2) Security Tools Use security tools such as COPS and Tripwire to check for security configuration weaknesses and for modifications made by intruders. We suggest storing these security tools, their configuration files, and databases offline or encrypted. TCP daemon wrapper programs provide additional logging and access control. These tools are available via anonymous FTP from info.cert.org in the pub/tools directory. 3) CERT Advisories Review past CERT advisories (both vendor-specific and generic) and install all appropriate patches or workarounds as described in the advisories. CERT advisories and other security-related information are available via anonymous FTP from info.cert.org in the pub/cert_advisories directory. To join the CERT Advisory mailing list, send a request to: cert-advisory-request at cert.org Please include contact information, including a telephone number. CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Copyright (c) Carnegie Mellon University 1994 --------------------------------------------------------------------------- Appendix B: ONE-TIME PASSWORDS Given today's networked environments, CERT recommends that sites concerned about the security and integrity of their systems and networks consider moving away from standard, reusable passwords. CERT has seen many incidents involving Trojan network programs (e.g., telnet and rlogin) and network packet sniffing programs. These programs capture clear-text hostname, account name, password triplets. Intruders can use the captured information for subsequent access to those hosts and accounts. This is possible because 1) the password is used over and over (hence the term "reusable"), and 2) the password passes across the network in clear text. Several authentication techniques have been developed that address this problem. Among these techniques are challenge-response technologies that provide passwords that are only used once (commonly called one-time passwords). This document provides a list of sources for products that provide this capability. The decision to use a product is the responsibility of each organization, and each organization should perform its own evaluation and selection. I. Public Domain packages S/KEY(TM) The S/KEY package is publicly available (no fee) via anonymous FTP from: thumper.bellcore.com /pub/nmh directory There are three subdirectories: skey UNIX code and documents on S/KEY. Includes the change needed to login, and stand-alone commands (such as "key"), that computes the one-time password for the user, given the secret password and the S/KEY command. dos DOS or DOS/WINDOWS S/KEY programs. Includes DOS version of "key" and "termkey" which is a TSR program. mac One-time password calculation utility for the Mac. II. Commercial Products Secure Net Key (SNK) (Do-it-yourself project) Digital Pathways, Inc. 201 Ravendale Dr. Mountainview, Ca. 94043-5216 USA Phone: 415-964-0707 Fax: (415) 961-7487 Products: handheld authentication calculators (SNK004) serial line auth interruptors (guardian) Note: Secure Net Key (SNK) is des-based, and therefore restricted from US export. Secure ID (complete turnkey systems) Security Dynamics One Alewife Center Cambridge, MA 02140-2312 USA Phone: 617-547-7820 Fax: (617) 354-8836 Products: SecurID changing number authentication card ACE server software SecureID is time-synchronized using a 'proprietary' number generation algorithm WatchWord and WatchWord II Racal-Guardata 480 Spring Park Place Herndon, VA 22070 703-471-0892 1-800-521-6261 ext 217 Products: Watchword authentication calculator Encrypting modems Alpha-numeric keypad, digital signature capability SafeWord Enigma Logic, Inc. 2151 Salvio #301 Concord, CA 94520 510-827-5707 Fax: (510)827-2593 Products: DES Silver card authentication calculator SafeWord Multisync card authentication calculator Available for UNIX, VMS, MVS, MS-DOS, Tandum, Stratus, as well as other OS versions. Supports one-time passwords and super smartcards from several vendors. --------------------------------------------------------------------------- Appendix C: cpm 1.0 README FILE cpm - check for network interfaces in promiscuous mode. Copyright (c) Carnegie Mellon University 1994 Thursday Feb 3 1994 CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 This program is free software; you can distribute it and/or modify it as long as you retain the Carnegie Mellon copyright statement. It can be obtained via anonymous FTP from info.cert.org:pub/tools/cpm.tar.Z. This program is distributed WITHOUT ANY WARRANTY; without the IMPLIED WARRANTY of merchantability or fitness for a particular purpose. This package contains: README MANIFEST cpm.1 cpm.c To create cpm under SunOS, type: % cc -Bstatic -o cpm cpm.c On machines that support dynamic loading, such as Sun's, CERT recommends that programs be statically linked so that this feature is disabled. CERT recommends that after you install cpm in your favorite directory, you take measures to ensure the integrity of the program by noting the size and checksums of the source code and resulting binary. The following is an example of the output of cpm and its exit status. Running cpm on a machine where both the le0 and le2 interfaces are in promiscuous mode, under csh(1): % cpm le0 le2 % echo $status 2 % Running cpm on a machine where no interfaces are in promiscuous mode, under csh(1): % cpm % echo $status 0 % From edgar at spectrx.saigon.com Fri Feb 4 10:35:10 1994 From: edgar at spectrx.saigon.com (Edgar W. Swank) Date: Fri, 4 Feb 94 10:35:10 PST Subject: Announcing SecureDrive 1.3A Message-ID: -----BEGIN PGP SIGNED MESSAGE----- This is to announce the availability of Version 1.3A of SecureDrive. This is a maintenance release of SecureDrive 1.3. It mainly fixes reported problems and has minimal new function. See file BUGS13.DOC. The only visible functional change from 1.3 is the appearance of msg Check bytes in Disk x: Boot Sector need updating from 1.3 to 1.1/1.3A. Proceed? which will be issued by both LOGIN and CRYPTDSK when they attempt to verify a passphrase on a hard disk or diskette encrypted by version 1.3 CRYPTDSK operating in version 1.1 compatability mode. This corrects the error in computing the check bytes used to verify the passphrase and updates the check bytes to the correct 1.1 value and WRITES back the boot sector. Note that once this update has taken place, this disk cannot be decrypted by release 1.3 anymore. Releases 1.3 and 1.3A of Secure Drive are based on releases 1.0 and 1.1, mostly written by Mike Ingle and version 1.2, with significant new code by myself. The code which we wrote is not copyrighted, but the program contains GNU Copylefted code, and therefore may be freely distributed under the terms of the GNU General Public Licence. See file COPYING for legalese. Version 1.2 and 1.3 add significant new function. As of Version 1.2, you may use an operand /PGP with LOGIN, either by itself, or with other operands. By itself, LOGIN /PGP will prompt for a passphrase and set the PGPPASS environment variable with whatever is entered. If PGPPASS is already set then LOGIN D: /PGP or LOGIN /F /PGP will use whatever PGPPASS is set to as the passphrase. For the hard disk partition, LOGIN will test the PGPPASS passphrase. If it is incorrect, then it will prompt you for another passphrase. If PGPPASS is NOT set when these forms of LOGIN are used, than a passphrase is prompted for AND PGPPASS is set to this passphrase. This is more secure than using the SET command since LOGIN only echoes "*"'s when entering the passphrase. As of Version 1.2, typing LOGIN /C /PGP will clear the SecureDrive crypto keys from memory AND clear the PGPPASS environment variable. This is done in a manner less likely to leave your passphrase in memory than just using the DOS SET command. In addition, Version 1.2 clears all the free memory it can find, which is likely to include some plaintext. However, if you want to be absolutely sure all traces of sensitive data are erased from memory then turning off the computer is still recommended. As of version 1.2, if PGPPASS is set before you run CRYPTDSK, CRYPTDSK will ask to use the value of PGPPASS for the passphrase before prompting you (for encryption), or try PGPPASS (for decryption). Obviously, if you encrypt or decrypt a lot of diskettes at once, this feature can save you a lot of typing. The purpose of these changes is to allow you to enter a single passphrase only once per boot IF you choose to use the same passphrase for your PGP secret key, your SecureDrive encrypted hard disk partition, and SecureDrive encrypted floppies. Version 1.3 supports up to four hard drive partitions in "safe" mode, only one of which may be active at any given time. One purpose of having multiple encrypted hard disk partitions is so that up to four users (perhaps members of a family) can each have their own encrypted partition with its own unique passphrase. This allows up to four users to have privacy from each other, even if they all use the same PC and physical hard disk(s). Version 1.3 gives you a choice of whether to use the version 1.1 passphrase digest or to use the (faster but perhaps slightly less secure) 1.0 version. If you select 1.0 compatiblity, it's unnecessary to decrypt and re-encrypt your 1.0-encrypted hard disk partition(s) and floppies. If you decide to switch to 1.1 passphrases, Version 1.3 CRYPTDSK will allow you to convert in one pass with no plaintext stored on disk. Version 1.3 includes the 1.2 changes for using PGPPASS. There are additional ehhancements to allow you to use the hard disk passphrase for the floppy disks without typing it in, even if PGPPASS is not set or is something different. Version 1.3 CRYPTDSK will operate on hard drives with SECTSR loaded. It uses SECTSR to protect the disk during conversion and will leave an encrypted disk partition in protected mode. Mike Ingle and I have different opinions on the distribution of SecureDrive. Under the GNU General License (copyleft) I do not need Mike's permission to distribute version 1.3 and I have not asked for same. My policy on distribution is in the version 1.3 doc: Exporting this program. Cryptography is export controlled, and sending this program outside the country may be illegal. Don't do it. The "author" of versions 1.2 and 1.3, Edgar Swank, says that the export ban should not prevent you from placing this program on public BBS's and anonymous FTP sites in the US and Canada. If individuals outside the US/Canada use the internet or international long distance to obtain copies of the program, THEY may be breaking US law. Any such foreign individuals should be aware that US law enforcement may legally (under US law) apprehend individuals who break US laws even if such individuals are not on or even have never been on US soil. Such apprehension may remove such individuals directly to US jurisdiction without benefit of extradition proceedings in such individuals' home country(ies). This has actually happened in at least two cases, Mexico -- suspect in murder of US drug agent, Panama -- Noriega -- indicted in absencia for drug smuggling. As is well known, after a small war with Panama, Noriega was brought to the USA, tried and convicted. He is now a guest of the US Government in a Florida prison. SecureDrive Version 1.3A is already available for download on the following public BBS's as SECDR13A.ZIP: Eagle's Nest (408)223-9821 Flying Dutchman (408)294-3065 Also I have a report (unverified so far) that Version 1.3 may now be obtained from a mailserver. Send mail to Server at Star.Hou.TX.US with body text that looks like this get /files/public/secdr13a.zip quit Please attempt to use the mailserver or the two BBS's above before requesting a copy directly from me. I will send a FEW more copies via E-mail to persons with a US/Canada net address who request a copy AND promise to upload it to a USA/Canada e-mail fileserver or anonymous FTP site. (I don't have access to FTP from my account here). I will announce here as I learn of Version 1.3A availability via additional automated e-mail or FTP sites. Here is the contents of SECDR13A.ZIP: Length Method Size Ratio Date Time CRC-32 Attr Name ------ ------ ----- ----- ---- ---- -------- ---- ---- 18321 DeflatX 6914 63% 06-14-93 22:27 0767480b --w- COPYING 1332 DeflatX 518 62% 01-30-94 09:30 bbb5655c --w- MAKEFILE 1632 DeflatX 1260 23% 12-04-93 00:43 980125ec --w- KEY.ASC 19664 DeflatX 4183 79% 11-19-93 21:42 22c2502c --w- CRYPT2.ASM 1355 DeflatX 629 54% 01-21-94 08:44 db63ade4 --w- RLDBIOS.ASM 24652 DeflatX 7740 69% 01-29-94 14:51 d0f5feaf --w- SECTSR.ASM 7507 DeflatX 2581 66% 12-29-93 21:15 ceda9b20 --w- SETENV.ASM 33 Stored 33 0% 07-16-93 06:09 aa6151a5 --w- M.BAT 16175 DeflatX 3949 76% 01-29-94 17:57 88215957 --w- CRYPTDSK.C 12260 DeflatX 3167 75% 01-29-94 18:27 7b10d96f --w- LOGIN.C 11557 DeflatX 3277 72% 05-09-93 19:38 e71f3eea --w- MD5.C 10860 DeflatX 2878 74% 01-29-94 18:07 3a9154c0 --w- SDCOMMON.C 1778 DeflatX 1160 35% 01-30-94 09:31 48688ff7 --w- SECTSR.COM 1152 DeflatX 586 50% 01-30-94 10:15 e44c593f --w- BUGS13.DOC 31425 DeflatX 10610 67% 01-30-94 09:59 235f457a --w- SECDRV.DOC 35024 DeflatX 16598 53% 01-30-94 09:31 99417b77 --w- CRYPTDSK.EXE 34072 DeflatX 16021 53% 01-30-94 09:31 26a2fb82 --w- LOGIN.EXE 3407 DeflatX 1097 68% 05-11-93 12:49 f1f58517 --w- MD5.H 3020 DeflatX 909 70% 01-24-94 03:32 8ee1c1f6 --w- SECDRV.H 1254 DeflatX 541 57% 05-09-93 19:39 182978aa --w- USUALS.H 152 Stored 152 0% 01-30-94 10:03 68a2560c --w- SECTSR.SIG 152 Stored 152 0% 01-30-94 10:04 a1d33655 --w- LOGIN.SIG 152 Stored 152 0% 01-30-94 10:04 845de45f --w- CRYPTDSK.SIG ------ ------ --- ------- 236936 85107 65% 23 Also note that the ZIP file contains PGP detached signatures (*.SIG) for the executable files. Finally here is my public key, also available on many public keyservers; note who has signed it. Type bits/keyID Date User ID pub 1024/87C0C7 1992/10/17 Edgar W. Swank - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAirfypkAAAEEAKe2jziPeFw6hY19clR2GtQ4gtGCSSVOTgPKEJzHfuC74Scf 9PEuu1kebLhHk43A9wo1vr52o4jpH/P/tnFmRtBQOMzLUzAt5rMucswtSVviMQS2 hBuc9yGJKWHVcyfA79EARKEYTdhx+2qKI+hFJcPE+rmD8wVoF94nNf3ah8DHAAUR tClFZGdhciBXLiBTd2FuayA8ZWRnYXJAc3BlY3RyeC5zYWlnb24uY29tPokAlQIF ECwAALo04ip/MkW/XQEBmNQD/0jUVqT0LMoVvw7Zz2FXyWrdBn6bRlyGxeqQWhig DXRipZ824/fHbA2vkbAczEayw8ZpwRVmhWNsxxWhjYFIi92KYJbAP/XIbr+rEuTI hPKKKKhuuGLUWhfXhCFluHjs3CA6ZQwnT4jnu1NlCkcnWLbL4ktqub2zLwrHCPUe 31L1iQCUAgUQK9Y50xgzoWUItwfFAQHPrAPzBbf6lQyzwbUwdxayzLDoh3Hygnun Looi+yzziEVQchOgSt3sLe2I108DLxTgp+26lJYTAZB+Gg8HGyB+Nz6263D0XlVU XQi9/7CSRyd8bhYFeuFPwFzHPWZlyLDAIsuaEfBsmp2DBLgffvhUCqiiWYmP9oa+ rOA+5IHS+xN8tIkAVQIFECu5dYOzvL/Jh3qmYQEBYDICAI5KdaTiPr2Y1OtRCTi6 xMG6hnRNalvK9C5d/bxrKnUYqsfSpKayX+Ts9psmq6a6doOrX3AAtgcZuTCYUfQk d22JAJUCBRArlzITocE4X0qvAOUBAahdA/4rRoSVp3G+Ki0wvkcAvpnwt7vSEYpH XSkyoC8LdAqs9bft5NDTOykgw5H1qFG1Doqk6oR0yxY0k91eVoBVclLWDb94sNO3 JjHJKO/QdODik5DpmXEnQhBfLlujuYkCtJjoBv1+QdImnnv9aNidGuLAneNvZ+UN NqfE3IRShzNw3IkAlQIFECtj5iw2VpfGMt2Y2QEBDEYD/2iMMml65eFaNWrNP7ab Yh8QW3+Mnjyl5CNpAjGkxejmIm4nZKqUHN5DuGzpJDnstRwbz6daXK15XcoM1m8g uhu6UzIwHs9+hbKE6inTCz4C0mE55PSmvF/ejjexnGzsiFpuFnjN/sRrSHc57flO IUWBCZD8Hizz3aYBxmvwJ863iQCVAgUQKxEXHOJ13g7/Z/cLAQGyYgP/apcv9V2M bHFgU0hl0D4MLqGjBReUfDroxQCsgsTb/0nr1W9yltBMqYPgD7ThLAf2rxIPNbGy D7VUA27LTwQTS6n2mbtkHOvGQVw7J2GwTA6319Gf0Qne0M1h7VJWjFX0Vzjuh/nk 6btxM2uTLSF2nUsDXe5/9N5XeesFhrbXNrM= =4fGE - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVFwE94nNf3ah8DHAQEkVQP/QzHZ0oqDW3XYrpYANTfeA7hIMgweKz8N 7/UpkV5XHhePwEfJA3fFn2Gs/BwF6Oy0xsJOk16AIE5JtAWqp5x3jzQ6BuJhkhhk RcVrmtqqBfj8PMnpm3rdQRUMC9CftxA/m06y3Cw5FHgxvrOXcZfyrsBIR26UejsI 4fOY+JjlglQ= =sBOp -----END PGP SIGNATURE----- -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca From hughes at ah.com Fri Feb 4 10:45:10 1994 From: hughes at ah.com (Eric Hughes) Date: Fri, 4 Feb 94 10:45:10 PST Subject: STEG: a real-life use for steganography Message-ID: <9402041840.AA21942@ah.com> I had an extremely interesting conversation with a fellow last night, say, X. A mutual friend of ours had steered him towards me. X has contacts in a country C which will remain nameless. The government of C is extremely repressive and has a large internal police force. The situation, evidently, is one similar to the old USSR, where masks behind masks were used in daily life, little is exactly as it appears, and the default discourse is sideways speaking. The scenario is almost worst-case. There is a need for steganography, since the use of cryptography is grounds for suppression; likewise there is a need for covert channels. There is a need for double-blinding of identities, since one's friends may be difficult to detect. And so on. The aspect that _is_ good is that C is not the whole world, and there are plenty of us not in C. The first most useful facility to set up, X thinks, is simply news from outside of C as a bypass of the media in C--wire service articles about C, for example, as well as a feed of the newsgroup "soc.culture.". Here's the technique we came up with last night. C has an indigenous music M which is periodically performed in the United States. We were thinking about pressing short-run CD's of these live performances. We all know where the news feeds go. The CD's would be distributed via standard music channels and would be surprisingly brisk sellers. The costs of the project can evidently be footed by willing members of the M industry in C. Now let me address the standard comment "Oh, steganography completely solves that problem." Please. That's like saying, "Oh, just use an internal combustion engine to solve your long distance transport problems." Such statements are a failure of imagination and seriousness. A practical system to carry this project out is quite large. I see at least the following pieces needed: -- A facility to gather the data being put on the disks. This by itself is no trivial task, since it involves the collection of many disparate sources. -- An authoring system to arrange the data, once collected, into a usable structure. -- An encryption system for the arranged data. Such a system can't treat the data as one long stream, because of the segmented nature of the data. The ability to mount the CD as a file system would be good leverage for other programmers. -- A mastering system to combine a music master CD (done separately) and a data master (in some format) into a new music master CD. This will, at the least require a machine with a CD reader and writer. Blank media, FYI, for a CD writer are about $20/disk. The CD writer is about $5K. These numbers are approximate and falling rapidly. -- A CD pressing facility. These are commercially available at quite reasonable cost in quantities in the 100's. -- A CD distribution system. This will likely be the M industry, and thankfully the details of international shipping and customs will be taken care of, as well as retail distribution. -- A decryption system to get the data off the CD. -- Client software to make use of the information. It need not all be in text format. -- A key distribution system. A secret key per CD and word of mouth may be sufficient. A system to make rememberable sentences out of an arbitrary 128 bits (and the inverse) would be useful to facilitate word of mouth. This is no small task. Those interested in participating may start working on any of the above. The tasks are fairly separable. Here are some that I can identify as critical. -- A standard for encoding data into the low bits of an audio CD. This will likely require a lot of specific knowledge of the low level encoding and error correction systems used in CD's. I do know that they are not simple, being much more than bit-correcting linear codes. -- A standard for the encoding of file system data onto these low bits. This should be a separate document, even though the design of this will be influenced by the bit encoding standard. Some adaptation of existing file system standards may be appropriate. -- A standard for the encryption format for the file system. It may be that Matt Blaze's CFS cryptograpy can be lifted wholesale. -- Multiplatform software support for all of the above. I am pleased to have a real example to work on, rather than a lot of wixering about hypotheticals. I welcome discussion of this topic. Eric From freeman at MasPar.COM Fri Feb 4 10:55:12 1994 From: freeman at MasPar.COM (Jay R. Freeman) Date: Fri, 4 Feb 94 10:55:12 PST Subject: San Jose BBS subject to M Message-ID: <9402041855.AA00762@cleo.MasPar.Com> > Hmm... wish I had the exact original handy to mis-quote ... Is this the one you mean? First they came for the Communists, and I didn't speak up, because I wasn't a Communist. Then they came for the Jews, and I didn't speak up, because I wasn't a Jew. Then they came for the Catholics, and I didn't speak up, because I was a Protestant. Then they came for me, and by that time there was no one left to speak up for me. by Rev. Martin Niemoller, 1945. From MCALVINK at ccmail.sunysb.edu Fri Feb 4 11:15:20 1994 From: MCALVINK at ccmail.sunysb.edu (MCALVINK at ccmail.sunysb.edu) Date: Fri, 4 Feb 94 11:15:20 PST Subject: UNSUB Message-ID: <01H8HO3DOA2Q95N79W@ccmail.sunysb.edu> UNSUBSCRIBE m calvinkoons From nobody at shell.portal.com Fri Feb 4 11:25:15 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Fri, 4 Feb 94 11:25:15 PST Subject: REMAILERS: Netcoms Policy and hazards to remailers Message-ID: <199402041921.LAA06512@jobe.shell.portal.com> An issue arose today with Netcoms DASD migration... My Account was moved from /ux/accountname to /uxx/accountname, which caused my .forward file to begin bouncing mail. Netcoms sysadms promptly moved my .forward to .forard.bak to eliminate the bounces and notified me via the now working mail. During my conversation with the admin I asked specifically what Netcoms policy vis-a-vis ECPA, search warrants, and warrantless requests from Law enforcement of any kind for both e-mail in transit and stored files.. The answer was as it should be. A "proper" search arrant would be required prior to cooperation with LE. Netcom as a policy ill NOT provide ANY materials other than account name without a search warrant, unless an account on netcom is used to crack another site and netcom is liable( in which case they will file a complaint and give cooperation to investigating officers.) a warrant is required for release. The subject of remailer and crypto out of a netcom account didnt elicit any comment from the sysadmin...) Tomorrow I will call and ask specifically on that area... anon From mg5n+ at andrew.cmu.edu Fri Feb 4 11:29:55 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Fri, 4 Feb 94 11:29:55 PST Subject: Running regularly In-Reply-To: Message-ID: Matthew Bernardini wrote: > Why not make two shell scripts, one that sleeps for so long (say 20 minutes) > using the unix sleep command, and then calls the remailer scripts in an > infinite while loop. This would work if you set it up as a background > process,and you don't need to be root for it to work. Only downsides are > that when the machine crashes you have to log back in and restart script, > your sleep command will always be in the top window if your sys-admin > is watching, and you have to be careful not to spawn to many processes and > bring the system down. I tried this on the system here, but it killed off the process when I logged off. As for starting too many processes, just don't start them... leave it as one single process that just repeats itself indefinently with sleeps in between. From beker at netcom.com Fri Feb 4 12:09:54 1994 From: beker at netcom.com (Brian Beker) Date: Fri, 4 Feb 94 12:09:54 PST Subject: Remailer Delays Message-ID: The last two messages I've sent through remailers have taken upwards of two days to arrive at their destinations. Parallel messages sent directly arrived immediately. The two remailers are Hal's and rebma. What is making this happen? Is it related to all the recent PGP FAQ traffic? Which remailers if any are not suffering from these lags? THX, B From wex at media.mit.edu Fri Feb 4 12:10:14 1994 From: wex at media.mit.edu (Alan (Miburi-san) Wexelblat) Date: Fri, 4 Feb 94 12:10:14 PST Subject: STEG: a real-life use for steganography In-Reply-To: <9402041840.AA21942@ah.com> Message-ID: <9402042009.AA09438@media.mit.edu> Hunh. I'm surprised that you would select a fixed medium (CDs) for a variable information source. How often do you plan to press new CDs? Would it not be simpler to use steganography to encode the desired information into GIFs of, say, US weather maps? These maps are revised quite often and it would be natural to send person X a new weather map every day or so. Yes, as we all know from past discussions, it's possible for someone who knows what you're doing to recover the data "hidden" in the pictures. But how likely is that to happen? What's the cost of this (or another non- media-dependent solution) versus the complexity and cost of using CDs as your transport mechanism? [About the CDs: what will the sound like when played on a normal CD player? Isn't this likely to attract attention?] --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 an53607 at anon.penet.fi All the world's a stage and most of us are desperately unrehearsed. From mab at research.att.com Fri Feb 4 12:10:15 1994 From: mab at research.att.com (Matt Blaze) Date: Fri, 4 Feb 94 12:10:15 PST Subject: Followup: Notes on key escrow meeting with NSA Message-ID: <9402042007.AA25589@big.l1135.att.com> Newsgroups: sci.crypt,talk.politics.crypto,comp.org.eff.talk,alt.privacy.clipper Subject: Re: Notes on key escrow meeting with NSA In a recent article, I wrote: >A group from NSA and FBI met the other day with a group of us at Bell >Labs to discuss the key escrow proposal. They were surprisingly >forthcoming and open to discussion and debate, and were willing to at >least listen to hard questions. They didn't object when asked if we >could summarize what we learned to the net. Incidentally, the people >at the meeting seemed to base a large part of their understanding of >public opinion on Usenet postings. Postings to sci.crypt and >talk.politics.crypto seem to actually have an influence on our >government. > >A number of things came out at the meeting that we didn't previously >know or that clarified previously released information. What follows >is a rough summary; needless to say, nothing here should be taken as >gospel, or representing the official positions of anybody. Also, >nothing here should be taken as an endorsement of key escrow, clipper, >or anything else by the authors; we're just reporting. These notes >are based on the collective memory of Steve Bellovin, Matt Blaze, Jack >Lacy, and Mike Reiter; there may be errors or misunderstandings. >Please forgive the rough style. Note also the use of "~ ~" for >'approximate quotes' (a marvelous Whit Diffie-ism). A couple of clarifications and new recollections. Same disclaimers as above. The NSA people were asked whether they would consider evaluating ciphers submitted by the private sector as opposed to simply proposing a new cipher as a "black box" as they did with Skipjack. They said they can't do this because, among other things, of the extraordinary effort required to properly test a new cipher. They said that it often takes from 8-12 years to design, evaluate and certify a new algorithm, and that Skipjack began development "~about 10 years ago.~" I asked if we should infer anything from that about the value of the (limited time and resource) civilian Skipjack review. They took that with good humor, but they did say that the civilian review was at least presented with and able to evaluate some of the results of NSA's previous internal reviews. Regarding the scale of the escrow exploitation system, they said that they did not yet have a final operational specification for the escrow protocols, but did say that the escrow agencies would be expected to deliver keys "~within about 2 hours~" and are aiming for "~close to real time.~" Initially, the FBI would have the decoder box, but eventually, depending on costs and demand, any law enforcement agency authorized to conduct wiretaps would be able to buy one. The two escrow agencies will be responsible for verifying the certification from and securely delivering the key halves to any such police department. As an aside, we've since been informed by a member of the civilian Skipjack review committee that the rationale for not having the escrow agency see the actual wiretap order is so that they do not have access to the mapping between key serial numbers and people/telephones. Also, on second reading, I wasn't at all clear about the reverse engineering resistance of the chips. I wrote: >...they are designed to resist reverse engineering the data in the >chip without destroying the chip. It is not clear (from the >information presented at the meeting) whether the chips are equally >resistant to destructive reverse-engineering to learn the skipjack >algorithm.... That is, the chips are designed to resist non-destructive reverse engineering to obtain the unit keys. They do not believe that it is possible to obtain the unit key of a particular chip without destroying the chip. They did not present any assertions about resistance to destructive reverse engineering, such that several chips can be taken apart and destroyed in the process, to learn the Skipjack algorithm. Finally, I should have made clear that "Clipper" is more properly called the "MYK-78T". -matt From Lyle_Seaman at transarc.com Fri Feb 4 12:25:15 1994 From: Lyle_Seaman at transarc.com (Lyle_Seaman at transarc.com) Date: Fri, 4 Feb 94 12:25:15 PST Subject: Read-Once Messages? In-Reply-To: <9401311747.AA12799@federal-excess.apple.com> Message-ID: lefty at apple.com (Lefty) writes: > Has there been any work done on messages that can be read a single time, > preferably only by a designated recipient, and is not amenable to being > captured as it is "played"? I know that Gibson's poem _Agrippa_ had some > sort of self-destruct feature built into it, but I don't know what > mechanism was used to implement this. I think I received one of these once, but I can't remember what it was. From dm at hri.com Fri Feb 4 12:39:54 1994 From: dm at hri.com (dm at hri.com) Date: Fri, 4 Feb 94 12:39:54 PST Subject: Running regularly In-Reply-To: Message-ID: <9402042034.AA29033@sparc31.hri.com> Date: Fri, 4 Feb 1994 14:27:46 -0500 (EST) From: Matthew J Ghio Matthew Bernardini wrote: > Why not make two shell scripts, one that sleeps for so long (say 20 minutes) > using the unix sleep command, and then calls the remailer scripts in an > infinite while loop. This would work if you set it up as a background > process,and you don't need to be root for it to work. I tried this on the system here, but it killed off the process when I logged off. If it's a UNIX system, try using the ``nohup'' (for ``no-hang-up'', from the days when you connected to computers by telephone) command to keep your background process alive after you log out. From nobody at shell.portal.com Fri Feb 4 12:45:15 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Fri, 4 Feb 94 12:45:15 PST Subject: Magic Money Digicash System Message-ID: <199402042044.MAA28800@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- Magic Money Digital Cash System Brought To You By Pr0duct Cypher Based on PGP Tools - The Crypto Construction Set Send to csn.org, should appear under /mpj somewhere Magic Money is a digital cash system designed for use over electronic mail. The system is online and untraceable. Online means that each transaction involves an exchange with a server, to prevent double-spending. Untraceable means that it is impossible for anyone to trace transactions, or to match a withdrawal with a deposit, or to match two coins in any way. The system consists of two modules, the server and the client. Magic Money uses the PGP ascii-armored message format for all communication between the server and client. All traffic is encrypted, and messages from the server to the client are signed. Untraceability is provided by a Chaum-style blind signature. Note that the blind signature is patented, as is RSA. Using it for experimental purposes only shouldn't get you in trouble. Digicash is represented by discrete coins, the denominations of which are chosen by the server operator. Coins are RSA-signed, with a different e/d pair for each denomination. The server does not store any money. All coins are stored by the client module. The server accepts old coins and blind- signs new coins, and checks off the old ones on a spent list. Suppose Alice wants to pay Bob some Magic Money. Alice uses her client module to extract some coins from her account (file). She then mails those coins to Bob, using a secure channel such as a PGP message. Bob runs his client module on the coins. The client module checks the signatures, and totals up the value of the coins. It then prompts Bob to choose the values of new coins which total the same value as the old ones. For example, Alice sends Bob a 64-unit coin. Bob chooses a 32-unit and two 16-unit coins. The client module then generates proto-coins, which are blinded but unsigned. It produces an output file containing Alice's coins, and the new proto-coins. Bob mails this to the server. The server counts up Alice's coins, checks their signatures, and checks for double-spending. It puts the coins on the cancelled list, signs the proto-coins, and mails them back to Bob. Bob runs his client module on the reply message. It unblinds the signed coins and adds them to his coin file. This completes the transfer. The Magic Money server is a filter, accepting input from stdin and sending output to stdout. To set up a server, you first compile the server program and install it in its own directory. Dump some random junk in a file called rand.dat. This and the system clock is hashed to generate random numbers. Then execute "s i" to initialize the server. It will prompt you for some information. For the denominations, I would use powers of 2 (1, 2, 4, 8, 16, 32, 64, 128...) because they minimize the number of coins needed to transfer any amount. The server will create a key and an e/d list. An ascii-armored copy of the server's public key is written to bank.asc. Users must have this key to use the server, so however you publicize your server, include the key. Set up the system so that, when a message comes in, the server is executed and the message (which need not be cleaned up first) is piped into stdin. The output from the server should be mailed back to the user. The server can be run through a remailer, if you don't want to reveal your location. This would be easiest through a penet-style remailer. Operating through a cypherpunks-style remailer would require an external mechanism to handle reply headers. However you do it, just see to it that messages go into the server and the output goes back to the right user. If you just want to experiment on one machine, put the server and client in different directories, to prevent their files from interfering with each other. Set up a shell script/batch file to feed the client's output into the server and return the server's reply. The server has the ability to include a message to the client. If the file msg.txt exists in the server's directory, it will be included in the server's replies, and the clients will display it. The client will wait for a keypress after displaying the message, so the last line should be "press any key to continue" or something similar. The message should not be longer than one screen, because there is no "more" in the client. The main use for the message is to warn users of expirations (see below), but you can send anything you want. To set up a client, compile the client module (unless the server operator was nice enough to provide a binary [hint]) and put it in its own directory. Put some random junk (for random numbers) into rand.dat, and put the server's ascii-armored key in bank.asc. Now execute "c -i" to initialize your client. It will create a key and generate "output.asc" which should be mailed to the server. When the reply comes back, save it in a file and run "c ". This will initialize your e-list and coin name files. If the server has a msg.txt, you will see it. Now get another user to send you some coins. Coins are binary, not ascii- armored, because we assume you will use a PGP message or other "envelope" to transport them. Execute "c " to process your coins. The client will show the denominations as the signatures are checked. It will show the total, and allow you to choose denominations for the new coins you want to generate. Then it will generate a file "output.asc" which should be mailed to the server. Take the server's reply and run "c " on it. It will extract and unblind the coins, displaying them as it does so. When it is done, you will have some coins to spend. To pay someone some coins, execute "c -p". The client will show a list of coins you have, and allow you to choose values to extract. These will be copied into "coins.dat", which you then mail to the person you want to pay. He does as above to deposit them. Do not lose "coins.dat" because the coins are removed from your file as they are extracted. Server maintenance and expirations: the server must keep track of all the coins which have ever been spent, at 16 bytes each. While the server uses an efficient hash file to maintain speed, the file will eventually grow to consume the entire filesystem of the host machine. There must be a way to clear it out eventually. The server operator executes "s n" to generate a new e/d list. The old list will be renamed. Old coins are still valid at this point. The server operator should put up a message warning users to exchange their old coins. The next time a user interacts with the server, his elist will be updated automatically, and the old one renamed. The user can (and should be warned to) execute "c -x" to automatically exchange all his old coins for new ones. After a reasonable time, and plenty of warning (!) the server operator executes "s d" to delete the old spent list, efile, and dfile. Old coins are now worthless. The next time a user interacts with the server, his old elist will be deleted automatically by his client. Old coins will now show up as having zero value, and a "c -x" will discard them as "expired coins". If the user was dumb enough not to exchange his coins, too bad. The server will only sign as much value as it receives, so the amount of money in circulation remains constant. We have a chicken-and-egg problem: how is value created? The server operator has the magical ability to create new coins from thin air. He executes "s m " where x is the denomination of the coins he wants. The result is a coins.dat file, which can be mailed to a user and processed by his client module. The server just signs the coins directly, without any blinding. Coins are represented by RSA integers in the normal PGP-signature format. The coin is 16 bytes, padded in the same way that PGP 2.3a pads a signature. The coin is stored signed, that is, raised to the d power. There is no hashing involved; RSA is used directly. To blind a coin, the client generates a blinding factor, a large random number. The random number is raised to the appropriate e power, modulo the server's n. It is then multiplied with the unsigned coin, generating a blinded "proto-coin", which is sent to the server. The server signs the blinded coin by raising to the power d. This "decrypts" the blinding factor at the same time as it signs the coin, because RSA is multiplicative. Then the client divides out the blinding factor, leaving the signed coin. How big should the blinding factor be? I am not sure. Right now, it is set to the modulus minus one byte. This is certainly secure, but it takes a long time to unblind because mp_inv is a slow operation. If you know how long it needs to be, feel free to change it. Now, if you're still awake, comes the fun part: how do you introduce real value into your digicash system? How, for that matter, do you even get people to play with it? What makes gold valuable? It has some useful properties: it is a good conductor, is resistant to corrosion and chemicals, etc. But those have only recently become important. Why has gold been valuable for thousands of years? It's pretty, it's shiny, and most importantly, it is scarce. Digicash is pretty and shiny. People have been talking about it for years, but few have actually used it. You can make your cash more interesting by giving your server a provocative name. Running it through a remailer could give it an 'underground' feel, which would attract people. Your digicash should be scarce. Don't give it away in large quantities. Get some people to play with your server, passing coins back and forth. Have a contest - the first person who (breaks this code, answers this question, etc.) wins some digital money. Once people start getting interested, your digital money will be in demand. Make sure demand always exceeds supply. If some people get servers up and running, and if there is any interest, I can write an automatic client which will accept and pay out Magic Money without human intervention. Please let me know if you have an application for this, or any other ideas for the system. Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVChQcGoFIWXVYodAQFDhAQAlOdUdnZZxarfxIbACZlHv+Hza+lLkaQl 2eMBro4Bu/QV6wjnTPfw4AND8HbsgdCYjsh7B6XBkpLqVqSk0/fBkwrb4jmvG/bD sU2ccYm2Da9qShHaYWSqApugVA+0bPc9LSHxpbbrAfXIkMQvYqKQMjde6VW4zecZ fZAtf6J/7TY= =N7Kb -----END PGP SIGNATURE----- From sdw at meaddata.com Fri Feb 4 12:49:55 1994 From: sdw at meaddata.com (Stephen Williams) Date: Fri, 4 Feb 94 12:49:55 PST Subject: Running regularly In-Reply-To: Message-ID: <9402042046.AA20030@jungle.meaddata.com> > > Matthew Bernardini wrote: > > > Why not make two shell scripts, one that sleeps for so long (say 20 minutes) > > using the unix sleep command, and then calls the remailer scripts in an > > infinite while loop. This would work if you set it up as a background ... > I tried this on the system here, but it killed off the process when I > logged off. > > As for starting too many processes, just don't start them... leave it > as one single process that just repeats itself indefinently with sleeps > in between. You did try to nohup it, right? nohup script blabla... 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 nobody at shell.portal.com Fri Feb 4 13:29:54 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Fri, 4 Feb 94 13:29:54 PST Subject: remailer delays Message-ID: <199402042129.NAA11271@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- Brian Beker asked, "The last two messages I've sent through remailers have taken upwards of two days to arrive at their destinations. Parallel messages sent directly arrived immediately. The two remailers are Hal's and rebma. What is making this happen? Is it related to all the recent PGP FAQ traffic? Which remailers if any are not suffering from these lags?" I am not using remba at all, not even pinging it. The last three days have seen the "Bomb me!" request dwindle to about 5-6 a day. Hal's ("shell") is working without a glitch. That leaves remba. If I can get my list of remailer details completed, people like you with specific needs (today you want speed) will be happier. The fast remailers that I am using and have had NO problem with are: @remailers = ( "catalyst at netcom.com", "remailer at dis.org", "ebrandt at jarthur.claremont.edu", "remailer at merde.dis.org", "elee7h5 at rosebud.ee.uh.edu", "hfinney at shell.portal.com", "hh at soda.berkeley.edu", "qwerty at netcom.com" ); These are not necessarily the most secure ones, but they are all pingable with variable 5 minute to 1 hour delays for the pings to come back. If speed is of concern, these are your remailers. cicada and pmantis are also quite fast but are not meant for what I need them for. I am very sensitive to kicking mailers off my list if I cause a problem, even once. The merde and dis.org remailers often add an hour delay, seeming to batch things out. jarthur is often ~10 minutes, but just as often an hour. - From my incomplete List: Remailer Fast? OpLog SysLog Subj Batch RD NL CPU Phys PGP BitB -------- ------ ----- ------ ---- ----- -- -- --- ---- --- ---- ---------- bsu-cs + ? ?/? + ? ? ? ? ? 23a ? catalyst + N? SM/MQ - - ? - PA M 23a - choas + ? ?/? + ? ? ? ? ? - - cicada ++ ? ?/? - - - - ? ? - - dis.org -/-- ? ?/? - ? ? ? ? ? 23a ? extropia +/? ? ?/? + ? ? ? Pr? ? 23a ? jarthur +/-- St SM/MQ? - ? ? ? Un ? 23a - menudo -- ? ?/? - t1 ? ? ? ? - ? merde -/-- ? ?/? - ? ? ? ? ? - ? penet.fi -- St ?/? - t? 24 + Pr H - - pmantis ++ ? ?/? - ? - - ? ? - - qwerty + C SM/MQ - - - - PA M 23a + rosebud ++/- ? ?/? - - - ? ? ? 23a ? remba ? ? ?/? ? ? ? ? ? ? 23a ? shell ++/+/- St ?/? - ? ? ? ? ? 23a - soda ++/- St+? ?/? - ? ? ? ? ? - Subj: Strips Subject header? NL: Non-linear remailing? 123->231. RD: Random delay added (max, in hours)? Batch: Batched remailing? t2 means twice daily. n5 means after 5 messages. CPU: Pr = private. PA = account on public access machine. Un = university. Phys: Physical security of the CPU, especially at night. H/M/L. BitB: BitBucket feature? Fast?: ++ <5 min + 5-10 min. - ~10-30 min delay -- pinging isn't practical due to long delays +/- sometimes +, sometimes - Normal internet mail delays are common, and are not equivalent in the two directions between any two remailers. Mail still gets through. OpLog: F: full copies of all mail is archived. My large volume mailing should help put a stop to this. St: Stats logs of when mail was remailed. St+: Stats logs of when and where mail was remailed. St-: simple counter. N: operator keeps no logs. SysLog: SM: sendmail logs of when and where mail was exchanged. Root access. MQ: mailqueue accessible by anyone on the site. Could make logs. -Nik (Xenon) -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLVJ3RwSzG6zrQn1RAQEfFQP/Rkt6bVBWCetn4YH/dm7LJ+EhAia+NXDy EutlgmKJKXPc2eh3pypVb0cxdlMr/dOidXrTY3LzCF4iHOc7/l1FNegkbrJltf9R +rOHyh23FDnQZE8NIxq9KLr++iUxMFsq8UfmNy+Z5ojMh2Nc+54CBSHoAMMEryPG oEOu5i3jK08= =nfRB -----END PGP SIGNATURE----- From hfinney at shell.portal.com Fri Feb 4 13:59:53 1994 From: hfinney at shell.portal.com (Hal) Date: Fri, 4 Feb 94 13:59:53 PST Subject: Magic Money Digicash System Message-ID: <199402042158.NAA09840@jobe.shell.portal.com> Wow! Hot stuff! I looked at csn.org, but I didn't find magic money. The pgp_tools has been there for a while, of course. Somebody post when they find it. Hats off to Pr0duct Cypher! Hal From MIKEINGLE at delphi.com Fri Feb 4 14:25:16 1994 From: MIKEINGLE at delphi.com (Mike Ingle) Date: Fri, 4 Feb 94 14:25:16 PST Subject: Prodigy snooping Message-ID: <01H8GY0YK46W91W1I6@delphi.com> >I heard from a friend that Prodigy was scanning user's hard drives. >Basically, when you logged on Prodigy made a complete directory of your >hard drive and uploaded it. Prodigy was using this to find out what >applications you used so they could direct the appropriate advertising >towards you. Apparently, they're suffering several lawsuits now because >of it. This tale has been around for a while. Prodigy makes a huge file, over 1 MB, on your hard drive and stores information there to speed up the data transfer. People started finding bits of their files in there. They claimed that Prodigy was snooping into their systems. Prodigy denied it and claimed that their software just didn't bother to clear the disk space when it allocated it, so whatever was there, stayed there until the space was used. They distributed a utility which would zero out that information. Whether they were really snooping or not, who knows? If they were, they were pretty stupid to leave clear text in the file. >My friend heard this on the trailing end of a radio talk show. If it was >really happening, it sounds horrible. Could Secure Drive be set up to >stop this kind of attack? Secure Drive would stop it if you weren't logged into the encrypted drive when you ran Prodigy. Of course, if you were logged in and they knew about Secure Drive, they could get your encryption key as well as your data... --- Mike From dave_taffs at rainbow.mentorg.com Fri Feb 4 14:25:19 1994 From: dave_taffs at rainbow.mentorg.com (Dave Taffs) Date: Fri, 4 Feb 94 14:25:19 PST Subject: request for information Message-ID: <199402042217.AA29743@fpd.MENTORG.COM> I saw the following on imp-interest, and thought somebody here might be interested in responding (perhaps?)... PS: She has David Chaum's internet address by now, I'm certain... to: imp-interest at thumper.bellcore.com from: owner-imp-interest at thumper.bellcore.com date: Fri, 4 Feb 1994 10:29:56 -0500 (EST) subj: Digicash story/Internet Letter sender: jayne levin sent: 02/04/1994 8:33 am (PDT) --------- **| I would like to explore the issue of digital cash in my next issue of The Internet Letter. I am trying to contact David Chaum but don't have his e-mail address, so I'd appreciate any help in making contact with him. I'd also like to get a grip on some of the issues involved in developing digital cash as well as the status of work in this area. Who else should I talk to? Jayne Jayne Levin Net Week Inc. Editor 220 National Press Building The Internet Letter Washington, D.C. 20045 USA +1 202 638 6020 Fax: +1 202 638 6019 From rcain at netcom.com Fri Feb 4 14:25:20 1994 From: rcain at netcom.com (Robert Cain) Date: Fri, 4 Feb 94 14:25:20 PST Subject: Running regularly In-Reply-To: <199402040708.XAA17954@jobe.shell.portal.com> Message-ID: <199402042225.OAA24297@mail.netcom.com> Hal sez: > > > Before I start throwing out ideas that I'm sure aren't new to readers here, > > I have a simple question that perhaps I should post to comp.unix.questions > > or comp.lang.perl, but.... Can I, and how would I, get a perl script to > > kick in and send out mail every few minutes when I am NOT logged in. Is this > > possible on Netcom? > > Most public Unix systems will not let you do this, in my experience. > The two Unix commands which usually give you the ability to run programs > at regular intervals are "at" and "crontab". You can read the man pages > and try running these to see if they are enabled for you. > If you run into this, there is a sneaky way to do it if you have a friend somewhere that doesn't restrict at or crontab and if your system provides elm and will will honor a .forward file. Have your friend set up a crontab that mails you a short note with some header characteristic that the filter program for elm can recognize via the filter-rules file and kick off an invocation of whatever you want to do each time it recieves one of these notes. Sneaky but it works. :-) 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 mnemonic at eff.org Fri Feb 4 14:59:57 1994 From: mnemonic at eff.org (Mike Godwin) Date: Fri, 4 Feb 94 14:59:57 PST Subject: interagency_workgroup.notice (fwd) Message-ID: <199402042256.RAA00559@eff.org> Forwarded message: From mbriceno at netcom.com Fri Feb 4 15:00:17 1994 From: mbriceno at netcom.com (Marc Briceno) Date: Fri, 4 Feb 94 15:00:17 PST Subject: Running regularly Message-ID: <199402042300.PAA18374@mail.netcom.com> Xenon askend: >> Before I start throwing out ideas that I'm sure aren't new to readers here, >> I have a simple question that perhaps I should post to comp.unix.questions >> or comp.lang.perl, but.... Can I, and how would I, get a perl script to >> kick in and send out mail every few minutes when I am NOT logged in. Is this >> possible on Netcom? Hal answered: >Most public Unix systems will not let you do this, in my experience. >The two Unix commands which usually give you the ability to run programs >at regular intervals are "at" and "crontab". You can read the man pages >and try running these to see if they are enabled for you. Netcom has a "policy against detached processes because of the load they put on the system and therfore 'crontab' and 'at' disabled for all users.(Netcom support)" To make your life even harder they kill all your processes upon hangup. Here is (half) the workaround: They forgot to disable "sleep" and they also didn't disable "nohup." You can simply write a script that sleeps for 30 min, executes your program and goes back to sleep. Call it with "nohup script &" and you're in business. The next problem that must be addressed is the auto-logout upon >14min of inactivity on the modem level that Netcom imposes on you. There is a simple 2 line command that you can add to your .login file to disable the auto-logout. I saw it once posted in one of the Netcom newsgroups, but I lost it. Perhaps you might post the question there. I would not advise to ask Netcom support for it... Some of the messages responding to the above post talked about "supending the account for intentionally disabling, blah, blah" 8-) Good luck, -- Marc Briceno PGP public key by finger From mnemonic at eff.org Fri Feb 4 15:00:19 1994 From: mnemonic at eff.org (Mike Godwin) Date: Fri, 4 Feb 94 15:00:19 PST Subject: reno_key_escrow.statement (fwd) Message-ID: <199402042259.RAA00674@eff.org> Forwarded message: From mnemonic at eff.org Fri Feb 4 15:05:17 1994 From: mnemonic at eff.org (Mike Godwin) Date: Fri, 4 Feb 94 15:05:17 PST Subject: gore_crypto.statement (fwd) Message-ID: <199402042301.SAA00879@eff.org> Forwarded message: From mnemonic at eff.org Fri Feb 4 15:05:18 1994 From: mnemonic at eff.org (Mike Godwin) Date: Fri, 4 Feb 94 15:05:18 PST Subject: harris.statement (fwd) Message-ID: <199402042300.SAA00784@eff.org> Forwarded message: From mnemonic at eff.org Fri Feb 4 15:05:21 1994 From: mnemonic at eff.org (Mike Godwin) Date: Fri, 4 Feb 94 15:05:21 PST Subject: clipper_q-and-a.txt (fwd) Message-ID: <199402042300.SAA00796@eff.org> Forwarded message: From mnemonic at eff.org Fri Feb 4 15:09:57 1994 From: mnemonic at eff.org (Mike Godwin) Date: Fri, 4 Feb 94 15:09:57 PST Subject: wh_press_secy.statement (fwd) Message-ID: <199402042301.SAA00849@eff.org> Forwarded message: From mnemonic at eff.org Fri Feb 4 15:10:17 1994 From: mnemonic at eff.org (Mike Godwin) Date: Fri, 4 Feb 94 15:10:17 PST Subject: doj_escrow_intercept.procedures (fwd) Message-ID: <199402042259.RAA00682@eff.org> Forwarded message: From mengel at dcdmwm.fnal.gov Fri Feb 4 15:29:56 1994 From: mengel at dcdmwm.fnal.gov (Marc W. Mengel) Date: Fri, 4 Feb 94 15:29:56 PST Subject: CERT advisory In-Reply-To: <9402041825.AA27913@media.mit.edu> Message-ID: <9402042327.AA43567@dcdmwm.fnal.gov> In <9402041825.AA27913 at media.mit.edu> you write: [Some items of interest to C-punks include CERT's advocacy of stopping cleartext transmission of password (no shit sherlock), and their proposed solutions, including the use of one-time passwords which I had queried about on this list a few months back. Of course they don't mention any sort of real encryption, let alone PGP. How hard would it be to build in PGP security to the transmission layer of something like FTP? Seems like a fairly simple problem, given that any site which supports anonymous FTP can publish a public key. Even if we assume that encryption would slow down the file transmission too much, we could still use it for the login/authentication part of the session... --AW] Since the command channel is flat ascii, one could extend the protocol with a pgp-password command, which would send the password encrypted in the server's public key. Similarly one could use the sort of convention that the wu-ftpd does to request encrypted files... simply request file.pgp, just like you request file.z, file.gz, etc. Of course, there really *ought* to be an RFC for it, but I'm thinking something like a command 666 PGPL -----BEGIN PGP MESSAGE----- ... -----END PGP MESSAGE----- which would send an encrypted login and password. The other piece to hack up would be the ftp client, it would have to ask for your login/password on the ftp server host, then crank that through pgp, and send an ELOGIN command down the socket -- no problem. The big issue, in my mind, is how the ftpd is going to get the key to unlock the *system's* private key... Do you compile it into the code? Should ftpd ask for it when it comes up? Marc From fnerd at smds.com Fri Feb 4 15:45:17 1994 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Fri, 4 Feb 94 15:45:17 PST Subject: STEG: a real-life use for steganography Message-ID: <9402042330.AA14310@smds.com> Eric talks about a hypothetical system S which he discussed with real acquaintance X of country C (with repressive government G), for stegging information I in through exogenously-produced CDs of indigenous music M. One problem is that S is proposed for use by lots of people in C. That means the whole system won't be a secret for long. Soon G will know not only which records and which equipment to ban, but also the passphrases for the records--so why encrypt or even camoflage it? Maybe making copies of existing popular records would help. Classics that lots of people already have. Are there already records produced for C but manufactured outside of C? Do they import music popular outside C? > -- A facility to gather the data being put on the disks. This by > itself is no trivial task, since it involves the collection of many > disparate sources. Maybe the newsgroup you mention is just the thing for the second-to- last step in the chain. It can combine efforts of people who don't have to know each other. > -- An encryption system for the arranged data. Such a system can't > treat the data as one long stream, because of the segmented nature of > the data. There's also the problem of recovering from errors on the CD. > The ability to mount the CD as a file system would be good > leverage for other programmers. > -- A decryption system to get the data off the CD. Can most CR ROM drives read the raw music format? Many? If not, can the bit stream to the ADC in a CD player be intercepted? Maybe the best hardware from a physical camoflage standpoint would be those little CDROM drives that double as "walkmen". > A system to make rememberable sentences out of an > arbitrary 128 bits (and the inverse) would be useful to facilitate > word of mouth. Isn't it good enough to always start with sentences invented by people and encode into bits? > encoding and error correction systems used in CD's. I do know that > they are not simple, being much more than bit-correcting linear codes. I think when they're not giving you exactly what you put in, they're doing desparate things like repeating the last few milliseconds. So about all you can do is put CRCs and IDs on blocks (maybe small blocks?) and be able to deal with lost and misplaced blocks. It might be useful to have signatures on block boundaries so you could recognize them out of continuous streams. Maybe you would just take two blocks worth of data and slide your buffer along one byte at a time till you got a good CRC...but by then you would have received a lot more data. Better have a long buffer. > -- A standard for the encoding of file system data onto these low > bits. This should be a separate document, even though the design of > this will be influenced by the bit encoding standard. Some adaptation > of existing file system standards may be appropriate. Here, too, you need to deal with lost blocks. Having one copy of the root of the index might not be great. Also, assuming you're using modified CD players instead of CDROM drives, you might want to take advantage of the music track structure. -fnerd quote me - - skip sweet sweetbacks badass skipjack song, jack. 3x, fast. -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE----- From nobody at shell.portal.com Fri Feb 4 15:55:19 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Fri, 4 Feb 94 15:55:19 PST Subject: For Pr0duct Cypher: faster mp_inv Message-ID: <199402042353.PAA17274@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- Pr0duct Cypher wrote: > How big should the blinding factor be? I am not sure. Right now, it is set > to the modulus minus one byte. This is certainly secure, but it takes a > long time to unblind because mp_inv is a slow operation. If you know how > long it needs to be, feel free to change it. PGP's mp_inv is needlessly slow. It works OK for the little numbers they normally use ("e" exponents) but bogs down for big numbers. Fortunately I wrote a fast version of mp_inv some time ago just for this application (blinding). You might say it is "blindingly" fast! Here it is, from my private copy of pgp source. With this you can choose anything for your blinding. You will probably want to change it to use your safemalloc. #ifdef OLD_MPINV /* Replaced by a faster routine, below */ void mp_inv(unitptr x,unitptr a,unitptr n) /* Euclid's algorithm extended to compute multiplicative inverse. Computes x such that a*x mod n = 1, where 0n, X->a, HCF->u(iminus1), U->u(i), temp->u(iplus1), * INV->v(iminus1), V->v(i), temp->v(iplus1). We rotate the assignment to temp * and INV in their 2nd block of code. */ void mp_inv(unitptr x,unitptr a,unitptr n) /* Euclid's algorithm extended to compute multiplicative inverse. Computes x such that a*x mod n = 1, where 0 0) /* if U > HCF then */ mp_init(u(iplus1),0); else { enterloop = 1; mp_move(u(iplus1),u(i)); /* temp := U */ while (mp_compare(u(iplus1),u(iminus1)) <= 0) { /* temp<=HCF */ ++shifts; mp_shift_left(u(iplus1)); /* leftshift(temp,1) */ } mp_shift_right_bits(u(iplus1),1); /* rightshift(temp,1) */ } mp_sub(u(iminus1),u(iplus1)); /* temp := HCF - temp */ mp_move(u(iplus1),u(iminus1)); i = iplus1; /* V := tempV, tempV := INV, INV := V, */ /* U := tempU, tempU := HCF, HCF := U; */ /* (All simultaneous) */ if (enterloop) { while (shifts--) mp_shift_left(v(i)); /* leftshift(V,shifts) */ mp_sub(v(iplus1),v(i)); /* temp = temp - V */ } mp_move(v(i),v(iplus1)); /* V := temp */ } while (testne(u(i),0) && mp_compare(u(i),u(iminus1))!=0); mp_move(x,v(iminus1)); if (mp_tstminus(x)) mp_add(x,n); mp_burn(u(0)); /* burn the evidence on the stack...*/ mp_burn(u(1)); mp_burn(u(2)); mp_burn(v(0)); mp_burn(v(1)); mp_burn(v(2)); #undef u #undef v } /* mp_inv */ #endif /* OLD_MPINV */ -----BEGIN PGP SIGNATURE----- Version: 2.1e iQCVAgUBLVLeoArkCJ6S8691AQH9/QP+LRZ4oXiwNTUkpK7/4uJWhvJCLHPsCNsR YXruZCgY1448DRpbNV4PCtFg/GhDqvJpsWtWOy3lFZIO9zxrDb/tsIfruIJJZr0w lpWhhY+xUJNQYuqgu69EOY2IhJPiyZ+AyMuE4uYscuxEKmAEdLm/BAypX1zNplue NdURpM+pPw4= =f7BH -----END PGP SIGNATURE----- From matthew at gandalf.rutgers.edu Fri Feb 4 16:09:57 1994 From: matthew at gandalf.rutgers.edu (Matthew Bernardini) Date: Fri, 4 Feb 94 16:09:57 PST Subject: Running regularly Message-ID: > Matthew Bernardini wrote: > > > Why not make two shell scripts, one that sleeps for so long (say 20 minutes) > > using the unix sleep command, and then calls the remailer scripts in an > > infinite while loop. This would work if you set it up as a background > > process,and you don't need to be root for it to work. Only downsides are > > that when the machine crashes you have to log back in and restart script, > > your sleep command will always be in the top window if your sys-admin > > is watching, and you have to be careful not to spawn to many processes and > > bring the system down. > > I tried this on the system here, but it killed off the process when I > logged off. > > As for starting too many processes, just don't start them... leave it > as one single process that just repeats itself indefinently with sleeps > in between. > Did the processes get killed BECAUSE you logged off ? Or did they get killed because you left a single process runnning in the background for an extended period of time and an automated script killed the job. Why not ask the sysadmin how to setup a long computational job for a couple of days ? I don't think any sysadmin would have a problem with that. Then you could find out if the jobs are killed automatically somehow. If it turns out that it was just the process that was automatically killed on a time interval, then you could easily write a script that would spawn a new process and then kill the parent. Matt From huntting at glarp.com Fri Feb 4 16:19:57 1994 From: huntting at glarp.com (Brad Huntting) Date: Fri, 4 Feb 94 16:19:57 PST Subject: CERT advisory In-Reply-To: <9402042327.AA43567@dcdmwm.fnal.gov> Message-ID: <199402050015.AA01939@misc.glarp.com> > Since the command channel is flat ascii, one could extend the protocol > with a pgp-password command, which would send the password encrypted in the > server's public key. Similarly one could use the sort of convention that > the wu-ftpd does to request encrypted files... simply request file.pgp, > just like you request file.z, file.gz, etc. There is an Internet draft (draft-ietf-cat-ftpsec-03.txt) on ftp encription and authentication extensions. I dont recall if it includes a public key method, but if not it would probably be easy to incorporate. brad From nobody at soda.berkeley.edu Fri Feb 4 16:25:18 1994 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Fri, 4 Feb 94 16:25:18 PST Subject: clipper_q-and-a.txt Message-ID: <199402050021.QAA04630@soda.berkeley.edu> Q. Who will hold the escrowed keys? A. The government. From nobody at shell.portal.com Fri Feb 4 16:30:17 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Fri, 4 Feb 94 16:30:17 PST Subject: wh_press_secy.statement Message-ID: <199402050030.QAA21462@jobe.shell.portal.com> The following is a self contradictory statement, if considered to apply for the time period of the next 20 years as the govenment's policy, and it down right PISSES ME OFF. Fuck you, government. >The Administration believes that the steps being announced today >will help provide Americans with the telecommunications security >they need without compromising the capability of law enforcement >agencies and national intelligence agencies. Today, any American can >purchase and use any type of encryption product. The >Administration does not intend to change that policy. Nor do we have >any intention of restrictiog domestic encryption or mandating the use >of a particular technology. From pmetzger at lehman.com Fri Feb 4 16:55:17 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Fri, 4 Feb 94 16:55:17 PST Subject: Food for thought Message-ID: <199402050052.TAA19116@snark> In conjunction with the latest Big Brother Chip announcements, I've dug up an article I wrote for the net a while back. Some of it seems a bit weak now, but so much of it still feels current that I decided to repost it here. ---------------------------------------------------------------------- Newsgroups: sci.crypt Subject: The Escrow Database. Summary: Expires: References: <1993Apr18.034352.19470 at news.clarkson.edu> Sender: Followup-To: Distribution: Organization: Partnership for an America Free Drug Keywords: Here is a disturbing thought. Now, we no longer live in the days of big filing cabinets. We live in the electronic age. I asked myself, how big could the escrow database get? How hard might it be to steal the whole thing, particularly were I an NSA official operating with the tacit permission of the escrow houses? (We can pretend that such will not happen, but thats naive.) Well, lets see. Ten bytes of each escrow half. Lets asume ten bytes of serial number -- in fact, I believe the serial number is smaller, but this is an order of magnitude calculation. We assume 250*10^6 as the population, and that each person has a key. I get five gigabytes for each of the two escrow databases. Fits conveniently on a single very valuable Exabyte tape. This can only get easier with time, but who cares -- I can already hold all the clipper keys in the country in my pocket on two 8mm tapes. Admittely, they will think of safeguards. They won't put the whole database on one disk, prehaps. Maybe they will throw stumbling blocks in the way. This changes nothing -- they keys will be needed every day by hundreds if not thousands of law enforcement types, so convenience will dictate that the system permit quick electronic retrieval. At some point, with or without collusion by the agencies, those exabyte tapes are going to get cut. Dorothy Denning and David Sternlight will doubtless claim this can't happen -- but we know that "can't" is a prayer, not a word that in this instance connotes realism. With two exabyte tapes in your pocket, you would hold the keys for every person's conversations in the country in your hands. Yeah, you need the "master key" two -- but thats just ten bytes of information that have to be stored an awful lot of places. Come to think of it, even if the NSA getting a copy of the database isn't a threat to you because unlike me you have no contraversial political views, consider foreign intelligence services. You know, the ones that David Sternlight wants to protect us from because of the evil industrial espionage that they do. The French apparently do have a big spying operation in friendly countries to get industrial secrets, so he isn't being completely irrational here (although why our companies couldn't use cryptosystems without back doors is left unexplained by those that point out this threat.) Presumably, foreign intelligence services can get moles into the NSA and other agencies. We have proof by example of this: its happened many times. Presumably, someday they will get their hands on some fraction of the keys. You can't avoid that sort of thing. Don't pretend that no one unauthorized will ever get their hands on the escrow databases. We crypto types are all taught something very important at the beginning of intro to cryptography -- security must depend on the easily changed key that you pick to run your system, and not on a secret. The escrow databases aren't the sorts of secrets that our teachers told us about, but they are the sort of big secrets they would lump into this category. Imagine trying to replace 100 million Clipper chips. I cannot believe that the NSA or whomever it is thats doing this doesn't realize all this already. They are too smart. There are too many of them who have made their bones in the real world. I suspect that they know precisely what they are doing -- and that what they are doing is giving us the appearance of safety so that they can continue to surveil in spite of the growth of strong cryptography. I suspect that they realize that they can't put things off forever, but they can try to delay things as long as possible. Who knows. Maybe even some of the higher ups, the inevitable bureaucratic types that rise in any organization, really do believe that this scheme might give people some security, even as their subordinates in Fort Meade wring their hands over the foolishness of it all. From hughes at ah.com Fri Feb 4 16:59:57 1994 From: hughes at ah.com (Eric Hughes) Date: Fri, 4 Feb 94 16:59:57 PST Subject: CERT advisory In-Reply-To: <9402042327.AA43567@dcdmwm.fnal.gov> Message-ID: <9402050055.AA22719@ah.com> >The big issue, in my mind, is how the ftpd is going to get the key >to unlock the *system's* private key... Do you compile it into the >code? Should ftpd ask for it when it comes up? Since active interception is not nearly so easy as passive listening, it would be appropriate to use a Diffie-Hellman key exchange in this situation. This protocol has no persistent private keys, so the issue of keeping a private key around securely is not an issue. Eric From hughes at ah.com Fri Feb 4 17:05:18 1994 From: hughes at ah.com (Eric Hughes) Date: Fri, 4 Feb 94 17:05:18 PST Subject: Running regularly In-Reply-To: Message-ID: <9402050100.AA22751@ah.com> >If it turns out that it was just the process that was automatically killed >on a time interval, then you could easily write a script that would spawn a >new process and then kill the parent. To continue the explanation, no single process would ever execute for a long time, since it would, phoenix-like, periodically die and be reborn. A clever mail filter hack could also check to see if it was still alive (say, with a socket) and then start it running again if it had stopped. Eric From koontzd at lrcs.loral.com Fri Feb 4 17:05:20 1994 From: koontzd at lrcs.loral.com (David Koontz ) Date: Fri, 4 Feb 94 17:05:20 PST Subject: No Subject Message-ID: <9402050102.AA08460@io.lrcs.loral.com> Subject: clipper_q-and-a.txt >Q. Who will hold the escrowed keys? >. The government. All this bullshit doesnot state that a court order is required, rather 'legal authorization', which means the NSA for foreign intellingence purposes without a court order. Perhaps what is needed is statuatory protection to prevent the NSA from eavesdropping on U.S. Citizens, communicating domestically, without a court order. Lets close a loop hole - no more SHAMROCK From jcook at pro-storm.metronet.com Fri Feb 4 17:09:57 1994 From: jcook at pro-storm.metronet.com (Julian Cook) Date: Fri, 4 Feb 94 17:09:57 PST Subject: Unsubscribe Message-ID: Unsubscribe me please From smb at research.att.com Fri Feb 4 17:39:57 1994 From: smb at research.att.com (smb at research.att.com) Date: Fri, 4 Feb 94 17:39:57 PST Subject: CERT advisory Message-ID: <9402050138.AA04593@toad.com> >The big issue, in my mind, is how the ftpd is going to get the key >to unlock the *system's* private key... Do you compile it into the >code? Should ftpd ask for it when it comes up? Since active interception is not nearly so easy as passive listening, it would be appropriate to use a Diffie-Hellman key exchange in this situation. This protocol has no persistent private keys, so the issue of keeping a private key around securely is not an issue. But you still have to type a password to a command that itself could have been compromised. (Not that D-H wouldn't be a tremendous help, of course.) All of the hand-held authenticators I'm familiar with require that the host -- or a dedicated, trusted, security server -- keep a secret key per user. That's not a great idea. Bellcore's S/Key doesn't, but I don't know of any hardware devices that implement it. Another possibility would be hand-held digital signature boxes that could sign a random challenge from the host. From fb at cyberg.win.net Fri Feb 4 17:45:17 1994 From: fb at cyberg.win.net (Francis Barrett) Date: Fri, 4 Feb 94 17:45:17 PST Subject: Magic Money Digicash System Message-ID: <81@cyberg.win.net> > Magic Money is a digital cash system designed for use over > electronic mail. The system is online and untraceable. Online > means that each transaction involves an exchange with a server, > to prevent double-spending. Untraceable means that it is > impossible for anyone to trace transactions, or to match a > withdrawal with a deposit, or to match two coins in any way. This is the neatest thing I have read in a long time. Where can I get one? > The client module then generates proto-coins, which are > blinded but unsigned. It produces an output file containing > Alice's coins, and the new proto-coins. > Bob mails this to the server. The server counts up Alice's > coins, checks their signatures, and checks for > double-spending. It puts the coins on the cancelled list, > signs the proto-coins, and mails them back to Bob. Bob runs > his client module on the reply message. It unblinds the > signed coins and adds them to his coin file. This completes > the transfer. A few questions. Since the client which generates the proto-coins is under the control of the consumer, the bank has no way of making sure that he is not running his own code, or that the RNG he is using is cryptographically strong, or even that he is not distributing modified client programs to other users. How does the bank deal with collisions in the 16 byte values of coins? What if the user picks the numeric values for the server to sign in a way which leaks information about the banks private key? RSA is much more secure when signing random-esque data, like a message digest, than it is when signing numbers provided to it by some outside party. Similarly, how can the consumer trust the bank's representation that money has already been spent? Surely the bank should be required to publish a list of cancelled coins and timestamps with a running MD5 hash periodically for inspection by the unwashed masses. What do you do about lost messages from the server to the client. Once coins have been recorded as spent, they cannot be redeemed again. Yet the mail message containing the new coins may have been lost in transit. --------------------------------------------------------------- Francis Barrett, F.R.C. | Thou canst not travel on the path | The Cybernetics Guild | before thou hast become the Path | fb at cyberg.win.net | itself. | --------------------------------------------------------------- From brown Fri Feb 4 14:47:38 1994 From: brown (Dan Brown) Date: Fri, 4 Feb 1994 17:47:38 -0500 Subject: clipper_q-and-a.txt Message-ID: <199402042247.RAA00190@eff.org> >From the White House ***************************************************************** Embargoed until 3:00 p.m. EST Feb. 4, 1994 QUESTIONS AND ANSWERS ABOUT THE CLINTON ADMINISTRATION'S ENCRYPTION POLICY Q. What were the findings of the encryption technology review? A. The review confirmed that sound encryption technology is needed to help ensure that digital information in both computer and telecommunications systems is protected against unauthorized disclosure or tampering. It also verified the importance of preserving the ability of law enforcement to understand encrypted communications when conducting authorized wiretaps. Key escrow technology meets these objectives. Specific decisions were made to enable federal agencies and the private sector to use the key escrow technology on a voluntary basis and to allow the export of key escrow encryption products. In addition, the Department of State will streamline export licensing procedures for products that can be exported under current regulations in order to help U.S. companies to sell their products abroad. To meet the critical need for ways to verify the author and sender of an electronic message -- something that is crucial to business applications for the National Information Infrastructure -- the federal government is committed to ensuring the availability of a royalty-free, public-domain Digital Signature Standard. Finally, an interagency working group has been established to continue to address these issues and to maintain a dialogue with industry and public interest groups. Q. Who has been consulted during this review? The Congress? Industry? What mechanism is there for continuing consultation? A. Following the President's directive announced on April 16, 1993, extensive discussions have been held with Congress, industry, and privacy rights groups on encryption issues. Formal public comment was solicited on the Escrowed Encryption Standard and on a wide variety of issues related to the review through the Computer System Security and Privacy Advisory Board. The White House Office of Science and Technology Policy and the National Security Council will chair the interagency working group. The group will seek input from the private sector both informally and through several existing advisory committees. It also will work closely with the Information Policy Committee of the Information Infrastructure Task Force, which is responsible for coordinating Administration telecommunications and information policy. Q. If national security and law enforcement interests require continued export controls of encryption, what specific benefits can U.S. encryption manufacturers expect? A. The reforms will simplify encryption product export licensing and speed the review of encryption product exports. Among other benefits, manufacturers should see expedited delivery of products, reduced shipping and reporting costs, and fewer individual license requests -- especially for small businesses that cannot afford international distributors. A personal exemption for business travellers using encryption products will eliminate delays and inconvenience when they want to take encryption products out of the U.S. temporarily. Q. Why is the key escrow standard being adopted? A. The key escrow mechanism will provide Americans and government agencies with encryption products that are more secure, more convenient, and less expensive than others readily available today -- while at the same time meeting the legitimate needs of law enforcement. Q. Will the standard be mandatory? A. No. The Administration has repeatedly stressed that the key escrow technology, and this standard, is for voluntary use by federal and other government agencies and by the private sector. The standard that is being issued only applies to federal agencies -- and it is voluntary. Does this approach expand the authority of government agencies to listen in on phone conversations? No Key escrow technology provides government agencies with no [sic] new authorities to access the content of the private conversations of Americans. Q. Will the devices be exportable? Will other devices that use the government hardware? A. Yes. After an initial review of the product, the State Department will permit the export of devices incorporating key escrow technology to most end users. One of the attractions of this technology is the protection it can give to U.S. companies operating at home and abroad. Q. Suppose a law enforcement agency is conducting a wiretap on a drug smuggling ring and intercepts a conversation encrypted using the device. What would they have to do to decipher the message? A. They would have to obtain legal authorization, normally a court order, to do the wiretap in the first place. They would then present documentation, including a certification of this authorization, to the two entities responsible for safeguarding the keys. (The key is split into component parts, which are stored separately in order to ensure the security of the key escrow system.) They then obtain the components for the keys for the device being used by the drug smugglers. The components are then combined and the message can be read. Q. Who will hold the escrowed keys? A. The Attorney General has selected two U.S. agencies to hold the escrowed key components: the Treasury Department's Automated Systems Division and the Commerce Department's National Institute of Standards and Technology. Q. How strong is the security in the device? How can I be sure how strong the security is? A. This system is more secure than many other voice encryption system readily available today. While the algorithm upon which the Escrowed Encryption Standard is based will remain classified to protect the security of the system, an independent panel of cryptography experts found that the algorithm provides significant protection. In fact, the panel concluded that it will be 36 years until the cost of breaking the algorithm will be equal to the cost of breaking the current Data Encryption Standard now being used. Q. Is there a "trap door" that would allow unauthorized access to the keys? A. No. There is no trapdoor. Q. Whose decision was it to propose this product? A. The National Security Council, the Justice Department, the Commerce Department, and other key agencies were involved in this decision. The approach has been endorsed by the President, the Vice President, and appropriate Cabinet officials. From brown Fri Feb 4 14:47:39 1994 From: brown (Dan Brown) Date: Fri, 4 Feb 1994 17:47:39 -0500 Subject: doj_escrow_intercept.procedures Message-ID: <199402042247.RAA00193@eff.org> U.S. Department of Justice Washington, D.C. 20530 February 4, 1994 AUTHORIZATION PROCEDURES FOR RELEASE OF ENCRYPTION KEY COMPONENTS IN CONJUNCTION WITH INTERCEPTS PURSUANT TO TITLE III The following are the procedures for the release of escrowed key components in conjunction with lawfully authorized interception of communications encrypted with a key-escrow encryption method. These procedures cover all electronic surveillance conducted pursuant to Title III of the Omnibus crime Control and Safe Streets Act of 1968, as amended (Title III), Title 18, United States Code, Section 2510 et seq. 1) In each case there shall be a legal authorization for the interception of wire and/or electronic communications. 2) All electronic surveillance court orders under Title III shall contain provisions authorizing after-the-fact minimization, pursuant to 18 U.S.C. 2518(5), permitting the interception and retention of coded communications, including encrypted communications. 3) In the event that federal law enforcement agents discover during the course of any lawfully authorized interception that communications encrypted with a key escrow encryption method are being utilized, they may obtain a certification from the investigative agency conducting the investigation, or the Attorney General of the United States or designee thereof. Such certification shall (a) identify the law enforcement agency or other authority conducting the interception and the person providing the certification; (b) certify that necessary legal authorization has been obtained to conduct electronic surveillance regarding these communications; (c) specify the termination date of the period for which interception has been authorized; (d) identify by docket number or other suitable method of specification the source of the authorization; (e) certify that communications covered by that authorization are being encrypted with a key-escrow encryption method; (f) specify the identifier (ID) number of the key escrow encryption chip providing such encryption; and (g) specify the serial (ID) number of the key-escrow decryption device that will be used by the law enforcement agency or other authority for decryption of the intercepted communications. 4) The agency conducting the interception shall submit this certification to each of the designated key component escrow agents. If the certification has been provided by an investigative agency, as soon thereafter as practicable, an attorney associated with the United States Attorney's Office supervising the investigation shall provide each of the key component escrow agents with written confirmation of the certification. 5) Upon receiving the certification from the requesting investigative agency, each key component escrow agent shall release the necessary key component to the requesting agency. The key components shall be provided in a manner that assures they cannot be used other than in conjunction with the lawfully authorized electronic surveillance for which they were requested. 6) Each of the key component escrow agents shall retain a copy of the certification of the requesting agency, as well as the subsequent confirmation of the United States Attorney's Office. In addition, the requesting agency shall retain a copy of the certification and provide copies to the following for retention in accordance with normal record keeping requirements: (a) the United States Attorney's Office supervising the investigation, and (b) the Department of Justice, Office of Enforcement Operations. 7) Upon, or prior to, completion of the electronic surveillance phase of the investigation, the ability of the requesting agency to decrypt intercepted communications shall terminate, and the requesting agency may not retain the key components. 8) The Department of Justice shall, in each such case, (a) ascertain the existence of authorizations for electronic surveillance in cases for which escrowed key components have been released; (b) ascertain that key components for a particular key escrow encryption chip are being used only by an investigative agency authorized to conduct electronic surveillance of communications encrypted with that chip; and (c) ascertain that, no later than the completion of the electronic surveillance phase of the investigation, the ability of the requesting agency to decrypt intercepted communications is terminated. 9) In reporting to the Administrative Office of the United States Courts pursuant to 18 U.S.C. Section 2519(2), the Assistant Attorney General for the Criminal Division shall, with respect to any order for authorized electronic surveillance for which escrowed encryption components were released and used for decryption, specifically note that fact. These procedures do not create, and are not intended to create, any substantive rights for individuals intercepted through electronic surveillance, and noncompliance with these procedures shall not provide the basis for any motion to suppress or other objection to the introduction of electronic surveillance evidence lawfully acquired. ************************************************************* U.S. Department of Justice Washington, D.C. 20530 February 4, 1994 AUTHORIZATION PROCEDURES FOR RELEASE OF ENCRYPTION KEY COMPONENTS IN CONJUNCTION WITH INTERCEPTS PURSUANT TO STATE STATUTES Key component escrow agents may only release escrowed key components to law enforcement or prosecutorial authorities for use in conjunction with lawfully authorized interception of communications encrypted with a key-escrow encryption method. These procedures apply to the release of key components to State and local law enforcement or prosecutorial authorities for use in conjunction with interceptions conducted pursuant to relevant State statutes authorizing electronic surveillance, and Title III of the Omnibus crime Control and Safe Streets Act of 1968, as amended, Title 18, United States Code, Section 2510 et seq. 1) The state or local law enforcement or prosecutorial authority must be conducting an interception of wire and/or electronic communications pursuant to lawful authorization. 2) Requests for release of escrowed key components must be submitted to the key component escrow agents by the principal prosecuting attorney of the State, or of a political subdivision thereof, responsible for the lawfully authorized electronic surveillance. 3) The principal prosecuting attorney of such State or political subdivision of such State shall submit with the request for escrowed key components a certification that shall (a) identify the law enforcement agency or other authority conducting the interception and the prosecuting attorney responsible therefor; (b) certify that necessary legal authorization for interception has been obtained to conduct electronic surveillance regarding these communications; (c) specify the termination date of the period for which interception has been authorize; (d) identify by docket number or other suitable method of specification the source of the authorization; (e) certify that communications covered by that authorization are being encrypted with a key-escrow encryption method; (f) specify the identifier (ID) number of the key escrow chip providing such encryption; and (g) specify the serial (ID) number of the key-escrow decryption device that will be used by the law enforcement agency or other authority for decryption of the intercepted communications. 4) Such certification must be submitted by the principal prosecuting attorney of that State or political subdivision to each of the designated key component escrow agents. 5) Upon receiving the certification from the principal prosecuting attorney of the State or political subdivision, each key component escrow agent shall release the necessary key component to the intercepting State or local law enforcement agency or other authority. The key components shall be provided in a manner that assures they cannot be used other than in conjunction with the lawfully authorized electronic surveillance for which they were requested. 6) Each of the key component escrow agents shall retain a copy of the certification of the principal prosecuting attorney of the State or political subdivision. In addition, such prosecuting attorney shall provide a copy of the certification to the Department of Justice, for retention in accordance with normal record keeping requirements. 7) Upon, or prior to, completion of the electronic surveillance phase of the investigation, the ability of the intercepting law enforcement agency or other authority to decrypt intercepted communications shall terminate, and the intercepting law enforcement agency or other authority may not retain the key components. 8) The Department of Justice may, in each such case, make inquiry to (a) ascertain the existence of authorizations for electronic surveillance in cases for which escrowed key components have been released; (b) ascertain that key components for a particular key escrow encryption chip are being used only by an investigative agency authorized to conduct electronic surveillance of communications encrypted with that chip; and (c) ascertain that, no later than the completion of the electronic surveillance phase of the investigation, the ability of the requesting agency to decrypt intercepted communications is terminated. 9) In reporting to the Administrative Office of the United States Courts pursuant to 18 U.S.C. Section 2519(2), the principal prosecuting attorney of a State or of a political subdivision of a State may, with respect to any order for authorized electronic surveillance for which escrowed encryption components were released and used for decryption, desire to note that fact. These procedures do not create, and are not intended to create, any substantive rights for individuals intercepted through electronic surveillance, and noncompliance with these procedures shall not provide the basis for any motion to suppress or other objection to the introduction of electronic surveillance evidence lawfully acquired. ************************************************************* U.S. Department of Justice Washington D.C. 20530 February 4, 1994 AUTHORIZATION PROCEDURES FOR RELEASE OF ENCRYPTION KEY COMPONENTS IN CONJUNCTION WITH INTERCEPTS PURSUANT TO FISA The following are the procedures for the release of escrowed key components in conjunction with lawfully authorized interception of communications encrypted with a key-escrow encryption method. These procedures cover all electronic surveillance conducted pursuant to the Foreign Intelligence Surveillance Act (FISA), Pub. L. 95-511, which appears at Title 50, U.S. Code, Section 1801 et seq. 1 ) In each case there shall be a legal authorization for the interception of wire and/or electronic communications. 2) In the event that federal authorities discover during the course of any lawfully authorized interception that communications encrypted with a key-escrow encryption method are being utilized, they may obtain a certification from an agency authorized to participate in the conduct of the interception, or from the Attorney General of the United States or designee thereof. Such certification shall (a) identify the agency participating in the conduct of the interception and the person providing the certification; to conduct electronic surveillance regarding these communications; (c) specify the termination date of the period for which interception has been authorized; (d) identify by docket number or other suitable method of specification the source of the authorization; (e) certify that communications covered by that authorization are being encrypted with a key-escrow encryption method; (f) specify the identifier (ID) number of the key escrow encryption chip providing such encryption; and (g) specify the serial (ID) number of the key-escrow decryption device that will be used by the agency participating in the conduct of the interception for decryption of the intercepted communications. 4) This certification shall be submitted to each of the designated key component escrow agents. If the certification has been provided by an agency authorized to participate in the conduct of the interception, a copy shall be provided to the Department of Justice, Office of Intelligence Policy and Review. As soon as possible, an attorney associated with that office shall provide each of the key component escrow agents with written confirmation of the certification. 5) Upon receiving the certification, each key component escrow agent shall release the necessary key component to the agency participating in the conduct of the interception. The key components shall be provided in a manner that assures they cannot be used other than in conjunction with the lawfully authorized electronic surveillance for which they were requested. 6) Each of the key component escrow agents shall retain a copy of the certification, as well as the subsequent written confirmation of the Department of Justice, Office of Intelligence Policy and Review. 7) Upon, or prior to, completion of the electronic surveillance phase of the investigation, the ability of the agency participating in the conduct of the interception to decrypt intercepted communications shall terminate, and such agency may not retain the key components. 8) The Department of Justice shall, in each such case, (a) ascertain the existence of authorizations for electronic surveillance in cases for which escrowed key components have been released; (b) ascertain that key components for a particular key escrow encryption chip are being used only by an agency authorized to participate in the conduct of the interception of communications encrypted with that chip; and (c) ascertain that, no later than the completion of the electronic surveillance phase of the investigation, the ability of the agency participating in the conduct of the interception to decrypt intercepted communications is terminated. 9) Reports to the House Permanent Select Committee on Intelligence and the Senate Select Committee on Intelligence, pursuant to Section 108 of FISA, shall, with respect to any order for authorized electronic surveillance for which escrowed encryption components were released and used for decryption, specifically note that fact. These procedures do not create, and are not intended to create, any substantive rights for individuals intercepted through electronic surveillance, and noncompliance with these procedures shall not provide the basis for any motion to suppress or other objection to the introduction of electronic surveillance evidence lawfully acquired. From brown Fri Feb 4 14:47:40 1994 From: brown (Dan Brown) Date: Fri, 4 Feb 1994 17:47:40 -0500 Subject: gore_crypto.statement Message-ID: <199402042247.RAA00195@eff.org> THE WHITE HOUSE OFFICE OF THE VICE PRESIDENT EMBARGOED UNTIL, 3: 00 PM EST CONTACT: 202/456-7035 February 4, 1994 STATEMENT OF THE VICE PRESIDENT Today's announcements on encryption represent important steps in the implementation of the Administration's policy on this critical issue. Our policy is designed to provide better encryption to individuals and businesses while ensuring that the needs of law enforcement and national security are met. Encryption is a law and order issue since it can be used by criminals to thwart wiretaps and avoid detection and prosecution. It also has huge strategic value. Encryption technology and cryptoanalysis turned the tide in the Pacific and elsewhere during World War II. [end of statement] From brown Fri Feb 4 14:47:41 1994 From: brown (Dan Brown) Date: Fri, 4 Feb 1994 17:47:41 -0500 Subject: interagency_workgroup.notice Message-ID: <199402042247.RAA00199@eff.org> >From the White House Feb. 4, 1994 ****************************************************************** WORKING GROUP ON DATA SECURITY The Administration has created a new interagency working on data security to deal with issues like encryption and digital telephony. This group will be chaired by the White House Office of Science and Technology Policy and the National Security Council and will include representatives of the agencies that have participated in Presidential Review Directive 27, which called for a comprehensive review of the impact of encryption technology and advanced digital telecomrnunications systems. Agencies participating in the new working group include the Office of Management and Budget, FBI, Department of Justice, Department of Comrnerce, National Security Agency, the Department of Treasury, and the Department of State. The group will work closely with the Inforrnation Comrnittee of the Information Infrastructure Task Force, which is responsible for coordinating Administration telecommunications and inforrnation policy. It will seek input from the private sector both informally and through groups like the National Security Telecommunications Advisory Committee and the U.S. Advisory Committee on the National Information Infrastructure. The working group will develop and irnplement Administration policies on encryption. Advanced encryption technology can provide better privacy protection for individuals, but can also thwart efforts by law enforcement agencies to use wiretaps to catch and prosecute criminals. The working group will attempt to reconcile the need of privacy and the needs of law enforcement. Last April, the Administration announced development of the Clipper chip, a new computer chip designed to provide better telecomrnunications security without compromising the ability of law enforcement to do wiretaps. The working group will work with industry to develop and apply technologies like the Clipper Chip, to evaluate possible alternatives to the Clipper Chip, and to review and refine Administration policies regarding encryption as developments warrant. In addition, the working group will coordinate Administration policies regarding digital telephony. As more and more telephone companies install high-speed, digital communications links, it becomes more and more difficult for law enforcement agencies to conduct wiretaps. The working group will work with industry to ensure that new digital telecommunications systems are designed in a way that ensures that do not prevent courtauthorized wiretaps. For more information on the interagency working group, contact Matt Heymann at NIST Public Affairs (301/975-2758), Mike Nelson at OSTP (202/395-6175), or Ray Mislock at NSC (202/395-4614). From brown Fri Feb 4 14:47:41 1994 From: brown (Dan Brown) Date: Fri, 4 Feb 1994 17:47:41 -0500 Subject: harris.statement Message-ID: <199402042247.RAA00197@eff.org> United States Department of State Washington, D.C. 20520 EMBARGOED FOR RELEASE, 3:00 PM EST, FEB. 4, 1994 Statement of Dr. Martha Harris Deputy Assistant Secretary of State for Political-Military Affairs February 4, 1994 Encryption -- Export Control Reform The Secretary of State is announcing today measures arising from the Administration's decision to reform export control procedures applicable to products incorporating encryption technology. These reforms are part of the Administration's effort to eliminate unnecessary controls and ensure efficient implementation. The reforms will simplify encryption product export licensing and speed the review of encryption product exports, thus helping U.S. manufacturers to compete more effectively in the global market. While there will be no changes in the types of equipment controlled by the Munitions List, we are announcing measures to expedite licensing. Last year the President announced an initiative to encourage U.S. manufacturers and users of encryption to take advantage of a government technology (the key-escrow chip) that provides excellent security while ensuring that the Government has a means to decode the encryption when lawfully authorized, such as when executing a court-authorized warrant in connection with a criminal investigation. At the time he announced this initiative, the President directed a comprehensive review of U.S. policy regarding domestic use and export of encryption technology. The reforms we are announcing today result from that review. The President has determined that vital U.S. national security and law enforcement interests compel maintaining appropriate control of encryption. Still, there is much that can be done to reform existing controls to ensure that they are efficiently implemented and to maintain U.S. leadership in the world market for encryption technology. Accordingly, the President has asked the Secretary of State to take immediate action to implement a number of procedural reforms. The reforms are: * License Reform: Under new licensing arrangements, encryption manufacturers will be able to ship their products from the United States directly to customers within approved regions without obtaining individual licenses for each end user. This will improve the ability of our manufacturers to provide expedited delivery of products, and to reduce shipping and tracking costs. It should also reduce the number of individual license requests, especially for small businesses that cannot afford international distributors. * Rapid review of export license applications: A significant number of encryption export license applications can be reviewed more quickly. For such exports, we have set a license turnaround goal of two working days. * Personal use exemption: We will no longer require that U.S. citizens obtain an export license prior to taking encryption products out of the U.S. temporarily for their own personal use. In the past, this requirement caused delays and inconvenience for business travellers. * Allow exports of key-escrow encryption: After initial review, key-escrow encryption products may now be exported to most end users. Additionally, key-escrow products will qualify for special licensing arrangements. These reforms should have the effect of minimizing the impact of export controls on U.S. industry. The Department of State will take all appropriate actions to ensure that these reforms are implemented as quickly as possible. The Secretary of State asks that encryption product manufacturers evaluate the impact of these reforms over the next year and provide feedback both on how the reforms have worked out and on recommendations for additional procedural reforms. The contact point for further information on these reforms is Rose Biancaniello, Office of Defense Trade Controls, Bureau of Political-Military Affairs, Department of State, (703) 875-6644. From brown Fri Feb 4 14:47:42 1994 From: brown (Dan Brown) Date: Fri, 4 Feb 1994 17:47:42 -0500 Subject: reno_key_escrow.statement Message-ID: <199402042247.RAA00201@eff.org> Department of Justice EMBARGOED FOR 3 P.M. RELEASE AG FRIDAY, FEBRUARY 4, 1994 (202) 616-2771 ATTORNEY GENERAL MAKES KEY ESCROW ENCRYPTION ANNOUNCEMENTS Attorney General Janet Reno today announced selection of the two U.S. Government entities that will hold the escrowed key components for encryption using the key escrow encryption method. At the same time, the Attorney General made public procedures under which encryption key components will be released to government agencies for decrypting communications subject to lawful wiretaps. Key Escrow Encryption (formerly referred to as Clipper Chip ) strikes an excellent balance between protection of communications privacy and protection of society. It permits the use in commercial telecommunications products of chips that provide extremely strong encryption, but can be decrypted, when necessary, by government agencies conducting legally authorized wiretaps. Decryption is accomplished by use of keys--80-bit binary numbers-- that are unique to each individual encryption chip. Each unique key is in turn split into two components, which must be recombined in order to decrypt communications. Knowing one component does not make decryption any more feasible than not knowing either one. The two escrow agents are the National Institute of Standards and Technology (NIST), a part of the Department of Commerce, and the Automated Systems Division of the Department of the Treasury. The two escrow agents were chosen because of their abilities to safeguard sensitive information, while at the same time being able to respond in a timely fashion when wiretaps encounter encrypted communications. In addition, NIST is responsible for establishing standards for protection of sensitive, unclassified information in Federal computer systems. The escrow agents will act under strict procedures, which are being made public today, that will ensure the security of the key components and govern their release for use in conjunction with lawful wiretaps. They will be responsible for holding the key components: for each chip, one agent will hold one of the key components, and the second agent will hold the other. Neither will release a key component, except to a government agency with a requirement to obtain it in connection with a lawfully authorized wiretap. The system does not change the rules under which government agencies are authorized to conduct wiretaps. When an authorized government agency encounters suspected key- escrow encryption, a written request will have to be submitted to the two escrow agents. The request will, among other things, have to identify the responsible agency and the individuals involved; certify that the agency is involved in a lawfully authorized wiretap; specify the wiretap's source of authorization and its duration; and specify the serial number of the key-escrow encryption chip being used. In every case, an attorney involved in the investigation will have to provide the escrow agents assurance that a validly authorized wiretap is being conducted. Upon receipt of a proper request, the escrow agents will transmit their respective key components to the appropriate agency. The components will be combined within a decrypt device, which only then will be able to decrypt communications protected by key- escrow encryption. When the wiretap authorization ends, the device s ability to decrypt communications using that particular chip will also be ended. The Department of Justice will, at the various stages of the process, take steps to monitor compliance with the procedures. From brown Fri Feb 4 14:47:44 1994 From: brown (Dan Brown) Date: Fri, 4 Feb 1994 17:47:44 -0500 Subject: wh_press_secy.statement Message-ID: <199402042247.RAA00203@eff.org> THE WHITE HOUSE CONTACT: 202 156-7035 OFFlCE OF THE PRESS SECRETARY EMBARGOED UNTIL 3 PM (EST) FRIDAY, February 4, 1994 STATEMENT OF THE PRESS SECRETARY Last April, the Administration announced a comprehensive interagency review of encryption technology, to be overseen by the National Security Council. Today, the Administration is taking a number of steps to implement the recommendations resulting from that review. Advanced encryption technology offers individuals and businesses an inexpensive and easy way to encode data and telephone conversations. Unfortunately, the same encryption technology that can help Americans protect business secrets and personal privacy can also be used by terrorists, drug dealers, and other criminals. In the past, Federal policies on encryption have reflected primarily the needs of law enforcement and national security. The Clinton Administration has sought to balance these needs with the needs of businesses and individuals for security and privacy. That is why, today the National Institute of Standards ant Technology (NIST) is committing to ensure a royalty-free, public-domain Digital Signature Standard. Over many years, NIST has been developing digital signature technology that would provide a way to verify the author and sender of an electronic message. Such technology will be critical for a wide range of business applications for the National Information Infrastructure. A digital signature standard will enable individuals to transact business electronically rather than having to exchange signed paper contracts. The Administration has determined that such technology should not be subject to private royalty payments, and it will be taking steps to ensure that royalties are not required for use of a digital signature. Had digital signatures been in widespread use, the recent security problems with the Intemet would have been avoided. Last April, the Administration released the Key Escrow chip (also known as the "Clipper Chip") that would provide Americans with secure telecommunications without compromising the ability of law enforcement agencies to carry out legally authorized wiretaps. Today, the Department of Commerce and the Department of Justice are taking steps to enable the use of such technology both in the U.S. and overseas. At the same time, the Administration is announcing its intent to work with industry to develop other key escrow products that might better meet the needs of individuals and industry, particularly the American computer and telecommunications industry. Specific steps being announced today include: - Approval by the Commerce Secretary of the Escrowed Encryption Standard (EES) as a voluntary Federal Informahon Processing Standard, which will enable govemment gencies to purchase the Key Escrow chip for use with telephones nd modems. The department's National Institute of Standards and Technology (NIST) will publish the standard. - Publication by the Department of Justice of procedurs for the release of escrowed keys and the announcement of NIST and the Automated Services Division of the Treasury Department as the escrow agents that will store the keys needed for decryption of communications using the Key Escrow chip. Nothing in these procedures will diminish tne existing legal and procedural requirements that protect Americans from unauthorized wiretaps. - New procedures to allow export of products containing the Key Escrow chip to most countries. In addition, the Department of State will streamline export licensing procedures for encryption products that can be exported under current export regulations in order to help American companies sell their products overseas. In the past, it could take weeks for a company to obtain an export license for encryption products, and each shipment might require a separate license. The new procedures announced today will substantially reduce administrative delays and paperwork for encryption exports. To implement the Administration's encryption policy, an interagency Working Group on Encryption and Telecommunications has been established. It will be chaired by the White House Office of Science and Technology Policy and the National Security Council and will include representatives of the Departments of Commerce, Justice, State, and Treasury as well as the FBI, the National Security Agency, the Office of Management and Budget, and the National Economic Council. This group will work with industry and public-interest groups to develop new encryption technologies and to review and refine Administration policies regarding encryption, as needed. The Administration is expanding its efforts to work with industry to improve on the Key Escrow chip, to develop key-escrow software, and to examine alternatives to the Key Escrow chip. NIST will lead these efforts and will request additional staff and resources for this purpose. We understand that many in industry would like to see all encryption products exportable. However, if encryption technology is made freely available worldwide, it would no doubt be usod extensively by terrorists, drug dealers, and other criminals to harm Americans both in the U.S. and abroad. For this reason, the Administration will continue to restrict export of the most sophisticated encryption devices, both to preserve our own foreign intelligence gathering capability and because of the concerns of our allies who fear that strong encryption technology would inhibit their law enforcement capabilities. At the same time, the Administration understands the benefits that encryption and related technologies can provide to users of computers and telecommunications networks. Indeed, many of the applications of the evolving National Information Infrastructure will require some form of encryption. That is why the Administration plans to work more closely with the private sector to develop new forms of encryption that can protect privacy and corporate secrets without undermining the ability of law-enforcement agencies to conduct legally authorized wiretaps. That is also why the Administration is committed to make available free of charge a Digital Signature Standard. The Administration believes that the steps being announced today will help provide Americans with the telecommunications security they need without compromising the capability of law enforcement agencies and national intelligence agencies. Today, any American can purchase and use any type of encryption product. The Administration does not intend to change that policy. Nor do we have any intention of restrictiog domestic encryption or mandating the use of a particular technology. From smb at research.att.com Fri Feb 4 17:49:56 1994 From: smb at research.att.com (smb at research.att.com) Date: Fri, 4 Feb 94 17:49:56 PST Subject: No Subject Message-ID: <9402050149.AA05059@toad.com> Subject: clipper_q-and-a.txt >Q. Who will hold the escrowed keys? >. The government. All this bullshit doesnot state that a court order is required, rather 'legal authorization', which means the NSA for foreign intellingence purposes without a court order. Perhaps what is needed is statuatory protection to prevent the NSA from eavesdropping on U.S. Citizens, communicating domestically, without a court order. The law already says that. The government's right to spy on non-Americans is spelled out in the Foreign Intelligence Surveillance Act, 50 USC 1801. Enforcing it is another matter, of course. I saw an AP wire story today that's illuminating. It seems that for years, members of the Tennessee Highway Patrol have been subpoenaing phone company records without proper authority. They've been using a rubber stamp with the commissioner's signature, apparently without his knowledge or consent -- which he probably wouldn't have given, since under Tennessee law the Highway Patrol can deal with crimes committed on a highway, car theft, odometer tampering, or (of course) drug dealing. The only state police agency that has such subpoena authority is the Tennessee Bureau of Investigation -- and even they're limited; the D.A. is supposed to do such things after authorization by the grand jury. And the phone company -- they complied, of course; they had no idea (they said) that the subpoenas were illegal. From nobody at shell.portal.com Fri Feb 4 18:55:19 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Fri, 4 Feb 94 18:55:19 PST Subject: KERT Advisory Message-ID: <199402050251.SAA12755@jobe.shell.portal.com> From: KERT Advisory Date: Fri, 4 Feb 94 21:14:40 EST To: kert-advisory at kremvax.su Subject: KERT Advisory - Ongoing Network Monitoring Attacks Organization: Komputer Emergency Response Team : 714-731-0699 ============================================================================= KA-94:01 KERT Advisory February 4, 1994 Ongoing Network Monitoring Attacks ----------------------------------------------------------------------------- In the past week, KERT has observed a dramatic increase in reports of intruders wishing to monitor network traffic. Systems of some service providers have been compromised, and all systems that offer remote access through normal channels are at risk. The intruders have already captured information from tens of thousands of users outside the political boundaries of the United States. The current attacks involve a network monitoring tool that uses the promiscuous mode of a specific network interface, the telephone, to capture host and user identities and data on newly established telephone sessions. In the short-term, CERT recommends that all users at all sites that offer remote access resist attempts by any persons or organizations to install Trojan-horse devices which purport to "enhance" privacy but in fact are designed to provide unauthorized access to sensitive information. While the current attack is specific to /dev/Clipper, the short-term workaround does not constitute a solution. The best long-term solution currently available for this attack is to reduce or eliminate the transmission of user data in clear-text over the network, and to reduce or eliminate the access of the intruders to the network interface design and specification process. ----------------------------------------------------------------------------- From mech Fri Feb 4 16:01:34 1994 From: mech (Stanton McCandlish) Date: Fri, 4 Feb 1994 19:01:34 -0500 (EST) Subject: Alert--Admin. names escrow agents, no compromise on Clipper - 7 files Message-ID: <199402050001.TAA02297@eff.org> EFF Press Release 04/04/94 * DISTRIBUTE WIDELY * At two briefings, Feb. 4, 1994, the Clinton Administration and various agencies gave statements before a Congressional committee, and later representatives of civil liberties organizations, industry spokespersons and privacy advocates. The Electronic Frontier Foundation's position, based on what we have seen and heard from the Administration today, is that the White House is set on a course that pursues Cold War national security and law enforcement interests to the detriment of individual privacy and civil liberties. The news is grim. The Administration is: * not backing down on Clipper * not backing down on key escrow * not backing down on selection of escrow agents * already adamant on escrowed key access procedures * not willing to elminate ITAR restrictions * hiding behind exaggerated threats of "drug dealers" and "terrorists" The material released to the industry and advocacy version of the briefing have been placed online at ftp.eff.org (long before their online availability from goverment access sites, one might add). See below for specific details. No information regarding the Congressional committee version of the briefing has been announced. EFF Director Jerry Berman, who attended the private sector meeting, reported the following: "The White House and other officials briefed industry on its Clipper chip and encryption review. While the review is not yet complete, they have reached several policy conclusions. First, Clipper will be proposed as a new Federal Information Processing Standard (FIPS) next Wednesday. [Feb. 9] It will be "vountary" for government agencies and the private sector to use. They are actively asking other vendors to jump in to make the market a Clipper market. Export licensing processes will be speeded up but export restrictions will not be lifted in the interests of national security. The reason was stated bluntly at the briefing : to frustrate competition with clipper by other powerful encryption schemes by making them difficult to market, and to "prevent" strong encryption from leaving the country thus supposedly making the job of law enforcement and intelligence more difficult. Again in the interest of national security. Of course, Clipper will be exportable but they would not comment on how other governments will view this. Treasury and NIST will be the escrow agents and Justice asserted that there was no necessity for legislation to implement the escrow procedures. "I asked if there would be a report to explain the rationale for choosing these results - we have no explanation of the Administration's thinking, or any brief in support of the results. They replied that there would be no report because they have been unable to write one, due to the complexity of the issue. "One Administation spokesperson said this was the Bosnia of Telecommunications. I asked, if this was so, how, in the absense of some policy explanation, could we know if our policy here will be as successful as our policy in Bosnia?" The announcements, authorization procedures for release of escrowed keys, and q-and-a documents from the private sector briefing are online at EFF. They are: "Statement of the [White House] Press Secretary" [White House] file://ftp.eff.org/pub/EFF/Policy/Crypto/wh_press_secy.statement "Statement of the Vice President" [very short - WH] file://ftp.eff.org/pub/EFF/Policy/Crypto/gore_crypto.statement "Attorney General Makes Key Escrow Encryption Announcements" [Dept. of Just.] file://ftp.eff.org/pub/EFF/Policy/Crypto/reno_key_escrow.statement "Authorization Procedures for Release pf Emcryption Key Components in Conjunction with Intercepts Pursuant to Title III/State Statutes/FISA" [3 docs. in one file - DoJ] file://ftp.eff.org/pub/EFF/Policy/Crypto/doj_escrow_intercept.rules "Working Group on Data Security" [WH] file://ftp.eff.org/pub/EFF/Policy/Crypto/interagency_workgroup.announce "Statement of Dr. Martha Harris Dep. Asst. Secy. of State for Polit.-Mil. Affairs: Encryption - Export Control Reform" [Dept. of State] file://ftp.eff.org/pub/EFF/Policy/Crypto/harris_export.statement "Questions and Answers about the Clinton Administration's Encryption Policy" [WH] file://ftp.eff.org/pub/EFF/Policy/Crypto/wh_crypto.q-a These files are available via anonymous ftp, or via WWW at: http://www.eff.org/ in the "EFF ftp site" menu off the front page. Gopher access: gopher://gopher.eff.org/ Look in "EFF Files"/"Papers and Testimony"/"Crypto" All 7 of these documents will be posted widely on the net immediately following this notice. -- 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 chris.replogle at ledge.com Fri Feb 4 21:15:21 1994 From: chris.replogle at ledge.com (Chris Replogle) Date: Fri, 4 Feb 94 21:15:21 PST Subject: UNSUB In-Reply-To: <01H8HO3DOA2Q95N79W@ccmail.sunysb.edu> Message-ID: Subject: UNSUB UNSUBSCRIBE From wex at media.mit.edu Fri Feb 4 21:35:20 1994 From: wex at media.mit.edu (Alan (Miburi-san) Wexelblat) Date: Fri, 4 Feb 94 21:35:20 PST Subject: CERT advisory In-Reply-To: <9402042327.AA43567@dcdmwm.fnal.gov> Message-ID: <9402050532.AA24459@media.mit.edu> My instant opinion is that the private key for a site/machine has to be held by that site/machine's administrator. Therefore, the ftpd would need to get the private key entered at startup time. --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 an53607 at anon.penet.fi All the world's a stage and most of us are desperately unrehearsed. From hughes at ah.com Fri Feb 4 21:35:22 1994 From: hughes at ah.com (Eric Hughes) Date: Fri, 4 Feb 94 21:35:22 PST Subject: IMPORTANT: unsubscription Message-ID: <9402050534.AA23137@ah.com> This is the mail I send to everyone who tries to unsubscribe by sending to the list. After I send this message, I delete it from my inbox and take no further action to that piece of mail. Read it. Eric ----------------------------------------------------------------------------- The cypherpunks list is for discussions on implementing cryptography. To mail to the whole list, send mail to cypherpunks at toad.com Every mail message sent to this address will be forwarded to everyone on the list. Make sure that the message you wish to send is appropriate for such a broad delivery. If you want to be added or removed from the cypherpunks list, or have any other questions which pertain to list management, send mail to cypherpunks-request at toad.com I don't manage the list from my regular account, so such mail which ends up in my ah.com account will just get you another copy of this file. Eric Hughes maintainer of the lists cypherpunks at toad.com and cypherpunks-announce at toad.com From Seth.Morris at lambada.oit.unc.edu Fri Feb 4 21:55:20 1994 From: Seth.Morris at lambada.oit.unc.edu (Seth Morris) Date: Fri, 4 Feb 94 21:55:20 PST Subject: Hughes' "real-life use for steganography" Message-ID: <9402050552.AA21327@lambada.oit.unc.edu> [Eric Hughes described a situation where data smuggling is required, and asks for discussion on practicle and practicable mechanisms (with appropriate and far too rare here emphasis on practicable). This is the sort of real-worldish issue I've been on this list for, so, despite my opinion that this doesn't sound like a real case, I'd like to add my thoughts.] What is needed here is not encryption, by steg, of course. Why worry about key distribution at all? If the data is being sent in bulk, it will find itself into the hands of the local Big Bro, and the transport medium will be exposed and (presumable) confiscated. This will get the M industry into trouble, and lose the transport medium. This seems more like a case for point-to-point transport to several distribution sites withis the country, where more anonymous transport must be arranged. At the very least, no industry should be placed at risk without the means to protect itself. Maybe DAT tapes of "bootleg" recordings of music M? Like Grateful Dead tapes, only edited to contain the data. This way, only certain tapes have data, and the tapes can find their way into the hands of those who can decode and distribute. Is there, within the country, a suitable transport medium that is transient and frequent? Someone suggested weather maps (sorry I forgot someone's name) but these don't seem perfect. What about scanned in art GIFs on a ntionally available network? Hmmm....... Compuserve? The problem I have with using steg as the mass-transport (other than loss of transport medium once it is discovered and loss of a cultural industry) is that it only reaches those with CD-ROMs. This is generally a small percentage of people. Some in-country transport to the technologically uneducated is necessary. This may be out of the scope of this discussion. For the initial transport, why be cross-platform? If MS-DOS machines with CD-ROM or DAT readers are acailable (or PIC's can be brought in... hmmm... anyone know how to encode a Photo-CD? "Tourist shots... Grand Canyon, Yosemite Nat'l Prak..."), there is some program on comp.binaries.ibm.pc that can encode some .com files as readable text (Not uuencode, the text IS the .com file). A simple de-stegger could be sent in this way written on a sheet of paper. Something similar could be worked out for other platforms (maybe not this simle, though). They key problem I see is regular, bulk transport of data to be distributed to a mass of people at random containing cantraband information is unlikely to sustain an information revolution. Distribution of the data to a few people who can make use of it while remaining anonymous seems more effective. Better still would be to find some way that anyone could receive ALL the information easily and untraceably, which is what I think the CD scheme was aimed at. Unfortunately, it is risky and only gets data to the privedledged few. Sorry if this rambled, I'm doing this off the top of my head and with a fever. Seth Morris (Seth.Morris at LaUNChpad.unc.edu) From mbriceno at netcom.com Fri Feb 4 22:20:00 1994 From: mbriceno at netcom.com (Marc Briceno) Date: Fri, 4 Feb 94 22:20:00 PST Subject: Running regularly Message-ID: <199402050618.WAA20365@mail.netcom.com> I wrote: >> The next problem that must be addressed is the auto-logout upon >14min of >> inactivity on the modem level that Netcom imposes on you. There is a simple >> 2 line command that you can add to your .login file to disable the >> auto-logout. I saw it once posted in one of the Netcom newsgroups, but I >> lost it. Perhaps you might post the question there. I would not advise to Ed Carp wrote: >Did you ever get an answer to this one??? I know that TMOUT in bash controls >the shell timeout - does this have an effect?? I don't know if TMOUT has anything to do with it. I posted the queston in the appropriate Netcom newsgroups and hope that the original poster will see it and send me his script. Once he does I will post it to the list. After all,there is no reason why one shouldn't be able to use one's computer for other purposes while Netcom's machine is factoring that 50 digit number ;-) -- Marc Briceno PGP public key by finger From matthew at gandalf.rutgers.edu Fri Feb 4 22:45:20 1994 From: matthew at gandalf.rutgers.edu (Matthew Bernardini) Date: Fri, 4 Feb 94 22:45:20 PST Subject: Stego for Video ? Message-ID: Have any programs been written that would allow for three dimensional stego in moving pictures ? I think this would make it a little more difficult to detect. How about more advanced graphical techniques like using a stego file as a map in a renderer ? The person who received the picture would know for instance that all the vertical walls, or all the brick surfaces, etc were stego encrypted messages. It would take some sophistication to reverse engineer the rendered picture, but necessity is the mother of invention. The actual image would not contain any specific information, but would be a disguised "envelope" for other pictures within the picture. Matt ----------------------------------------------------------------------------- | Rutgers University Computing Services Matthew Bernardini | Hill Micro/Graphics Center 7804 McCormick | Site-Manager (908) 878-0946 | 017 Hill Center | (908) 932-3129 (908) 932-4921 ----------------------------------------------------------------------------- From MIKEINGLE at delphi.com Fri Feb 4 22:45:23 1994 From: MIKEINGLE at delphi.com (Mike Ingle) Date: Fri, 4 Feb 94 22:45:23 PST Subject: ViaCrypt Encryption Hardware Message-ID: <01H8IA4ZZZBC8ZF180@delphi.com> Some interesting flyers for ViaCrypt hardware encryption devices: There are three of them. The DigiSig+ D350 is an external device which hooks up to a parallel port. The D355 is similar but hooks up to a serial port. Both of these are flat boxes that look like external modems. The D360 is an internal board, and the D150 is a software emulator. All of them do the same things: RSA, DES, and DSS. The hardware devices have tamper-resistant memory to store secret keys, which can be generated internally. ViaCrypt says the hardware boxes will support PGP soon. All of the devices are controlled by a script language. The hardware units take ISO Memory Cards. ViaCrypt PGP is also selling for $99. ViaCrypt's number is 1-800-536-2664 or 602-944-0773 --- Mike For the person who requested my PGP key: Type bits/keyID Date User ID pub 1024/569A09 1993/07/31 Mike Ingle sig 87C0C7 Edgar W. Swank sig 9C0865 W.Meredith Key fingerprint = AB B7 D7 70 4D 32 72 64 79 63 7F 05 07 1D 62 5D -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAixa6xEAAAEEAN0a4+5zXcAbvGCkhWMowzko1fjc+9Q/kWsPXPABJ1H12wmZ fvsTOlIZKsYVG9oulz6N928btkP+CBWAKEyykDSaD3/HQBpg5T3/T6CVQCCkfGJx qvdJa6OdY0f7d83o2MX2P58veYqgXuiDSL0BUtqXcF1GNeV+ra2f+EADVpoJAAUR tCFNaWtlIEluZ2xlIDxtaWtlaW5nbGVAZGVscGhpLmNvbT6JAJUCBRAtTrsZ3ic1 /dqHwMcBAYXmBACRfSLCOBa3VfIMf4IhwqqxBToNqzJuD1g9N97A6SJ7/7E4/ux+ gulv3EsQJl2SXA6tnKPaZVPdDEOwW0+I+/YyT4YkeXiu7y7bgQSjeGdiElJaMboO vNcdNUaDWBn0t3+h1B9UGE29/CyHXPGVzkh8W+mK1J+3GrrCxoIZch9RTIkAlQIF EC0hm4Q+dhgw+ZwIZQEBXxcEAKw8CGgLbYjmPPeFSvc9KGnPn10ky8ltuFwRg5zu tLN70WpkQtivHA74d4CTYroklOj//HiBlVAb04Pl31Ypug6F3PUiEZC4thlJ4BeF 3q4LJSHvD70gYZ3uzwEn/ZOqfAn79ehsVpsiCfh6haZN0oJfJpz7Tr5c1eVAyl99 ZAdb =/VCZ -----END PGP PUBLIC KEY BLOCK----- From MIKEINGLE at delphi.com Fri Feb 4 23:30:03 1994 From: MIKEINGLE at delphi.com (Mike Ingle) Date: Fri, 4 Feb 94 23:30:03 PST Subject: Looking for lost mail Message-ID: <01H8IA420KRM8ZF180@delphi.com> I lost some list mail today. Could someone please forward me the missing messages? These are the last ones I got. Everything between this and the "KERT Advisory" joke is what I lost. Thanks, Mike Some people have been asking how to run background tasks on Netcom. How about this: have your task run, then send a ping to a remailer. When the ping comes back, your .forward file will start the task back up and it can run, then ping the remailer again. From: IN%"mech at eff.org" "Stanton McCandlish" 4-FEB-1994 20:44:29.91 To: IN%"eff-board at eff.org" CC: IN%"eff-staff at eff.org", IN%"comp-org-eff-talk at cs.utexas.edu", [ everywhere ] Subj: White House crypto briefings: Clipper, FIPS, escrow agents, export From: IN%"smb at research.att.com" 4-FEB-1994 21:03:12.11 To: IN%"hughes at ah.com" CC: IN%"cypherpunks at toad.com" Subj: RE: CERT advisory From: IN%"fb at cyberg.win.net" 4-FEB-1994 21:08:15.44 To: IN%"cypherpunks at toad.com" Subj: RE: Magic Money Digicash System From hfinney at shell.portal.com Fri Feb 4 23:40:06 1994 From: hfinney at shell.portal.com (Hal) Date: Fri, 4 Feb 94 23:40:06 PST Subject: Magic Money Digicash System Message-ID: <199402050738.XAA07723@jobe.shell.portal.com> From: fb at cyberg.win.net (Francis Barrett) > > Magic Money is a digital cash system designed for use over > > electronic mail. > This is the neatest thing I have read in a long time. Where can I get > one? FTP to csn.org, cd to /mpj, read the file README.MPJ which will tell you a directory to switch to, do that, cd to pgp-tools (or pgp_tools, or pgptools, I forget which), and get magicmny.zip. Then unzip and build it. > A few questions. Since the client which generates the proto-coins is > under the control of the consumer, the bank has no way of making sure > that he is not running his own code, or that the RNG he is using is > cryptographically strong, or even that he is not distributing modified > client programs to other users. None of these things should cause major problems. At worst useless coins would be generated. Initially, users might send their coins in right away to confirm that they are OK until they get some confidence in the program. > How does the bank deal with collisions in the 16 byte values of coins? This will practially never happen if they are chosen randomly. Bad randomness could produce coins which match ones which have already been spent (if somehow your RNG got into exactly the same state as someone else's), so they would be valueless. I think the program makes you initialize a random file before using it, so just make sure you put something random there! > What if the user picks the numeric values for the server to sign in a > way which leaks information about the banks private key? RSA is much > more secure when signing random-esque data, like a message digest, > than it is when signing numbers provided to it by some outside party. I don't think there are any values you can sign which would give away a private key. Even signing "1" or "2" should be safe, I think, since the secret key is the size of the modulus. I ftp'd a paper recently mentioned on imp-interest (on "anonymous credit cards") which claimed that new cash could be generated from sets of old cash in Chaum's scheme. I don't believe this, and the ref was to a paper "in preparation" by the authors. I'll try sending them email to ask about this. > Similarly, how can the consumer trust the bank's representation that > money has already been spent? Surely the bank should be required to > publish a list of cancelled coins and timestamps with a running MD5 > hash periodically for inspection by the unwashed masses. Here is how this problem would arise. Alice has some cash, which she sends to Bob to buy something. Bob sends it to the bank to be verified and turned into fresh cash before he will send the goods to Alice. But the bank says the cash has been spent before, and Bob reports this to Alice. Alice insists that she has never spent this cash before. Now, this is like a mystery story. Who is telling the truth? Maybe Alice is lying. Maybe the bank is lying. Maybe they are both telling the truth and someone broke in and stole Alice's cash while she was sleeping, copying it from her computer and spending it before she could. Ignoring that last possibility for a minute, it is basically Alice's word against the bank's. In general, in situations like this, we often go by the reputation of the parties involved. If the bank really is cheating, there will be lots of other people like Alice, people with good reputations, who are making similar charges. This will make people stop trusting the bank. On the other hand, if Alice is cheating, this is probably not the first time. In time she will get a reputation for being untrustworthy. The idea of publishing lists of used coins is interesting but I'm not sure it helps. Double-spending could easily occur close together in time, between publication of lists. A cheating bank could claim a coin had been spent just before the actual coin came in. > What do you do about lost messages from the server to the client. > Once coins have been recorded as spent, they cannot be redeemed again. > Yet the mail message containing the new coins may have been lost in > transit. The server should re-transmit the message if it does not arive. We discussed this a while back and it appears safe for everyone in these protocols to re-transmit messages freely if the other person claims never to have gotten them. Even if they are lying, what is the harm - you are just sending them information they already have. Good questions. Hal From ld231782 at longs.lance.colostate.edu Sat Feb 5 00:45:22 1994 From: ld231782 at longs.lance.colostate.edu (L. Detweiler) Date: Sat, 5 Feb 94 00:45:22 PST Subject: SQUISH II, the SEQUEL Message-ID: <199402050840.BAA18743@longs.lance.colostate.edu> Hello, my mailbox has been awfully quiet lately from cypherpunk rants, and I need a bit of a massage at the moment, so I wanted to ask you a question. Have you considered what I was saying about preventing `abuse' of remailers? I have given you some time to formulate a plan. so-- could someone email me your new official Cypherpunk ethical guidelines for anonymous posting, involving your opinions and procedures on libel, harassment, and `violent death threats'? what's that? you don't have an official policy or any safeguards? I guess that means that `anything goes' (quite literally!) kind of a disturbing policy, because someone simultaneously very ingenious and malicious could create some major annoyances. I guess you already know that. but even the past `operations' could pale in comparison to future ones. the possibilities are really limitless. imagine what can be accomplished when no one is held accountable for what they post! why, it is a recipe for Utopia. cypherpunks, I so admire your vision of the future. BTW, I want to commend you anonymous site operators for your resilience. it does appear that the remailers are fairly secure, at least, that is the picture portrayed to `outsiders'. of course, with insiders, it is a different story. but in a certain interesting application of anonymous remailers, e.g. an enemy attacking the remailers themselves, the confidentiality of identity among `insiders' is not critical. in fact, it can be very satisfying for an enemy to strike his foe, even while the foe sees his face, but can do nothing about it because of his own predicament. even more delightful (for the attacker, that is!) is the situation where the `predicament' is not even due to the attacker, but entirely the enemy himself. in other words, the most effective and devastating tactic of guerilla warfare is to twist technology to get your enemy to shoot *himself*. From remailer at merde.dis.org Sat Feb 5 01:35:22 1994 From: remailer at merde.dis.org (remailer bogus account) Date: Sat, 5 Feb 94 01:35:22 PST Subject: He's baaaaack! Message-ID: <9402050930.AA02620@merde.dis.org> Just when you thought it was safe to go back on the internet... He's baaaaack! Remailer operators, please lock him out now, before he does whatever he is getting ready to do. Better yet, set it up so when he sends to a remailer, he gets back a hundred copies, and one gets forwarded to his sysadmin with his name on it. From catalyst-remailer at netcom.com Sat Feb 5 03:15:25 1994 From: catalyst-remailer at netcom.com (catalyst-remailer at netcom.com) Date: Sat, 5 Feb 94 03:15:25 PST Subject: Magic Money questions Message-ID: <199402051111.DAA11286@mail.netcom.com> -----BEGIN PGP SIGNED MESSAGE----- Magic Money is available from csn.org in the same directory as pgptools. Be sure to add in the fast mp_inv posted here. It speeds up the unblinding of a 1024-bit coin from 2 minutes to 3 seconds. Thanks to whoever posted that code. I will include it in the next release, as soon as some people shake down the current one for bugs. fb at cyberg.win.net wrote: >A few questions. Since the client which generates the proto-coins is >under the control of the consumer, the bank has no way of making sure >that he is not running his own code, or that the RNG he is using is >cryptographically strong, or even that he is not distributing modified >client programs to other users. If his RNG is bad, he is only hurting himself. If he gets the same coin as another person, and that coin has already been spent, his coins will bounce, costing him money. Same is true if he corrupts his packets - the server looks for the ASN string, and if it's not there, bounces the transaction. He can run his own code if he wants to. >How does the bank deal with collisions in the 16 byte values of coins? There shouldn't be any, except for deliberate double-spending. The coins are 128-bits, so you'd need 2^64 of them before the odds favor a collision. The odds of a coin collision are equal to the odds of two messages having the same PGP signature. >What if the user picks the numeric values for the server to sign in a >way which leaks information about the banks private key? RSA is much >more secure when signing random-esque data, like a message digest, >than it is when signing numbers provided to it by some outside party. This is a problem, if this attack is feasible. The coins won't spend if they don't have the proper ASN string in them, but the server has no way to see what it is signing. Can someone produce values which will reveal the private key? I've heard of attacks which involve getting signatures on factors of a message, and multiplying them to get a forged signature. These won't work here, because each coin value is signed with a different d. All you could do is multiply several invalid coins of value x to get one valid coin of the same value. But a signature leaking the private key - that is a new one for me. Please tell me about this attack. How would one prevent it without using a cut-and-choose protocol? Applied Cryptography suggests (page 106) that it is okay to dispense with the cut-and-choose portion of a blind signature in cases (such as this one) where the user is motivated not to provide a corrupted coin. The coins use different e's from the bank's PGP key, so a coin could not be used to forge a message from the bank. >Similarly, how can the consumer trust the bank's representation that >money has already been spent? Surely the bank should be required to >publish a list of cancelled coins and timestamps with a running MD5 >hash periodically for inspection by the unwashed masses. There is no punishment for double-spending. The transaction is simply thrown out. The bank, in fact, has no way to identify the customer. What could the bank hope to accomplish by claiming that a coin was already spent? It can print more coins at any time, so it has no reason to cheat. A server will have to protect its reputation by not printing too much money or otherwise making its users angry. If you want to put in an MD5, it wouldn't be hard. >What do you do about lost messages from the server to the client. >Once coins have been recorded as spent, they cannot be redeemed again. >Yet the mail message containing the new coins may have been lost in >transit. What can be done? The server can hold onto outgoing messages for a while, and can have a means of remailing those which are lost. Or the message can be mailed back to the user through two different routes, to increase the reliability of the system. But one cash-like property of digital money is that, if you lose the data, you're SOL. I don't claim the system is perfect. But it's a start, and in my opinion, that is what digicash needs right now: a start. These Clipper postings have me worried. It seems as though the government is in a big hurry to get Clipper on the market. They only have one shot at this. What needs coded now? A menu-driven PGP? Any ideas for new projects? Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVNAjcGoFIWXVYodAQHtgwP+OTFcxAbZL8uvVeBbwwn4/N1jnLGeHFRB lw7U3Y3ciESs0PBRDu1JO4hOqzpW7Ch+GkY1z+ueWD8m4+EoroacJMcTI28EKGm3 +2eV0KpQsKfcfsPCfMFVKhqBRAzcwJhFdziFbPvG9g4CU9/Huz4ff8KiSud8zdWO n8odZHk5zTs= =6Yw2 -----END PGP SIGNATURE----- From nobody at shell.portal.com Sat Feb 5 03:20:09 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Sat, 5 Feb 94 03:20:09 PST Subject: Encrypted Snail Remailer. Message-ID: <199402051120.DAA15779@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- Disclaimer: Please take this as a work of science fiction, a short monologue by the character in a novel. It is meant to stimulate discussion and to express concerns that have recently turned from vague to clear, in my mind. I have great respect for the people out here, but I can not help myself. I very much want a secure network of remailers, but I fear the problem is the design, inflexible and non-private, of the internet itself. This is dedicated to those such as Phil Zimmerman and Pr0duct Cypher, individuals who seem to see the larger picture, that which involves humanity, not just internet culture 1994. -=New Secure Remailer Service Announcement=- For discussion purposes only until I post my mailbox address and buy that 128/256MB drive ;-) ! Ultimate in remailer technology. Only slightly slower than many Cypher remailers, but much less traceable. Up to 250MB at once. Encrypt your message with the (possibly anonymous) public key of a friend or contact, signing it with your anonymous secret key. Encrypt that, along with the friend's postal address, with my public key. Put it on a new DOS or Mac floppy, or 128/256MB Optical Disk, avoiding finger prints and DNA on the postage stamp. Send it with a fake return address from a pubic mailbox to my yet to be announced post office box. I will decrypt the forwarding address on my PowerBook, not at home, and mail it from various Manhattan street mailboxes, with no return address (or one you send me). I will then securely overwrite the file from my hard disk. Of course, you can include an anonymous encrypted return address as part of your message to the recipient. The cost is $5 cash, plus $1/MB of encrypted message to cover the CPU time. Express mail would in fact be AS fast as the serious Cypher remailers, but would cost you $20 since I have to pay in cash at a post office, or get a money order to use FedEx, and then make up a fake return address if you leave one out. Until a new generation of internet remailers are produced, I make claim to my remailer service being much more secure. There is also no need keeping logs to protect my liability, since no one knows that my remailer was where it came from. One of the most serious weakness of any internet remailer is that you tell someone spying on the recipient exactly which remailer site a piece of mail came from, as well as when. I asked about faking internet mail but was told that this was "frowned upon" for internet mail. Too bad. REALLY too bad. With mine, it could be any individual in NYC, and the time of day doesn't mean much. It thus involves a lot more than a few keystrokes on the assumed NSA internet logging database to trace it back to the sender. Fairly obvious and fairly illegal spying on me and the other manual remailers out there would be required, as well as opening mailboxes before the mailman arrived. A TEMPEST attack on a PowerBook in public in different locations just isn't going to happen very often. Bugging my PowerBook isn't possible since I always carry it with me (and know what it's insides look like in detail). Secure encryption being available to the common man is what will change the world. I'm not yet convinced that internet remailers will have a similar influence unless they are able to resist the presence of full site-to-site monitoring by the government and hackers, a thing which should thus be assumed by their designers. Cryptoanarchy doesn't mean the internet. It means encryption. Given that snail mail encrypted remailing is already possible, the reason for a new, secure remailer generation isn't really security but is speed, convenience, flexibility, and cost. The same reasons for ANY use of the internet. But current serious remailers are neither fast nor convenient, and they don't have a BILLION messages going through them a day to mix your secret messages into, like postal mail DOES. They tag mail as having BEEN remailed as well. Even when ALL e-mail is encrypted you haven't done anything for anonymity until all e-mail is also REMAILED, with no logs or remailer sites appearing in the headers. E-mail is free now. Remailing needs to be free too, or what advantage has it over snail mail, given that it does the same thing? The only way I can see all mail being remailed, assuming it is already all encrypted, is if every personal e-mail account was itself a remailer. I don't see this happening unless the Cypherpunks themselves write the software for the "data highway". Otherwise I will never trust remailers since as I've said to others, I can't SEE the wires. PGP is what's happening. Digital money too. But the INTERNET, even with (centralized) remailers is just a Big Brother nationwide wiretap. So don't use wires. What is my liability, if I am a remailer and the authorities intercept a message to a gangster? None, since they don't know I remailed it. Can any internet remailer be so lucky? I could say I don't KNOW if I remailed it (no logs), even if they find a return address as encrypted in my public key; "Any one of dozens of Manhattan snail remailers could have sent it." However, if your return address IS encrypted with my public key, law enforcement can, most likely LEGALLY, demand my pass phrase. Of course they'll only know the return address using the pass phrase and secret key of the receiver. Again though, this situation is BETTER security than internet remailers, since the pass phrase for the remailer is in my head, not plain text in a perl code. They can't secretly download my memory, or at least not YET ;-). Breaking into your remailer site without a trace is conceivable though. I'd find it similarly attractive but more rewarding than dumpster diving. Commercial sites are easiest, especially small high tech companies. Are these sites TEMPEST secure? Tempest based on simple radio receivers is primitive compared to what modern spectroscopy could conceivably do, even at a distance. I'd imagine ACTIVE spectrosopies could do much more or you could actively induce a current in a given direction at a given frequency. How about having your CPU mail me its secret key and pass phrase? Things like this are only getting easier, fast. VERY fast. Another reason to not trust fixed-location centralized remailers. I don't even like the idea of personal accounts on a Unix machine. Every laptop should be an internet node, and an encrypted remailer. Only when central remailers are no longer there to attack will we have safe anonymity without using snail remailing. Hell I can't even get more than three fucking e-mails in response when I ask for INFORMATION about the existing remailers. I thank Eli and Hal, but I guess the NSA doesn't hand out info on the dozen Cypherpunk remailers IT is running. Zero knowledge (yup), reputations (lowsy or non existent except for anon.penet.fi), information markets (selling remailer pass phrases and sendmail logs), anonymous networks (snail mail only), collapse of governments (yes, but not using the existing nationwide wiretap, er... internet). Fuck, I'm sounding like Detweiler. But I'm ranting for MORE cryptoanarchy. Another internet-like standardization such as that of e-mail headers, has very sadly crept into PGP itself, weakening it as the secure encryptor. PGP 2.3a still has no "random data block" output format, in which the ONLY way to even KNOW it's a PGP message is to successfully decrypt it. I asked about this on alt.security.pgp, generated little interest, but was told a future version may have this option (just gossip). I say it should be the STANDARD. Internet-like standards should NOT be the guiding force behind CRYPTOGRAPHIC standards. Get the fuck off the internet, and write me a real encryptor. How can steganography work if it's so easy to figure out if what is extracted is an encrypted message? Given the upcoming non-voluntary second generation Clipper, steg will have to become the norm. And don't port PGP to the Mac and Windows, port it FROM them; over 100 million strong and growing. "Five to one baby." News of the revolution will not be posted. Thanks for PGP. Thanks for the CPU. Like those Cypherpunk T-shirts though! Boot up and slam dance. Kewl! Nice sig! If my remailer, the ONLY acceptably secure encrypted remailer that exists, catches on, I may add a modem feature, involving pay phones. I've already written the needed secure code (none). And remember, security begins with people, not technology, always has, always will. -=Xenon=- P.S. gosub disclaimer. -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLVM1wwSzG6zrQn1RAQF8kwP/YetocN9urSgB4X9u70ZABFeLawEkwu56 jFDWZgDG+Z/81vFkVWTC7gvfDDB4Rjy0qeEhuq187zeRJ3fKCRPkkHz7swDV3V+o RA9waKWz7tdxglkW98bJIKpC9rYp4lvtxPWgtAsLTs6b9tJqvXmp2S+OcjcyV6sE gKI25vPg5Ww= =zjED -----END PGP SIGNATURE----- From garet.jax at nitelog.com Sat Feb 5 05:45:29 1994 From: garet.jax at nitelog.com (Garet Jax) Date: Sat, 5 Feb 94 05:45:29 PST Subject: Remailers Revisited In-Reply-To: <9401230638.AA05002@terminus.us.dell.com> Message-ID: Why not set up a mailgroup (such as cypherpunks.pgp) wherein ALL messages are PGP encrypted? Once one subscribes to the group, she would receive a message containing both the standard further information about the group as well as public and PRIVATE PGP for the mail group keys to add to her PGP key ring. Then whenever she sent a message to the group remailer (cypherpunks.pgp at toad.com) it would already be PGP encrypted with the group key. And anyone who received that message would be able to open and read it because they would already have the private key for the group. The remailer could check the messages before forwarding them to the list subscribers to make sure that they are PGP encrypted. If they aren't then they wouldn't be sent... a nice side effect of this would be that the list subscribers would no longer receive those 'unsubscribe user' messages as most likely these would not have been encrypted before mailing. -Garet {Garet.Jax at nitelog.com} From garet.jax at nitelog.com Sat Feb 5 05:45:33 1994 From: garet.jax at nitelog.com (Garet Jax) Date: Sat, 5 Feb 94 05:45:33 PST Subject: how to solve this prob. In-Reply-To: <9401272306.AA26581@toad.com> Message-ID: There MUST be some way that the LISTSERV software can be modified so that a user can send an unsubscribe message to the -request line for another user. Take this Detweiler for example. If he forgets where to send his unsubscribe message and sends it to the list instead, someone could send an unsubscribe message to the proper address for him. ex: 'unsubscribe [ listname ] user at e-mail.addr' The system would note that the name of the person sending the unsubscribe message ( user1 ) was different from the one who was being unsubscribed ( user2 ) , and would, after unsubscribing user2 send a message to user2 telling him that he had been unsubscribed from the list by user1. ex: 'Dear user2, you have been unsubscribed from the Cypherpunks list by user1. If you wish to resubscribe, send a message containing...' That way, instead of the list readers bombarding the folks who send the unsubscribe requests to the list, they could simply forward the request to the proper place. Now, how do we get it implemented? From mnemonic at eff.org Sat Feb 5 07:05:37 1994 From: mnemonic at eff.org (Mike Godwin) Date: Sat, 5 Feb 94 07:05:37 PST Subject: Alert--Admin. names escrow agents, no compromise on Clipper - 7 files (fwd) Message-ID: <199402051502.KAA07424@eff.org> Forwarded message: From ravage at wixer.bga.com Sat Feb 5 07:10:14 1994 From: ravage at wixer.bga.com (Jim choate) Date: Sat, 5 Feb 94 07:10:14 PST Subject: how to solve this prob. In-Reply-To: Message-ID: <9402051453.AA02769@wixer> > > > There MUST be some way that the LISTSERV software can be modified > so that a user can send an unsubscribe message to the -request line > for another user. > > Take this Detweiler for example. If he forgets where to send his > unsubscribe message and sends it to the list instead, someone could send > an unsubscribe message to the proper address for him. ex: > > 'unsubscribe [ listname ] user at e-mail.addr' > > The system would note that the name of the person sending the > unsubscribe message ( user1 ) was different from the one who was being > unsubscribed ( user2 ) , and would, after unsubscribing user2 send a > message to user2 telling him that he had been unsubscribed from the list > by user1. ex: > > 'Dear user2, you have been unsubscribed from the Cypherpunks > list by user1. If you wish to resubscribe, send a message > containing...' > > That way, instead of the list readers bombarding the folks who send > the unsubscribe requests to the list, they could simply forward the > request to the proper place. > > Now, how do we get it implemented? > To keep this type of service from being abused there would need to be some kind of validation. At the very least the listproc should receive some form of 'ok' from the user being deleted in absentia. Otherwise the list would desolve into a morass of people unsubscribing others who annoyed them for no other reason than agravated neurosis. In general it would do nothing but double the load, further reducing bandwidth. From mnemonic at eff.org Sat Feb 5 07:40:15 1994 From: mnemonic at eff.org (Mike Godwin) Date: Sat, 5 Feb 94 07:40:15 PST Subject: your mail In-Reply-To: <9402050102.AA08460@io.lrcs.loral.com> Message-ID: <199402051538.KAA07593@eff.org> David Koontz writes: > All this bullshit doesnot state that a court order is required, rather > 'legal authorization', which means the NSA for foreign intellingence > purposes without a court order. The Foreign Intelligence Surveillance Act (FISA) requires a court order for such taps. --Mike From frissell at panix.com Sat Feb 5 08:15:34 1994 From: frissell at panix.com (Duncan Frissell) Date: Sat, 5 Feb 94 08:15:34 PST Subject: Clipper "Above the Fold" Message-ID: <199402051611.AA02906@panix.com> Clipper and the Admin decision to adopt same is reported in a front page (above the fold) article in the Saturday New York Times. Usual errors about how the "backdoor" would work and about how warrants would be required to get the keys. All the usual suspects. Good placement though. DCF --- WinQwk 2.0b#1165 From bgold at tlcnet.aps.muohio.edu Sat Feb 5 09:10:15 1994 From: bgold at tlcnet.aps.muohio.edu (Bruce Goldflies) Date: Sat, 5 Feb 94 09:10:15 PST Subject: unsubscribe Message-ID: <9402051708.AA05261@tlcnet.aps.muohio.edu> unsubscribe From klbarrus at owlnet.rice.edu Sat Feb 5 09:10:36 1994 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Sat, 5 Feb 94 09:10:36 PST Subject: MAIL: tearlines, policies Message-ID: <9402051708.AA05317@arcadien.owlnet.rice.edu> -----BEGIN PGP SIGNED MESSAGE----- Fellow cypherpunks, Hm... I'm falling further behind list mail; the day after the security situation at Rice was fixed (~2 weeks off internet) the hard disk crashed. * About remailer policies: Try to gopher site (chaos.bsu.edu) in "Anonymous Mail"/"Remailer Policies" I can only really describe what goes on at elee7h5 at rosebud, elee6ue at rosebud, and elee9sf at menudo.uh.edu. * About tearlines: There is no standard I'm aware of, although a quick and dirty trick is to place a single period in the first column. Most remailers pipe to /usr/lib/sendmail (and not "/usr/lib/sendmail -oi") so a single period will end a mail message. Try it before you rely on it to strip the rest of your message. I beleive Miron Cuperman (extropia remailer) invokes sendmail with -oi. * About old discontinued remailers: I remember another discontinued remailer ?@cs.buffalo.edu. I don't remember the name, but the student was forced to shut it down because the university said that running an anonymous remailer basically made computing resources available to non-students. * About the remailers I started/run: Remailer Fast? OpLog SysLog Subj Batch RD NL CPU Phys PGP BitB - --------- ------ ----- ------ ---- ----- -- -- --- ---- --- ---- ---------- menudo -- N SM - t1 ? Y Un H 23a ? rosebud ++/- N MQ - - - N Un M 23a ? elee9sf at menudo also accepts RIPEM encryption elee6ue at rosebud requires "digital cash" (basically random strings I made) Errors on elee9sf at menudo are forwarded klbarrus at owlnet.rice.edu where they are deleted. I still get mail at that address which is why I have it forwarded and not just dropped. Errors on rosebud are dropped Karl Barrus klbarrus at owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVPSY4OA7OpLWtYzAQHDCgQAphyqkkgHtXblB1C5OlyCPZQD2/6IQ7YD FaYOHBG+NmnUMKl1bz8T9LcDKGvUKFSLW9SmI64MOqv78HF7QIXLILPG4mQ/Yn3j +zv5WyIEMofyMWUxkkWl8G/eIdCT2nB6vGNgQ8/hvhdG4DvGSpgNlwSB8itRTRwK j5DOz+wdQeM= =u1Y6 -----END PGP SIGNATURE----- From klbarrus at owlnet.rice.edu Sat Feb 5 09:25:39 1994 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Sat, 5 Feb 94 09:25:39 PST Subject: MAIL: questionnaire Message-ID: <9402051721.AA05442@arcadien.owlnet.rice.edu> -----BEGIN PGP SIGNED MESSAGE----- bsu-cs: Run by Chael Hall. Contact at same address chaos: Run by Chael Hall. Contact at same address dis.org/merde: Run by Peter Shipley extropia: Run by Miron Cuperman Comments: not directly connected, introduces some delay menudo: Run by Karl Barrus Maching: University machine Problems policy: see policy at gopher site. Contact elee9sf at menudo.uh.edu or klbarrus at owlnet.rice.edu Software: Hal's remailer code with a few modifications by myself Security: batches incoming message, sends them out randomly at midnight. Comments: also accepts RIPEM, pads messages to 1K with random stuff (an experimental approach, Hal has code to pad inside PGP messages). History: ?? penet.fi: Run by Julf (Johan Helsingus) rebma: Run by Bill (O'Hanlon? not quite sure) Machine: privately owned Comments: not directly connected, introduces some delay History: 2nd oldest remailer rosebud: (elee7h5 at rosebud.ee.uh.edu) Run by Karl Barrus. Machine: univerisity Problems policy: see gopher site Contact klbarrus at owlnet.rice.edu Software: standard scripts Security: syslog file can be read Comments: errors are dropped History: 3rd oldest remailer rosebud: (elee6ue at rosebud.ee.uh.edu) Run by Karl Barrus. Machine: univerisity Problems policy: see gopher site Contact klbarrus at owlnet.rice.edu Software: standard scripts modified to accept cash strings Security: syslog file can be read Comments: errors are dropped Karl Barrus klbarrus at owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVPVe4OA7OpLWtYzAQFWmAP+KnsEAO+EnOvDNZQ1+leUiFz+rDheosD/ 7XaM26uMWfrCQuXaWmVtxsTPOuU1Qw3qyqCz5ah6X2mzC1GvaDd+SXGwr9LH2/3x +v/7y+PDfi7SMZluLX6qumXi5k9NPztBrbcdTWEbu04PAahshlKNWbGU/XAzc+b+ jgwUBudWPZA= =SfIz -----END PGP SIGNATURE----- From aa377 at cleveland.Freenet.Edu Sat Feb 5 09:55:37 1994 From: aa377 at cleveland.Freenet.Edu (Ken Kopin) Date: Sat, 5 Feb 94 09:55:37 PST Subject: how to solve this prob. Message-ID: <9402051752.AA09134@slc8.INS.CWRU.Edu> > > >There MUST be some way that the LISTSERV software can be modified >so that a user can send an unsubscribe message to the -request line >for another user. > >Take this Detweiler for example. If he forgets where to send his >unsubscribe message and sends it to the list instead, someone could send >an unsubscribe message to the proper address for him. ex: > > 'unsubscribe [ listname ] user at e-mail.addr' > >The system would note that the name of the person sending the >unsubscribe message ( user1 ) was different from the one who was being >unsubscribed ( user2 ) , and would, after unsubscribing user2 send a >message to user2 telling him that he had been unsubscribed from the list >by user1. ex: > > 'Dear user2, you have been unsubscribed from the Cypherpunks > list by user1. If you wish to resubscribe, send a message > containing...' > >That way, instead of the list readers bombarding the folks who send >the unsubscribe requests to the list, they could simply forward the >request to the proper place. > >Now, how do we get it implemented? > > > EEEEEEEEK! You've got to be kidding! Take this L. Detweiler guy. He sets up a script and every name that comes from toad.com gets deleted from the list. Good way to destroy the list. How many times do YOU want to resubscribe? Ken Kopin -JAFL (Just a F****** lurker) -- *** I Buy KOOL-AID Points *** |Internet: aa377 at Cleveland.Freenet.Edu 1-499 1/3 cent each. | 500-1499 1/2 cent each. |Disclaimer: It'll never stand up 1500-? 1 cent each. | in court. From rcain at netcom.com Sat Feb 5 10:20:14 1994 From: rcain at netcom.com (Robert Cain) Date: Sat, 5 Feb 94 10:20:14 PST Subject: Some stuff about Diffie-Hellman (and more :-) Message-ID: <199402051816.KAA28356@mail.netcom.com> In the Diffie-Hellman exchange there is a well-known-prime, w, and a well-knwon-modulus, m. For those interested that don't know I think it then proceeds as follows (don't have notes in front of me so please someone correct me if I'm misremembering it) where ** is the power or exponentiation operator and % is the modulus operator: 1) Bob generates a one time random prime, b, then computes B = (w ** b) % m and sends B to Carol. 2) Carol generates a one time random prime, c, then computes C = (w ** c) % m and sends C to Bob. 3) Bob generates a session key: K = (B ** c) % m 4) Carol generates a session key: K = (C ** b) % m Carol and Bob have the same K because: K == (C ** b) % m == (B ** c) % m == (w ** (b * c)) % m >From just the knowledge of B and C a snoop cannot determine b from B, within computational reason (the root modulus being as difficult as factoring), nor c from C, and because K cannot be determined from B and C without knowing b or c, she is screwed. Now, the tutorial over :-), the question is; is there a "standard" well-known-prime, w, and a "standard" well-known-modulus, m, and if not, let's define one. I suppose that PGP uses a well known pair but they are big and not easy to hand around without going through media (I think.) When defined algorithmically they might be easier to actually incorporate in a program or a product than great big numbers. If this has not been done, I propose a simply stated algorithm for finding a "standard" w and m that will allow interoperation among all future implementations of D-H as follows: Let "standard" w be the first prime found probing from the starting point w' = n!, with a well-known n that should be small. I am not sure what n should be to generate a large enough w'. Let's just say the smallest n that generates a 1000 digit number. There is a well known primality testing algorithm by Lenstra that is pretty agreed upon by the number theory crowd (I have it coded by Lenstra and more on that later.) So, let w be the first number larger than w' that passes Lenstra's primality test. Any program or device employing D-H will have this algorithm in it somewhere for generating each session specific b and c so all we need to agree on is 1000 (or whatever is decided to be a large enough prime for all practical purposes.) I leave a "standard" for m up for discussion because I don't have the material in front of me that tells the criterion for selecting strong m's and there are some considerations. I would like it to be algoritmically defined though using standard long modulus, long integer arthmetic and some small, easy to remember number. Whatcha think? Oh, for those of you that actually code this stuff like me, I have Lenstra's long integer function package in C that I "ported" from K&R to ANSI and edited and reorganized the documentation in the process. I interacted with him in that process and it is a stable and reliable package. This was a year ago so he has most likely added to it by now but this snapshot I have is very complete and has way more than is needed to do nearly anything in crypto. And it is by Lenstra himself! A cool guy BTW. The problem: I did have to make some changes to macros and sundry things to ANSIfy it and may have introduced errors. It runs his demonstration programs that are part of the package and gives the correct results and these programs exercise a good part of it, especially the areas I had to mess with. BUT: I have not had the time to sit down and look hard at a true verification suite and he doesn't have one either. So, caveat emptor, I offer this package (and the original from which it was derived) to *one* person that can put it in a relevant ftp site. Is that you, Sameer? BTW, D-H is useless across a medium in which there can be an active snoop or spoof as I guess we call him. Whit, Marty and Ron agree as of a discussion a year ago. The spoof just has a pair of boxes and separately negotiates a session with Bob and one with Carol so that clear text passes between his pair. There is no way in theory to detect the presence of our friendly spoof. :-) I've found a solution to this that is more than sufficiently secure in practice and even theoretically secure in most practical situations. I'm not sure what to do with it. I would like to retire on it though (and get a couple "voluntary income tax" liens off my back :-) and perhaps even endow some kind of institute. Actually I worry more about being retired because of it if you get my paranoid drift. I guess that is why I'm lettin' y'all know about it here first. I am also curious about how you folks here feel about someone wanting to personally benefit financially from an algorithm/protocol invention/discovery like this but I don't want nor will get into any flame war. :-( Peace, Bob -- Bob Cain rcain at netcom.com 408-354-8021 "Morality is largely a rationalization of the point you happen to occupy in the power pattern at a given time. If you're a *Have-Not* you're out to *get*, and your morality is an appeal to a law higher than man-made laws--the noblest ideals of justice and equality. When you become a *Have* then you are out to *keep* and your morality is one of law, order and the rights of property over other rights." Saul D. Alinsky 1909-1972 --------------PGP 1.0 or 2.0 public key available on request.------------------ From klbarrus at owlnet.rice.edu Sat Feb 5 10:25:38 1994 From: klbarrus at owlnet.rice.edu (Karl Lui Barrus) Date: Sat, 5 Feb 94 10:25:38 PST Subject: MAIL: Re: remailers revisted Message-ID: <9402051823.AA06395@arcadien.owlnet.rice.edu> -----BEGIN PGP SIGNED MESSAGE----- - From a few weeks ago (recently for me :-) >Given that my understanding is basically correct, why couldn't >the remailer system be set up similarly to the way IRC is? Your system sounds great. However, don't you have to be root to run the server side of things (put it in /etc/inetd.conf)? Or the alternative is to leave a process continually running listening for connections, right? Leaving a process running isn't feasible for me, even if it forks all the time (especially now with the recent security problem on owlnet). Or is there another way that an ordinary user can pull this off? If so I'd like to hear about it and work on an idea I've had for a while. Karl Barrus -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVPkGoOA7OpLWtYzAQGa0wQAnh38YhoBl8fPemQRf79y44FgEVkRXHZX eNGNkNQ28Hy7aa21ni0FDViGLtauZO2akaYncL5GLEu6LYgr+pMjHThU0li16LQL ADOO8W1xUCyLu/hrNXKmlw+fQ0UoPPm8h10tTn+6D8XFzDDPGvKglRKpTkKVMHoa geMLZSbC8yI= =sBov -----END PGP SIGNATURE----- From 73772.2614 at CompuServe.COM Sat Feb 5 10:40:15 1994 From: 73772.2614 at CompuServe.COM (Arlene Zeichner) Date: Sat, 5 Feb 94 10:40:15 PST Subject: unsub,add to announce pls Message-ID: <940205183542_73772.2614_FHC115-1@CompuServe.COM> Please unsubscribe. It's great but too technical for me. From rcain at netcom.com Sat Feb 5 10:50:16 1994 From: rcain at netcom.com (Robert Cain) Date: Sat, 5 Feb 94 10:50:16 PST Subject: doj_escrow_intercept.procedures (fwd) In-Reply-To: <199402042259.RAA00682@eff.org> Message-ID: <199402051847.KAA02401@mail.netcom.com> Wow! That procedure, if it could be verified to be followed, is almost good enough to satisfy my queasy feeling that some *very dificult* and *very publicly* accessable means of opening a back door might just not be appropriate. Even though this goes strongly against my personal interest I can envision situations where I would want them to have that ability. Imagine that it is your city that gets a terrorist nuke built in one of its basements. Truly secure and easy communication makes that a whole lot easier but then since a truly secure box is real simple to make, it sort of obviates the reasoning for trying to do the standardization anyway. Anybody who really wants absolute security will be able to get it at some price that won't be too high. :-) I would like to propose us the challenge to come up with a way utilizing this crypto technology and signatures and such to guarantee a verifiable trail whenever it is done that is available to any court of law. The implication is clear that other forms will be outlawed if this package is sold. No point in even doing it otherwise. So in case they win this one I suggest that, as Tom Lehrer talks about on his album Revisited, we "Be Prepared." :-) 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 arthurc at crl.com Sat Feb 5 10:50:38 1994 From: arthurc at crl.com (Arthur Chandler) Date: Sat, 5 Feb 94 10:50:38 PST Subject: FIRST CYPHERPUNKS VIRTUAL MEETING In-Reply-To: <9402032319.AA20066@ah.com> Message-ID: FIRST CYPHERPUNKS VIRTUAL MEETING AT BAYMOO The first cypherpunks virtual conference will be held at BayMOO on Wednesday, February 9, at 8pm PST (11 EST). To get there: telnet (or use a client) mud.crl.com 8888 Follow instructions for login. Type help for any topic when you get into the MOO. @go Cypherpunk Central to get to the main room, then type HALL to get to the conference hall. One of the virtues of this hall is that there can be large scale AND small scale discussions going on at the same time. Here, briefly, is how it works: A. People login and go the Cypherpunk Hall B. One person can assume the facilitator's chair. This allows the facilitator to set several options for the room's function. C. In one mode, the facilitator allows open conversation: any can speak, and all can be heard. D. In another mode, the facilitator sets the allowable number of speakers. Those wishing to speak must request permission from the facilitator, who can set the number anywhere from one on up. Those wishing to speak must request, and are given a place in line; when any of the current speakers yield, the next in line move up automatically to speaker status. E. BUT -- and here is the ingenious feature of this conference room-- folks can sit in any of 8 rows. If they speak while sitting in those rows and the room is in facilitated mode, only those sitting in their row can hear them. The net effect is that small conversations can take place within the larger room, but they do not interrupt the main course of the moderated discussion. F. In addition, the virtual meeting room also has a built-in [about] function. This feature allows all participants to indicate, by a bracketed phrase in front of their names, the topic under discussion. In this way, if the subject begins to drift, explicit acknowledgement of the change can be made in the [about] header. Example: agore [about clipperchips]: So you see, we really have your welfare at heart. hthoreau [about clipperchips]: I decline your help. agore [about help]: Are you arguing that the government should just let illicit operations take place unmonitored? hthoreau [about interference]: That depends... This conference hall is still beta, so be patient if buglets appear. I'll also try to put in a virtual bar for more laid-back chat. The bar will be connected to Cypherpunk Central. Just examine the bartender to see how to order drinks -- or to concoct your own. Hope to see you there! From nobody at pmantis.berkeley.edu Sat Feb 5 11:15:39 1994 From: nobody at pmantis.berkeley.edu (nobody at pmantis.berkeley.edu) Date: Sat, 5 Feb 94 11:15:39 PST Subject: Military & dependants Message-ID: <9402051912.AA21376@pmantis.berkeley.edu> Can American Military members or their family take copies of PGP or other encryption programs with them when being stationed at overseas bases? Aren't the overseas installations considered to be American soil while occupied, thus permitting such transfers? --- There can be only one! From garet.jax at nitelog.com Sat Feb 5 11:15:40 1994 From: garet.jax at nitelog.com (Garet Jax) Date: Sat, 5 Feb 94 11:15:40 PST Subject: Remailer Tearline Variant In-Reply-To: <9401312103.AA02297@toad.com> Message-ID: Eli ebrandt at jarthur.claremont.edu said: >Bill Stewart said: >> Julf's anon.penet.fi remailer cuts off anything resembling a signature, >> using the convention that a -- line (or maybe an all-dash line?) >> is a signature, since some of the common mail and news programs use that, >Picking any fixed sig marker is likely to cause problems -- notice >how often anon.penet.fi messages show up truncated due to a line of >hyphens. A more flexible possibility: allow an X-Sig-Marker: header, >which specifies a pattern/regexp to strip after. Actually, the >sig marker line itself should be stripped as well, in case it >contains identifying information. >> formal and mimeish, or a simpler '--truncate here--' sort of line >> that gets retained across remailing so additional junk doesn't accrete. >I don't see the problem you're guarding against. Could you explain? >Seems that sig elision needs to be done once, by the first hop, and >then you're home free. Actually a variation on this '--truncate here--' scheme might solve the user-selected multiple-remailer scheme that we're trying to get up here. Place the 'truncate' or '::' line at the beginning of your message, just after the last local header line. Then add routing instructions for the remailer. Then maybe another 'truncate' message followed by more routing instructions for the next remailer chosen. Then a blank line and your message. BEGIN example: From: [me] Message-Id: <[number]@[mysite]> To: hh at cicada.berkeley.edu Subject: Hi there! :: Request-Remailing-To: hh at pmantis.berkeley.edu :: Request-Remailing-To: elee7h5 at rosebud.ee.uh.edu :: Request-Remailing-To: cypherpunks at toad.com Eli ebrandt at jarthur.claremont.edu said: >Bill Stewart said: >> Julf's anon.penet.fi remailer cuts off anything resembling a signature, >> using the convention that a -- line (or maybe an all-dash line?) >> is a signature, since some of the common mail and news programs use that, ... END example Each remailer would only strip off the first 'Request-Remailing-To:' instruction in the message. The remailer would assume that anything following that was part of the message, until it reached the signature, which it would truncate. Then it would remail the new 'message' as requested. From m5 at vail.tivoli.com Sat Feb 5 11:30:19 1994 From: m5 at vail.tivoli.com (Mike McNally) Date: Sat, 5 Feb 94 11:30:19 PST Subject: doj_escrow_intercept.procedures (fwd) In-Reply-To: <199402042259.RAA00682@eff.org> Message-ID: <9402051926.AA10212@vail.tivoli.com> Robert Cain writes: > Wow! That procedure... I'm having great difficulty extracting meaning from your prose, but I think you're saying that you like that the government has escrowed keys to Clipper phones for use in "national emergencies". > Imagine that it is your city that gets a terrorist nuke built > in one of its basements. We don't have many basements in Austin. > Truly secure and easy communication makes > that a whole lot easier Makes *what* a whole lot easier, building the bomb or catching the bombers? > but then since a truly secure box is real > simple to make, Really? > it sort of obviates the reasoning for trying to do the > standardization anyway. Obviates the reasoning? I'm confused. > Anybody who really wants absolute security > will be able to get it at some price that won't be too high. :-) So what exactly are you talking about? Sounds like you're happy the government introduced Clipper because it's so easy for anyone to build secure cryptographic devices. I'm having trouble understanding this. > I would like to propose us the challenge to come up with a way > utilizing this crypto technology and signatures and such to guarantee a > verifiable trail whenever it is done that is available to any court > of law. Whenever *what* is done? Whenever somebody builds a nuclear bomb? > The implication is clear ... I suggest that, as Tom Lehrer talks about > on his album Revisited, we "Be Prepared." :-) I think we should start with, "Be Lucid." -- | 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 rcain at netcom.com Sat Feb 5 11:35:40 1994 From: rcain at netcom.com (Robert Cain) Date: Sat, 5 Feb 94 11:35:40 PST Subject: Crypto Regulation Reform Message-ID: <199402051934.LAA08528@mail.netcom.com> Mr. President, I am watching with great interest the activity with regard to cyrpto regulation and have an observation I would like to share. The following was excerpted from the Harris statement: > > The President has determined that vital U.S. national security and > law enforcement interests compel maintaining appropriate control > of encryption. Still, there is much that can be done to reform > existing controls to ensure that they are efficiently implemented > and to maintain U.S. leadership in the world market for encryption > technology. Accordingly, the President has asked the Secretary of > State to take immediate action to implement a number of procedural > reforms. The reforms are: > While I totally understand the concern here and am in sympathy with the reasoning, assuming benign adherence to the procedures, I think you are in effect jousting windmills with this attempt to control or regulate crypto. It is simply too easy to build and distribute inexpensive devices that are *truly secure*, without back doors to make it other than delusional to think that the people that we would not want to have this technology won't. A device can be made right now at lower cost than a computer modem, much lower, that could be inserted between any phone and the wall that would make it impossible, no matter what laws are in place, to tap either passively or acitively, communication that passes between two of these devices. I know how to do it, could do it and probably will just for the fun of it at least. If I can there are many others that can also. In fact I personally know several. These devices can be credit card size and even fit in a wallet. They can easily be smuggled in and will be. A black market will flourish and nothing will have been accomplished except the expenditure of a lot of futile money and creation of more crime in an inflated, lucrative market. We simply must accept that point-to-point secure communication is a part of our electronic environment and swallow the bitter pill that no matter what the valid arguments are for regulation, it is effectively not possible, so that national security and law enforcement are going to be denied, in the near future, a tool in their arsenel and will have to come up with new ways of gathering this intelligence. Please abandon this effort before we throw good money after bad and create a worse situation than we will have without it. I would like whoever processes this email to forward a copy to the following contact. > The contact point for further information on these reforms is Rose > Biancaniello, Office of Defense Trade Controls, Bureau of > Political-Military Affairs, Department of State, (703) 875-6644. Sincerely, Bob Cain -- Bob Cain rcain at netcom.com 408-354-8021 From FISHMAN%SNYFARVA.bitnet at CUNYVM.CUNY.EDU Sat Feb 5 11:45:40 1994 From: FISHMAN%SNYFARVA.bitnet at CUNYVM.CUNY.EDU (FISHMAN%SNYFARVA.bitnet at CUNYVM.CUNY.EDU) Date: Sat, 5 Feb 94 11:45:40 PST Subject: Apologies, but . . . Message-ID: <01H8J3B5YJFK8Y56KS@SNYFARVA.BITNET> I read Eric's "welcome" file several times after signing on and *know* that I sent a request to unsubscribe to the correct address; I also recall his stating that sending an unsub message here would tar and feather me as a "newbie," but . . . two attempts to unsub via the prescribed route have yielded nothing more than an additional 75 or more files from this list. I respect the effort being made but can recognize it when I'm over my head: I'm a poet not a programmer. And I need help extricating myself from this web. Thanks. Cordially, *************** Charles Fishman From rcain at netcom.com Sat Feb 5 11:45:41 1994 From: rcain at netcom.com (Robert Cain) Date: Sat, 5 Feb 94 11:45:41 PST Subject: CERT advisory In-Reply-To: <9402050055.AA22719@ah.com> Message-ID: <199402051944.LAA09776@mail.netcom.com> Eric Hughes sez: > > Since active interception is not nearly so easy as passive listening, This isn't true of anything but the aether itself or a point to point wire with integrity. In any switched or networked system with routing, active interception is trivial. That is why D-H has a lower level of applicability than generally considered. > it would be appropriate to use a Diffie-Hellman key exchange in this > situation. This protocol has no persistent private keys, so the issue > of keeping a private key around securely is not an issue. Yes, the one time key usage is an important factor in the D-H. Nothing can be determined from one session that will help in breaking another. 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 m5 at vail.tivoli.com Sat Feb 5 12:20:19 1994 From: m5 at vail.tivoli.com (Mike McNally) Date: Sat, 5 Feb 94 12:20:19 PST Subject: Crypto Regulation Reform In-Reply-To: <199402051934.LAA08528@mail.netcom.com> Message-ID: <9402052019.AA10570@vail.tivoli.com> Robert Cain writes: > A device can be made right now at lower cost > than a computer modem, much lower, that could be inserted between any > phone and the wall that would make it impossible, no matter what laws > are in place, to tap either passively or acitively, communication that > passes between two of these devices. I know how to do it, could do it > and probably will just for the fun of it at least. Uhh, could you tell us? Sounds like quite a breakthrough. Credit card sized? Much cheaper than a modem, like $50 maybe? And it digititizes and securely encrypts speech (full duplex?) on the fly? -- | 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 rcain at netcom.com Sat Feb 5 12:20:41 1994 From: rcain at netcom.com (Robert Cain) Date: Sat, 5 Feb 94 12:20:41 PST Subject: doj_escrow_intercept.procedures (fwd) In-Reply-To: <9402051926.AA10212@vail.tivoli.com> Message-ID: <199402052018.MAA14027@mail.netcom.com> Mike McNally sez: > > > Robert Cain writes: > > Wow! That procedure... > > I'm having great difficulty extracting meaning from your prose, but I Hmmm, others have been having that problem lately. :-) > think you're saying that you like that the government has escrowed > keys to Clipper phones for use in "national emergencies". Yes, after long consideration that, that as I said runs counter to my self interest, I had to come to the conclusion first that is was in fact desirable to have a means to tap. It should be very difficult though and verifiable. > > > Imagine that it is your city that gets a terrorist nuke built > > in one of its basements. > > We don't have many basements in Austin. :-) > > > Truly secure and easy communication makes > > that a whole lot easier > > Makes *what* a whole lot easier, building the bomb or catching the > bombers? It makes it easier for any clandestine plan to be established and carried out. This is the greatest fear they have. Arbitrary networks of people with arbitrary purposes can be securely formed world wide within the limits of the trust inherent in the people. Can you spell r e v o l u t i o n? It's not me that's paranoid, it's them. :-) > > > but then since a truly secure box is real > > simple to make, > > Really? Yep. It would take me about three months of full time effort and would be almost a single chip. I am not the only one by any means. > > > it sort of obviates the reasoning for trying to do the > > standardization anyway. > > Obviates the reasoning? I'm confused. Well, if it is as easy as I contend to make devices that are truly secure all the people that they would want to be able to monitor would undoubtedly have one. > > > Anybody who really wants absolute security > > will be able to get it at some price that won't be too high. :-) > > So what exactly are you talking about? Sounds like you're happy the > government introduced Clipper because it's so easy for anyone to build > secure cryptographic devices. I'm having trouble understanding this. No, I think now that Clipper is ultimately stupid. I do think that if it were *not* possible to easily get around it (black market probably, remember the "blue boxes" of yore :-) and not possible probably to even detect the illegal device's use (just use it as a front end to a Clipper :-), then an escrow system which was benign (I realize some think that an oxymoron) would be a good idea. > > > I would like to propose us the challenge to come up with a way > > utilizing this crypto technology and signatures and such to guarantee a > > verifiable trail whenever it is done that is available to any court > > of law. > > Whenever *what* is done? Whenever somebody builds a nuclear bomb? Whenever they use whatever process they may set up to allow back door entry. I'm wondering if something analogous to a paper trail could be guaranteed using our technology. I don't know if that is possible but have an inkling that it is. > > > The implication is clear ... I suggest that, as Tom Lehrer talks about > > on his album Revisited, we "Be Prepared." :-) > > I think we should start with, "Be Lucid." Or learn to write better. I'm workin' on it. :-) 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 mg5n+ at andrew.cmu.edu Sat Feb 5 12:25:41 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Sat, 5 Feb 94 12:25:41 PST Subject: Info on anonymous remailers Message-ID: I am pleased to report on the performance of our two newest remailers, qwerty at netcom.com and nate at vis.colostate.edu. Both remailers had a very good response time. Here are the latest ping-times: Ping messages sent at Thu, 3 Feb 1994 17:49:24 -0500 (EST). Replies received: nobody at shell.portal.com 17:50:19 (+0:00:55) nobody at vangogh.VIS.ColoState.EDU 17:50:29 (+0:01:05) nobody at rosebud.ee.uh.edu 17:50:31 (+0:01:07) qwerty-remailer at netcom.com 17:50:33 (+0:01:09) catalyst-remailer at netcom.com 17:50:33 (+0:01:09) nowhere at bsu-cs.bsu.edu 17:50:40 (+0:01:16) remailer-admin at chaos.bsu.edu 17:50:48 (+0:01:24) nobody at pmantis.berkeley.edu 17:51:08 (+0:01:44) nobody at soda.berkeley.edu 17:51:26 (+0:02:02) remailer at dis.org 18:27:51 (+0:38:27) nobody at cicada.berkeley.edu 18:28:05 (+0:38:41) nobody at jarthur.Claremont.EDU 20:54:25 (+3:05:01) The addresses of the above remailers are: hfinney at shell.portal.com catalyst at netcom.com elee7h5 at rosebud.ee.uh.edu nowhere at bsu-cs.bsu.edu remailer at chaos.bsu.edu hh at cicada.berkeley.edu hh at pmantis.berkeley.edu hh at soda.berkeley.edu ebrandt at jarthur.claremont.edu remailer at merde.dis.org qwerty at netcom.com nate at vis.colostate.edu This test did not include any of the special-purpose anonymous remailers. For a complete list of remailers, send mail to mg5n+remailers at andrew.cmu.edu. You will receive an automated reply. From hayden at krypton.mankato.msus.edu Sat Feb 5 13:35:46 1994 From: hayden at krypton.mankato.msus.edu (Robert A. Hayden) Date: Sat, 5 Feb 94 13:35:46 PST Subject: FIRST CYPHERPUNKS VIRTUAL MEETING In-Reply-To: Message-ID: Is a MOO really the best method to carry out the virtual meeting? My expierience has been that they are most unfriendly, espicially if you are clientless. I'd think a series of IRC channels would work better, but maybe I'm wrong. ____ Robert A. Hayden <=> hayden at krypton.mankato.msus.edu \ /__ -=-=-=-=- <=> -=-=-=-=- \/ / Finger for Geek Code Info <=> In the United States, they \/ Finger for PGP 2.3a Public Key <=> first came for us in Colorado... -=-=-=-=-=-=-=- (GEEK CODE 1.0.1) GAT d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++ n-(---) h+(*) f+ g+ w++ t++ r++ y+(*) From hfinney at shell.portal.com Sat Feb 5 14:05:45 1994 From: hfinney at shell.portal.com (Hal) Date: Sat, 5 Feb 94 14:05:45 PST Subject: Some stuff about Diffie-Hellman (and more :-) Message-ID: <199402052205.OAA06854@jobe.shell.portal.com> Quite a few misconceptions here, I'm afraid: From: rcain at netcom.com (Robert Cain) > In the Diffie-Hellman exchange there is a well-known-prime, w, and a > well-knwon-modulus, m. w is supposed to be a "generator" of the group of integers mod m. It does not have to be prime. It is supposed to be such that the series w**0, w**1, w**2,...,w**m-1 does not repeat but goes through all the integers less than m. Testing for such w's is pretty easy if you know the factorization of m, involving a few arithmetic tests. > For those interested that don't know I think > it then proceeds as follows (don't have notes in front of me so please > someone correct me if I'm misremembering it) where ** is the power or > exponentiation operator and % is the modulus operator: > > 1) Bob generates a one time random prime, b, then computes b does not have to be prime; it is a random number less than m. > B = (w ** b) % m > and sends B to Carol. > > 2) Carol generates a one time random prime, c, then computes Likewise, c does not have to be prime; it is a random number less than m. > C = (w ** c) % m > and sends C to Bob. > > 3) Bob generates a session key: Carol does this, not Bob. > K = (B ** c) % m > > 4) Carol generates a session key: Bob does this, not Carol. > K = (C ** b) % m >[...] > Now, the tutorial over :-), the question is; is there a "standard" > well-known-prime, w, and a "standard" well-known-modulus, m, and if ^^^^^-- generator > not, let's define one. I don't think there is a need for this. The two sides need to agree on a pair but they could just pick it at the beginning. If everyone uses the same m,w it would help attackers of the scheme to focus their efforts on these numbers. I believe there was some discussion of using well-known numbers in the Digital Signature Standard (which is based on the same problem as DH) but I don't know what the resolution was. > I suppose that PGP uses a well known pair but > they are big and not easy to hand around without going through media (I > think.) PGP does not uses DH and has no well known numbers. If you do want well known numbers, I really think it will not be that bad just to put them into the program. Coming up with an algorithm to choose and test a generator from scratch is probably going to be larger and certainly going to be far slower than just hard-wiring the number in. Hal From smb at research.att.com Sat Feb 5 14:35:45 1994 From: smb at research.att.com (smb at research.att.com) Date: Sat, 5 Feb 94 14:35:45 PST Subject: Some stuff about Diffie-Hellman (and more :-) Message-ID: <9402052233.AA04867@toad.com> In the Diffie-Hellman exchange there is a well-known-prime, w, and a well-knwon-modulus, m. For those interested that don't know I think it then proceeds as follows (don't have notes in front of me so please someone correct me if I'm misremembering it) where ** is the power or exponentiation operator and % is the modulus operator: 1) Bob generates a one time random prime, b, then computes B = (w ** b) % m and sends B to Carol. 2) Carol generates a one time random prime, c, then computes C = (w ** c) % m and sends C to Bob. 3) Bob generates a session key: K = (B ** c) % m 4) Carol generates a session key: K = (C ** b) % m Carol and Bob have the same K because: K == (C ** b) % m == (B ** c) % m == (w ** (b * c)) % m >From just the knowledge of B and C a snoop cannot determine b from B, within computational reason (the root modulus being as difficult as factoring), nor c from C, and because K cannot be determined from B and C without knowing b or c, she is screwed. Close, but not quite. The modulus m should be primed for best results. Some folks have used a power of 2 for m, since that makes the modulus operation easier, but it also makes cracking it easier, for comparable sizes. Next, the base w should be a primitive root of the group GF(m). More seriously, your equations are subtly wrong -- Bob and Carol can't do the calculations you've given. Bob should calculate (C**b)%m -- he knows b and C, but doesn't know c. Similarly, Carol calculates (B**c)%m. Now, the tutorial over :-), the question is; is there a "standard" well-known-prime, w, and a "standard" well-known-modulus, m, and if not, let's define one. I suppose that PGP uses a well known pair but they are big and not easy to hand around without going through media (I think.) When defined algorithmically they might be easier to actually incorporate in a program or a product than great big numbers. If this has not been done, I propose a simply stated algorithm for finding a "standard" w and m that will allow interoperation among all future implementations of D-H as follows: (deleted) Two problems... First, many attacks on the discrete log problem are based on massive precomputation for a known modulus. That probably isn't an issue when you get to ~1K bits (*not* digits!). Second, you need to specify things far more concretely, and in particular define the random number generation process. You can't pick w till you know m. I've found a solution to this that is more than sufficiently secure in practice and even theoretically secure in most practical situations. Well, I'd certainly be interested in hearing about it... There have been a number of mechanisms for preventing eavesdropping with DH; a lot depends on what assumptions you want to make. My attempts -- which involve the two parties sharing a weak (i.e., PIN- or password-grade secret) can be found in /dist/smb/{neke,aeke}.ps on research.att.com. There's also Rivest and Shamir's Interlock Protocol (April '84 CACM). Davies and Price suggest using it for authentication, but Mike Merritt and I showed that that doesn't work under certain circumstances. --Steve Bellovin From nobody at shell.portal.com Sat Feb 5 15:05:47 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Sat, 5 Feb 94 15:05:47 PST Subject: CypherPUNKS. Not! Message-ID: <199402052302.PAA13278@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- Disclaimer: In this essay, I explore the "punk" aspect of "Cypherpunk". I wish to provoke, but not disrespect. I am trying to learn and stir things up, and fend off a certain boredom and inertia that seems to set in when new ideas seem to be scarce, or worse, shunned. I am a fool throwing out ideas. You can learn a lot from a fool. Dedicated to Nikola Tesla and Buckminster Fuller. You ain't punks. Light rock and Muzak for you. Wouldn't want to upset an RFC standard. Oh no no, that would be FROWNED upon! We might loose our Netcom accounts. How can we download Wired and Mondo articles then? Are you crazy? Detweiler and Sternlight might narc on us, and get us in fearful trouble. We don't want trouble we just want to fit in and cruise for babes with our e-money and bOING bOING ties. Please send more e-postage; your remailer account's gone dry. You got a problem; the problem is YOU. -Sid Vicious/Sex Pistols When will all remailers forge mail headers so no one knows which site's sendmail logs to subpoena or hack into? Forge Message-ID's too. Forge everything. You can do it with postal mail, legally. When will every account be a remailer? The internet SUCKS. What's the flag for PGP to output its "random data block" format? Get off the internet. Message up, to satellite, from remailer, message down to the world. No one knows who's decrypting. And besides, "What encrypted message?" God doesn't give out His sendmail logs. Wires, you can't see them. You can't trust them. If you rely on technology for your security, stop using wires. And once your remailers ARE more secure, old Uncle Sam's comin' t' pull the plug, 'cause they know where to find that CPU. I'm comin' too. Sounds like fun. I wonder what sort of sexy pass phrase you're using. What's your address? I want to send you $1. Oh, here's the address in the Thomas Register. You're out a $1. * WWW - World Wide Wiretap * Get Off the Internet and Write Us a Real Encryptor. Get Off the Internet and Write Us a Real Encryptor. Oh glee, the net loonies are sending megajoules not megabytes. Real addresses not e-addresses. Can I still hit 'd' for "diffuse"? I can't see you; I can't touch you. I want privacy. I want real friends. I want off the internet. Get Off the Internet and Write Us a Real Encryptor. -=Xenon=- Dead Kennedys / Bedtime for Democracy and other works: @SONG: Anarchy for Sale Step right up folks Anarchy for sale! T-shirts only 10 dollars Badges only 3.50 I nicked the design, never asked the band I never listen to them either Buy buy buy from Circle A Like hula hoops, it's a disposable craze Another fast-food fad to throw away CHORUS Get your anarchy for sale Anarchy for sale Anarchy for sale Sheep unite! Get your cuddly boots and studs Be sure to rebel in proper style Rebel along the paths we pick Out of fear of peer pressure we create Hey you!- Get those flyers off my wall No commie peace shit in my boutique No one here cares what that all means CHORUS Our town sucks Our scene rules To belong you must buy into it So we sold you metal spike bracelets.... C'mon let's see a good fight CHORUS @SONG: Chickenshit Conformist Punk's not dead It just deserves to die When it becomes another stale cartoon A close-minded, self-centered social club Ideas don't matter, it's who you know If the music's gotten boring It's because of the people Who want everyone to sound the same Who drive bright people out Of our so-called scene 'Til all that's left Is just a meaningless fad Hardcore formulas are dogshit Change and caring are what's real Is this a state of mind Or just another label The joy and hope of an alternative Have become its own cliche A hairstyle's not a lifestyle Imagine Sid Vicious at 35 Who needs a scene Scared to love and to feel Judging everythng By loud fast rules appeal Who played last night? "I don't know, I forgot. But diving off the stage Was a lot of fun." CHORUS So eager to please Peer pressure decrees So eager to please Peer pressure decrees Make the same old mistakes Again and again, Chickenshit conformist Like your parents What's ripped us apart even more than drugs Are the thieves and the goddamn liars Flipping people off when they share their stuff When someone falls are there any friends? Harder core than thou for a year or two Then it's time to get a real job Others stay home, it's no fun to go out When the gigs are wrecked by gangs and thugs When the thugs form bands, look who gets record deals >From New York metal labels looking to scam Who sign the most racist queerbashing bands they can find To make a buck revving kids up for war Walk tall, act small Only as tough as gang approval Unity is bullshit When it's under someone's fat boot Where's the common cause Too many factions Safely sulk in their shells Agree with us on everything Or we won't help with anythng That kind of attitude JUst makes a split grow wider Guess who's laughing while the world explodes When we're all crybabies Who fight best among ouselves CHORUS That farty old rock and roll attitude's back "It's competition, man, we wanna break big." Who needs friends when the money's good That's right, the '70s are back. Cock-rock metal's like a bad laxative It just don't move me, ya know? The music's OK when there's more ideas than solos Do we rally need the attitude too? Shedding thin skin too quickly As a fan it disappoints me Same old stupid sexist lyrics Or is Satan all you can think of? Crossover is just another word For lack of ideas Maybe what we need Are more trolls under the bridge Wil the metalheads finally learn something- Or will the punks throw away their education? No one's ever the best Once they believe their own press "Maturing" don't mean rehashing Mistakes of the past CHORUS The more things change The more they stay the same We can't grow When we won't criticize ourselves The '60s weren't all failure It's the '70s that stunk As the clock ticks we dig the same hole Music scenes ain't real life They won't get rid of the bomb Won't eliminate rape Or bring down the banks Any kind of real change Takes more time and work Than changing channels on a TV set CHORUS @SONG: Fleshdunce We're world industry's thoughtlords The entertainment wing We keep you all in line By fixing your free will Surround you with pop fantasies Just slightly out of reach To soften all the blows Of your forced daily routine We strip-mine your underground culture Take the bite out and rinse it clean Give ourselves credit for creating it Then sell it back to you At twice the price Our pool of talent vampires Has blown into your town To dazzle, sign and milk you All strictly on our own terms You think you've got a lot to say We'll change that real soon You're not a person anymore We've made you a cartoon By the time we're through remolding you You won't even recognize your face There's no end to the eager beavers Drawn the moths to our Babylon's mirage Conveyor belt of fleshdunce They all want to do the fleshdunce Conveyor belt of fleshdunce Who all want to do the fleshdance @SONG: Where Do Ya Draw the Line Seems like the more I think I know The more I find I don't Every answer opens up so many questions anarchy sounds good to me Then someone asks, "Who'd fix the sewers?" "Would the rednecks just play king Of the neighborhood?" How many liberators Really want to be dictators Every theory has its holes When real life steps in So how do we feed And make room for All the people crowded on our earth And transfer all that wealth >From the rich to those who need it CHORUS Where do ya draw the line Where do ya draw the line I'm not telling you I'm asking you Ever notice hard line radicals Can go on start trips too Where no one's pure and right Except themselves "I'm cleansed of the system." ('Cept when my amp needs electric power) Or-"The Party Line says no. Feminists can't wear fishnets." You wanna help stop war? Well, we reject your application You crack too many jokes And you eat meat What better way to turn people off Than to twist ideas for change Into one more church That forgets we're all human beings Where do ya draw the line? In Toronto someone blew up A cruise missile warhead plant 10 slightly hurt, 4 million dollars damage Why not destroy private property When it's used against you and me Is that violence Or self-defence You tell me CHORUS Turn on Tune in Cop out @SONG: PULL MY STRINGS I'm tired of self-respect I can't afford a car I wanna be a prefab superstar I wanna be a tool Don't need no soul Wanna make big money Playing rock and roll I'll make my music boring I'll play my music slow I ain't no artist I'm a businessman No ideas of my own I won't offend Or rock the boat Just sex and drugs And rock and roll Drool, drool, drool, drool, drool (etc.) My payola! Drool, drool, drool, drool, drool (etc.) My payola! You'll pay ten bucks to see me On a fifteen foot high stage Fatass bouncers kick the shit Out of kids who try to dance If my friends say I''ve lost my guts I'll laugh and say That's rock and roll But there's just one problem... Is my cock big enough Is my brain small enough For you to make me a star Give me a toot, I'll sell you my soul Pull my strings and I'll go far And when I'm rich And meet Bob Hope We'll shoot some golf And shoot some dope Is my cock big enough Is my brain small enough For you to make me a star Give me a toot, I'll sell you my soul Pull my strings and I'll go far @SONG: SHORT SONGS I love short songs. @SONG: Stealing People's Mail Words and Music by Biafra We ain't going to the party We ain't going to the game We ain't going to the disco Ain't gonna cruise down main We're stealing people's mail stealing people's mail stealing people's mail On a friday night Drivin' in the mountains Winding round and round Rummage thru your mailboxes Take your mail back to town And we got license plates, wedding gifts, tax returns Checks to politicians from real estate firms, Money, bills and cancelled checks, Pretty funny pictures of your kids We're stealing peopl's mail On a Friday night We're stealing people's mail By the pale moonlight We got grocery sackful after grocery sackful Grocery sackful after grocery sackful Grocery sackful after grocery sackful Of the private lives of you Ha Ha People say we're crazy We're sick and all alone But when we read your letters We're rolling on the floor We got more license plates, wedding gifts, tax returns Checks to politicians from real estate firms, Money, bills and cancelled checks We cut relationships with your friends We're gonna steal your mail By the pale moonlight We better not get caught We'll be drugged and shocked 'Til we come out born-again christians.... @SONG: NAZI PUNKS FUCK OFF Punk ain't no religious cult Punk means thinking for yourself You ain't hardcore cos you spike your hair When a jock still lives inside your head Nazi punks Nazi punks Nazi punks - Fuck Off! Nazi punks Nazi punks Nazi punks - Fuck Off! If you've come to fight, get outa here You ain't no better than the bouncers We ain't trying to be police When you ape the cops it ain't anarchy Nazi punks Nazi punks Nazi punks - Fuck Off! Nazi punks Nazi punks Nazi punks - Fuck Off! Ten guys jump one, what a man You fight each other, the police state wins Stab your backs when you trash our halls Trash a bank if you've got real balls You still think swastikas look cool The real nazis run your schools They're coaches, businessmen and cops In a real fourth reich you'll be the first to go Nazi punks Nazi punks Nazi punks - Fuck Off! Nazi punks Nazi punks Nazi punks - Fuck Off! You'll be the first to go You'll be the first to go You'll be the first to go Unless you think... @SONG: TERMINAL PREPPIE I go to college That makes me so cool I live in a dorm And show off by the pool I join the right clubs Just to make an impression I block out thinking It won't get me ahead My ambition in life Is to look good on paper All I want is a slot In some big corporation John Belushi's my hero I Lampoon and ape him My news of the world Comes from Sports Illustrated I'm proud of my trophies Like my empty beer cans Stacked in rows up the wall To impress all my friends No, I'm not here to learn I just want to get drunk And major in business And be taught how to fuck Win! Win! I always play to win Wanna fit in like a cog In the faceless machine (chorus) I'm a terminal terminal terminal preppie Terminal terminal terminal preppie Terminal terminal terminal terminal Terminal terminal terminal terminal I want a wife with tits Who just smiles all the time In my centerfold world Filled with Springsteen and wine Some day I'll have power Some day I'll have boats A tract in some suburb With Thanksgivings to host (chorus) I'm a terminal terminal terminal preppie Terminal terminal terminal preppie Terminal terminal terminal preppie @SONG: I AM THE OWL I am your plumber No I never went away I still bug your bedrooms And pick up everything you say It can be a boring job To monitor all day your excess talk I hear when you're drinking And cheating on your lonely wife I play tape recordings Of you to my friends at night We've got our girl in bed with you You're on candid camera We just un-elected you (chorus) I am the owl I seek out the fowl Wipe 'em away Keep America free For clean livin' folks like me If you demonstrate Angainst somebody we like I'll slip on a wig And see if I can start a riot Transform you to an angry mob All your leaders go to jail for my job But we aren't the russians Political trials are taboo We've got our secret Ways of getting rid of you Fill you full of LSD Turn you loose on a freeway (chorus) Send you spinning Send you spinning Send you spinning all over the freeway Spinning on the crowded freeway Spinning on the freeway Spinning on the freeway Spin... Spin... Spin - Lookout The Press, they never even cared Why a youth leader walked into a speeding car In ten years we'll leek the truth By then it's only so much paper Watergate hurt But nothing really ever changed A teeny bit quieter But we still play our little games We still play our little games We still play our little games We still play our little games We still play a lot of games I am the owl (chorus) -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLVPbtQSzG6zrQn1RAQHIwAP/VW6tak/NGsOeHdD57Aj1NgsGaRkJaojQ R96d91Kdh7f9n0QQiC+l3FRb+utKB6Clf2EIjnWLbG1ZGesKpRLAaKaaL3lcwHrT 8yNGuVDk4nmCHzBbI/uC+z9U6qrY7HWwjSU6fq5Gd9EpirBtmFHO8AyZtF+ZgiZe xSL7rwOdJ4U= =lMsr -----END PGP SIGNATURE----- From koontzd at lrcs.loral.com Sat Feb 5 16:05:48 1994 From: koontzd at lrcs.loral.com (David Koontz ) Date: Sat, 5 Feb 94 16:05:48 PST Subject: your mail Message-ID: <9402060000.AA09012@io.lrcs.loral.com> >David Koontz writes: >> All this bullshit doesnot state that a court order is required, rather >> 'legal authorization', which means the NSA for foreign intellingence >> purposes without a court order. >The Foreign Intelligence Surveillance Act (FISA) requires a court order >The Foreign Intelligence Surveillance Act (FISA) requires a court order >for such taps. >--Mike >From a secret court that has never (NEVER), turned down a request. From wcs at anchor.ho.att.com Sat Feb 5 18:25:48 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Sat, 5 Feb 94 18:25:48 PST Subject: Problem with some digicash applications Message-ID: <9402060224.AA04502@anchor.ho.att.com> One security hole in online digicash systems of the Chaum variety is that you _do_ need to make sure the money is only transmitted in encrypted forms not susceptible to playback attacks. (I haven't read the magic-money code yet...) The threat scenarios look like this: cash cash Alice--------------------->Bob---fast_net-----slow_net--------->Bank \ \ / \_______________________\___Eve_____________/ If Eve can read the cash either before Bob gets it or before Bob's message gets from his fast LAN across the slow part of the net to the bank, then she can occasionally spend it before Bob can. (This is especially likely if she's Bob's favorite remailer or network provider.) (On-line validation through slow remailers???) It's probably not much of a problem for radio-tollbooths, since the tollbooth(=Bob=bank) gets it as fast as Eve does. It's also not a problem if Eve can't find the cash part of a message between Alice and Bob or Bob and the bank. Unencrypted messages might let Eve subsitute her bank account for Bob's. But consider fixed-format messages of the form: RSA(Key), IDEACBC[Key](Cash,Account#) which might be commonly used by a Teller Machine or the digicash equivalent of a credit card authorization box. If Eve stomps on the Account-number bits, even though she can't break the encryption to substitute her account number for Bob's, she can substitute a random account number for Bob's. This acts as a denial-of-service attack against Bob. As a defense, either the message has to contain signatures or at least MACs for validation, and be rejected if invalid, or the format needs to make it impossible to find the account number field or to modify it without trashing the cash as well. A solution that's probably _not_ acceptible is for the Bank to return a message of the form Sign[Bank](OK,Cash,Account#) since this reveals the account number, which loses some privacy. It maybe ok to use a hash of the account number, or a nonce + the account number encrypted with the account-owner's public key. # Bill Stewart AT&T Global Information Solutions, aka NCR Corp # 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204 # email bill.stewart at pleasantonca.ncr.com billstewart at attmail.com # ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465 From qwerty-remailer at netcom.com Sat Feb 5 19:10:23 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Sat, 5 Feb 94 19:10:23 PST Subject: Military & dependants Message-ID: <199402060308.TAA28240@mail.netcom.com> Nobody asks: > Can American Military members or their family take copies of PGP > or other encryption programs with them when being stationed at > overseas bases? Aren't the overseas installations considered to > be American soil while occupied, thus permitting such transfers? I'm not sure what the ITAR rules say about export of armaments by the military; it would be nice if it were illegal :-) Also don't know if sending to American military bases overseas counts as export, especially if it involves going through non-US territory (if there is such a thing any more :-() Use of encryption technology by the military is probably subject to all sorts of rules; use for official purposes certainly is. You could probably get in major trouble for doing so without authorization, and I doubt PGP is officially approved; it's certainly not approved for classified information. Patent issues are also involved; the government is allowed to use RSA as part of the terms of the funding deals for their research, but this presumably doesn't apply to private use by government employees. On the other hand, IDEA wasn't developed with US funds, and its patent probably doesn't give the government any rights to use it. Ascom Tech probably could try to restrict it if they wanted. From wcs at anchor.ho.att.com Sat Feb 5 19:35:48 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Sat, 5 Feb 94 19:35:48 PST Subject: Magic Money questions Message-ID: <9402060330.AA05021@anchor.ho.att.com> >What does the bank hope to accomplish by claiming a coin was already spent? >It can print more coins any time, so it has no reason to cheat. If the bank issues coins in return for real money, and then refuses to accept them back, it's gained the amount of money it just ripped off. Doing this often enough to be noticed loses reputation, of course; you can sometimes get away with it if you're a government central bank and get a law made saying you no longer have to pay back silver for those paper dollar notes. On the other hand, printing extra coins doesn't get you anything, since nobody gave you any real money for them. Of course, if you can start up a big bank in remailer-space, and get lots of depositors, but nobody knows where you are, you can ignore the damage to your reputation by ripping off all your depositors at once and forwarding your email to Argentina, just as bank-embezzlers occasionally abscond with the whole pile. From hughes at ah.com Sat Feb 5 19:45:48 1994 From: hughes at ah.com (Eric Hughes) Date: Sat, 5 Feb 94 19:45:48 PST Subject: Apologies, but . . . In-Reply-To: <01H8J3B5YJFK8Y56KS@SNYFARVA.BITNET> Message-ID: <9402060344.AA17504@ah.com> Had you read the message closely, you would have read that I maintain the list by hand and do not immediately get to all requests. Eric ----------------------------------------------------------------------------- The cypherpunks list is for discussions on implementing cryptography. To mail to the whole list, send mail to cypherpunks at toad.com Every mail message sent to this address will be forwarded to everyone on the list. Make sure that the message you wish to send is appropriate for such a broad delivery. If you want to be added or removed from the cypherpunks list, or have any other questions which pertain to list management, send mail to cypherpunks-request at toad.com I don't manage the list from my regular account, so such mail which ends up in my ah.com account will just get you another copy of this file. Eric Hughes maintainer of the lists cypherpunks at toad.com and cypherpunks-announce at toad.com From hughes at ah.com Sat Feb 5 19:45:49 1994 From: hughes at ah.com (Eric Hughes) Date: Sat, 5 Feb 94 19:45:49 PST Subject: CERT advisory In-Reply-To: <199402051944.LAA09776@mail.netcom.com> Message-ID: <9402060343.AA17498@ah.com> >> Since active interception is not nearly so easy as passive listening, >This isn't true of anything but the aether itself or a point to point >wire with integrity. In any switched or networked system with routing, >active interception is trivial. Possible? Yes. Trivial? Bullshit. It's all economics, and the resources required to intercept packets and spoof protocols is significantly greater than that merely to watch packets go by. There are many fewer people with these greater resources, which include access to routers. Both active and passive attacks are possible in a packet forwarding system. Merely because both are possible does not mean that they are the same. D-H is not a panacea, but its use for password transmission would completely solve the Ethernet sniffing problem. That alone indicates that active and passive attacks are different in nature and in the defences appropriate. D-H doesn't require any prearranged keying material, which is its primary advantage against passive attacks. Since distribution and storage of keying material is an as-yet pragmatically unsolved problem, it is unwise to insist upon prearranged keys when a partial solution, D-H, is available immediately. Eric From jdwilson at gold.chem.hawaii.edu Sat Feb 5 20:35:48 1994 From: jdwilson at gold.chem.hawaii.edu (Jim Wilson VA) Date: Sat, 5 Feb 94 20:35:48 PST Subject: Soap Boxx's Brother?? Message-ID: <9402060430.AA14604@gold.chem.hawaii.edu> Taken from paperboy a briefing given by Mr. Dennix Boxx - any relation to Soap? Forwarded message: > From paperboy at tecnet2.jcte.jcs.mil Thu Feb 3 17:01:04 1994 > Date: Fri, 4 Feb 94 02:26:12 GMT > Message-Id: <9402040226.AA01090 at tecnet2.jcte.jcs.mil> > To: jdwilson at gold.chem.hawaii.edu > From: paperboy at tecnet2.jcte.jcs.mil > Posted: Fri Feb 4 02:26:10 GMT 1994 > Subject: News Briefing 02/03/94 > > DoD News Briefing > Thursday, February 3, 1994 - 1:00 p.m. > Mr. Dennis Boxx, Deputy ATSD, Public Affairs > > > Mr. Boxx: Good afternoon. I've got a couple of > announcements. > > Today we have a Memorandum for Correspondents, which > announces that Secretary of Defense-Designate William Perry will > leave Washington, Friday evening, to attend the Munich Conference > on Security Policy '94. Deputy Secretary Perry is scheduled to > deliver the U.S. address at the conference on Sunday morning. > Throughout the weekend he will also hold bilateral meetings with -Jim From nate at VIS.ColoState.EDU Sat Feb 5 21:00:22 1994 From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons) Date: Sat, 5 Feb 94 21:00:22 PST Subject: Please, please write to your reps! Message-ID: <9402060500.AA02903@vangogh.VIS.ColoState.EDU> In light of recent news from the EFF concerning the Clipper/ SkipJack/Key Escrow/Rape of Privacy issues (see comp.org.eff.news), I would like to ask everyone out there to take the time (a few minutes, maybe an hour if you really take time) to write to your Congress-unit and Senator, as well as the President, Vice President, etc... and voice your strong opposition to the recent policy decisions about Clipper. Also, write to CNN and any other news agencies (ABC, NBC, CBS, BBC, etc) and tell them that they should get their act together and start to cover this issue, as it certainly is "newsworthy" Thanks for your time, and please write. -nate sammons -- +-----------------------------------------------------------------------+ | Nate Sammons | | Colorado State University Computer Visualization Laboratory | | Data Visualization/Interrogation, Modeling, Animation, Rendering | +-----------------------------------------------------------------------+ From nobody at pmantis.berkeley.edu Sat Feb 5 21:10:23 1994 From: nobody at pmantis.berkeley.edu (nobody at pmantis.berkeley.edu) Date: Sat, 5 Feb 94 21:10:23 PST Subject: Remailer Security Message-ID: <9402060508.AA24108@pmantis.berkeley.edu> Just a qucik question. How safe am I from being traced if I use a remailer? If I hop it through say three of them? From nate at VIS.ColoState.EDU Sat Feb 5 21:20:22 1994 From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons) Date: Sat, 5 Feb 94 21:20:22 PST Subject: bounce from ?? Message-ID: <9402060519.AA02971@vangogh.VIS.ColoState.EDU> I just posted to the list about writing to congress-units, etc, and was sent a bounce from that the recipient's mailbox was full... anyone else get this? -nate -- +-----------------------------------------------------------------------+ | Nate Sammons | | Colorado State University Computer Visualization Laboratory | | Data Visualization/Interrogation, Modeling, Animation, Rendering | +-----------------------------------------------------------------------+ From nobody at shell.portal.com Sat Feb 5 21:40:22 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Sat, 5 Feb 94 21:40:22 PST Subject: Remailer security. Message-ID: <199402060537.VAA12987@jobe.shell.portal.com> Mr. Someone asked, >Just a qucik question. >How safe am I from being traced if I use a remailer? If I hop it through >say three of them? Depends on how much they are willing to pay for the extropia secret key and pass phrase that I am selling. Too bad they don't guard their company at night, and don't use rotary locks instead of six pin tumblers. How much do you think your enemy is willing to offer? The point is.... Decide for yourself. No one knows. -Citizen #487-22-3398/C class. From hughes at ah.com Sat Feb 5 21:50:22 1994 From: hughes at ah.com (Eric Hughes) Date: Sat, 5 Feb 94 21:50:22 PST Subject: ADMIN: bounce from ?? In-Reply-To: <9402060519.AA02971@vangogh.VIS.ColoState.EDU> Message-ID: <9402060546.AA17852@ah.com> I've removed the relevant bouncing address from the list. In the future, such question can be directed to me at hughes at ah.com, since this kind of list problem is best dealt with quicker than normal requests. Eric From nate at VIS.ColoState.EDU Sat Feb 5 23:05:49 1994 From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons) Date: Sat, 5 Feb 94 23:05:49 PST Subject: a little information, please... Message-ID: <9402060704.AA03216@vangogh.VIS.ColoState.EDU> -----BEGIN PGP SIGNED MESSAGE----- Could some kind sole out there please tell me a few things? 1) How many legal wiretaps are conducted each year? 2) How much will it cost to implement the key escrow system, specifically, how much startup cost and how much per year to maintain? 3) How much money is lost per year as a result of strict export controls on encryption technology? (Lost from business revinue, that is) 4) How much money has it cost to design the Clipper Chip and the DSS? Thanks, - -nate - -- +-----------------------------------------------------------------------+ | Nate Sammons | | Colorado State University Computer Visualization Laboratory | | Data Visualization/Interrogation, Modeling, Animation, Rendering | +-----------------------------------------------------------------------+ From nobody at shell.portal.com Sat Feb 5 23:40:22 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Sat, 5 Feb 94 23:40:22 PST Subject: Magic Money Update Message-ID: <199402060740.XAA24069@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- This is an update for Magic Money. The PGPKGEN.C here contains a very fast mp_inv function, provided by an anonymous poster on the Cypherpunks list, which reduces the time to unblind a 1024-bit coin from minutes to a few seconds. The C.C contains a new -r option which generates a blank message, similar to the -i option, without generating a new key. This should be used by infrequent server users, to update their elists and make sure they do not miss an expiration. The message generated by -r has no coins, but causes the server to reply. Blinding is now fast enough to use a 1024-bit server key. A server operator should re-integrate the assembly-language speedups from PGP, or the server will be very slow in signing coins. The PGP makefile might help you do this. Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVSTlsGoFIWXVYodAQGIVgP/aU0rqTccbAonRO2Mv4O3Z9WAXswy1BkN VY1psOyNTgT+C7Uvet1dm92rlRgvShAEcF5CK7crrO+hjhp7QgU6rnCY5ZrAN/i5 Oavn8CZcjxGb7nSkMhPQIIO7yoeKJoV+zaIYJ8uhGwSI6s7L/sDRsqebpxqoN4Bv EMAIK3BZ8Zg= =uahV -----END PGP SIGNATURE----- From mgream at acacia.itd.uts.edu.au Sun Feb 6 00:10:24 1994 From: mgream at acacia.itd.uts.edu.au (Matthew Gream) Date: Sun, 6 Feb 94 00:10:24 PST Subject: Some stuff about Diffie-Hellman (and more :-) In-Reply-To: <9402052233.AA04867@toad.com> Message-ID: <9402060811.AA24965@acacia.itd.uts.EDU.AU> Earlier, smb at research.att.com wrote: > There's also Rivest and Shamir's Interlock Protocol (April '84 CACM). > Davies and Price suggest using it for authentication, but Mike Merritt > and I showed that that doesn't work under certain circumstances. Diffie, Wiener et al in "Authentication and Authenticated Key Exchanges" (Designs, Codes and Cryptography, 2, 1992) discuss the need to combine key exchange and authentication, amongst other things. Anyway, the upshot is that a Station To Station protocol is developed and discussed which is based on the original D-H system. Damn, I don't have the paper which me, so I'm not sure whether third party certification is needed. The accompanying discussion, relating to secure protocol requirements and so on struck me as quite good at the time IMHO. Matthew. -- Matthew Gream, ph: (02)-821-2043 M.Gream at uts.edu.au. From karn at qualcomm.com Sun Feb 6 00:10:50 1994 From: karn at qualcomm.com (Phil Karn) Date: Sun, 6 Feb 94 00:10:50 PST Subject: archiving on inet In-Reply-To: <199402021222.HAA05404@snark> Message-ID: <199402060805.AAA19940@servo.qualcomm.com> >Anyway, people who want to use the law to restrict distribution of >their news articles are extremely foolish. Your words are out there >and they WILL be read. Forever. You can't help it. If you find your >words embarassing, don't say them. Yeah. You guys should lighten up. You won't be able to keep your posts off of CD-ROM collections, but you might still have some fun with the vendors. The next release of my KA9Q NOS software, prior versions of which have already appeared on quite a few CD-ROMs, will contain a copyright notice that explicitly grants permission to CD-ROM publishers to carry it for free -- on the condition that they send me a free copy of the disk. Most already do, as a courtesy, usually when I show up at their booths at the Dayton Hamvention. My new notice should take care of the rest. Heck, each one probably costs them no more than a buck to make, so how could they object? Seems like a win-win situation to me. They enhance their sales and I build up a nice CD-ROM collection quite cheaply... By the way, there's a very good reason why you should *welcome* the availability of USENET archives on CD-ROM. Imagine that one day you toss out on the net a clever little idea in the hope that someone may find it useful. You don't think much of it at the time. Several years later, much to your dismay, you discover that some slimeball has stolen and been granted a patent on your idea. You're convinced they got it from your original USENET article, but how do you prove it? Simple -- if your original comments were preserved for posterity on a commercial CD-ROM, complete with silk-screen label showing the dates of the articles it contains. Don't laugh - this has already happened to me. Fortunately, I had also published my idea in a ham radio journal more than a year before the bogus patent application was filed. But if I hadn't, I'd now be frantically looking around for 5-year-old USENET archives. Phil From nobody at shell.portal.com Sun Feb 6 00:10:50 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Sun, 6 Feb 94 00:10:50 PST Subject: Magic Money vulnerabilities? Message-ID: <199402060810.AAA25213@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- People have mentioned possible attacks against Magic Money. I don't think it is possible to send the server a value to sign which would reveal the server's secret key. The server signs your message x by raising x to the power d. If you know x^d and x, finding d would seem to be a discrete-logarithm problem, which is just as intractible as factoring. Can a small or otherwise rigged x help you to find d? If so, participating in any blind signature protocol is very dangerous, but I don't think that you can find d this way. wcs at anchor.ho.att.com wrote: (some deleted) (attack 1) >One security hole in online digicash systems of the Chaum variety is >that you _do_ need to make sure the money is only transmitted in >encrypted forms not susceptible to playback attacks. >If Eve can read the cash either before Bob gets it or before Bob's >message gets from his fast LAN across the slow part of the net >to the bank, then she can occasionally spend it before Bob can. (attack 2) >If Eve stomps on the Account-number bits, even though she can't >break the encryption to substitute her account number for Bob's, >she can substitute a random account number for Bob's. >This acts as a denial-of-service attack against Bob. >As a defense, either the message has to contain signatures or at least >MACs for validation, and be rejected if invalid, or the format >needs to make it impossible to find the account number field >or to modify it without trashing the cash as well. Magic Money is not susceptible to the first (intercept) attack, because the coins are encrypted with the server's public key. The reply is also encrypted with a response key sent to the server inside the encrypted packet. The server signs its responses, so you couldn't send someone some bogus coins and then fake the server's response to fool the person into believing that the coins were good. Magic Money has no account numbers; the server just exchanges old coins for new coins immediately. A version of the second attack is a problem. The message from the user to the server has no authentication. It is just an encrypted PGP message to the server. There is an RSA packet and an IDEA packet, and the data is directly inside the IDEA packet. If you were to dearmor the message and garble something near the end, then re-armor it, the server would bounce the garbled coins with a bad signature. Some of the first coins would already have been cancelled, and their value would be lost. To prevent this, the next version will MD5 the data packet before encrypting it, and include the MD5 value. This will be checked, and if it is bad, the message will be thrown out before processing any of the coins. This is not a pressing problem. Who would go to all the trouble to make a remailer detect and corrupt certain messages? The person doing the corrupting would not have anything to gain. A while ago I read of a program in alpha-test called Nautilus. This was specifically designed to compress speech for modem transmission. The author said that the beta, when it was ready, would be Copylefted. PGP Tools, if combined with Nautilus, has everything you need to do a secure phone. With the Clipper push, we need one badly, and now. It should use PGP keys for authentication, but either DH or a one-shot RSA key for key exchange. That way they can't record the session and demand your key later, as they could if you used your regular PGP key for the key exchange. Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVSdtMGoFIWXVYodAQHC9AQApMjaIF2+h0k6Zb2YSwjkFL1/zAgCXJU+ Dm+kS0us9kusKMc2wr2pc4cEzQow9apM/Od2CisXAaRtHZNUyE8tN3mYWEPxAdcd 6qG03ZekvTqQB+do2HBGRAH3KXGscPIDCyjuh9iIKp9bB7/GWLNoAYm7fPjxpIYz gnWTuRyBme4= =wOox -----END PGP SIGNATURE----- From cknight at crl.com Sun Feb 6 00:50:23 1994 From: cknight at crl.com (Chris Knight) Date: Sun, 6 Feb 94 00:50:23 PST Subject: archiving on inet In-Reply-To: <199402060805.AAA19940@servo.qualcomm.com> Message-ID: On Sun, 6 Feb 1994, Phil Karn wrote: > The next release of my KA9Q NOS software, prior versions of which have > already appeared on quite a few CD-ROMs, will contain a copyright > notice that explicitly grants permission to CD-ROM publishers to carry > it for free -- on the condition that they send me a free copy of the > disk. It's a good idea... But can you see a CD-ROM publisher sending a free CD to everyone who puts that in a disclaimer? Still... It's more likely than calculating royalties! -ck From julf at penet.fi Sun Feb 6 02:35:51 1994 From: julf at penet.fi (Johan Helsingius) Date: Sun, 6 Feb 94 02:35:51 PST Subject: FIRST CYPHERPUNKS VIRTUAL MEETING In-Reply-To: Message-ID: <199402061035.AA19075@lassie.eunet.fi> > Is a MOO really the best method to carry out the virtual meeting? My > expierience has been that they are most unfriendly, espicially if you are > clientless. > > I'd think a series of IRC channels would work better, but maybe I'm wrong. Have to agree 100%. Julf From hughes at ah.com Sun Feb 6 03:55:55 1994 From: hughes at ah.com (Eric Hughes) Date: Sun, 6 Feb 94 03:55:55 PST Subject: Some stuff about Diffie-Hellman (and more :-) In-Reply-To: <9402060811.AA24965@acacia.itd.uts.EDU.AU> Message-ID: <9402061151.AA19462@ah.com> >Anyway, the upshot is >that a Station To Station protocol is developed and discussed which is >based on the original D-H system. The STS protocol is a regular D-H followed by a (delicately designed) exchange of signatures on the key exchange parameters. The signatures in the second exchange that they can't be separated from the original parameters. >Damn, I don't have the paper which me, >so I'm not sure whether third party certification is needed. There is a digital signature required, so what is at root required is a trusted public key of the other party. One can use a certificate to establish this trust and transmit it at session time, but any other method of communicating a public key will work, include a trusted web of trust or direct previous transmission. STS is a well-thought out protocol, with many subtleties already arranged for. For the issue at hand, though, which is Ethernet sniffing, it's authentication aspects are not required now, even though they certainly will be in the near future. Eric From wcs at anchor.ho.att.com Sun Feb 6 04:50:29 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Sun, 6 Feb 94 04:50:29 PST Subject: Government Policy makes Internet breakins easier Message-ID: <9402061248.AA09213@anchor.ho.att.com> Newsgroups: comp.org.eff.talk,comp.security.misc,talk.politics.crypto,alt.security,alt.activism Subject: Government Encryption Policies Simplify Internet Break-ins Distribution: [Sure would be nice if the EFF or CPSR would put out a press release along these lines. Anybody?] The news from the Information Superhighway hasn't been good this week. Major breakins have been occurring from someone who's been stealing users' passwords as they log in across the net, using them to break into their machines, and using their machines to watch the net for more passwords. It's not really that hard to stop - encryption technology has been available for several years that sends passwords across the net in encrypted form the eavesdroppers can't use - but most people haven't deployed encryption. Why not? Well, part of it's just laziness, but in large part the use of encryption has been restricted by the government's Cold War era policies against developing, using, or distributing encryption software. Encryption is the mathematical privacy coding that lets people send their passwords and conversations privately. If you want to sell encryption software overseas, you have to get a munitions export license, just as you would for exporting assault rifles or nuclear weapon parts, and they'll only give you a license for crippled software that the NSA can break easily, unless you're a bank or selling to a "friendly" government's military. If you want to sell encryption software in the US, you can't export it, which means you have to sell separate US and export versions. And if you want to give it away free, like lots of university and public domain software, you can't just post it to the net or make it available for ftp (the Internet version of the public library), without risking years in jail or at least having your computers confiscated while the government tries to decide whether to indict you - and you'd better be able to afford some *very* good lawyers. Can this sort of free speech really be illegal? Nobody's really sure, the government won't give you permission and few people want to risk the jail time to find out if they'll give you forgiveness. Meanwhile, most computer systems have simple password systems that can't protect against wiretappers. It's especially a problem on international long-distance circuits, where the connections are more exposed, because export rules say your business can't ship it the package you use on your US computers to your foreign branches. The Clinton Administration has announced that they're going to relax the export rules a bit, if you use their new Escrow Encryption Chip (which has built-in wiretapping capabilities) or simple encryption systems with short, easy-to-guess keys. The paperwork will be simpler, and you won't need an arms dealer license to carry your cellular phone or laptop computer on a business trip, but the NSA still retains control over what technology you can use. Proposed legislation in Congress would transfer control of crypto exports to the Commerce Department, which handles most other export licensing. Without the Communist Party to kick around, U.S. Administration press releases bring up spectres of drug dealers, terrorists, and pornographers, but some of the major applications for the wiretapping capabilities of the new Escrow Chip appear to be financial transactions and tax evasion, since banks will need to replace their current encryption systems with something newer, as faster generations of computer technology will make the present systems insecure over the next 5-10 years. Because the Escrow Chip is a hardware-only approach, it's adequate for automatic teller machines, but you'd need to buy a government encryption module if you want to do your banking over the Information Superhighway - more secure encryption can be done cheaply, in software, but the NSA's 55 mph speed limit won't let you - for now. On the other hand, the Cold War's over and you can get good encryption software from Finland, Moscow, Bulgaria, Switzerland, or Australia, often free, and it's becoming widely used by political activists in post-Communist countries. --------- The preceding has been the personal opinion of Bill Stewart, and does not necessarily represent the views of the EFF, CPSR, Cypherpunks, or my employer, but I'll be happy to have my rhetoric stolen :-) --------- Bill Stewart billstewart at attmail.com From julf at penet.fi Sun Feb 6 05:40:28 1994 From: julf at penet.fi (Johan Helsingius) Date: Sun, 6 Feb 94 05:40:28 PST Subject: FIRST CYPHERPUNKS VIRTUAL MEETING In-Reply-To: Message-ID: <199402061337.AA20812@lassie.eunet.fi> > The first cypherpunks virtual conference will be held at BayMOO on > Wednesday, February 9, at 8pm PST (11 EST). To get there: Count me out. Yes, I like to participate in physical Cypherpunks meetings. Yes, I like to participate over e-mail. If I really have to, I can waste time using IRC. But I do *not* have enough patience to hang out in any cute virtual restroom line in some virtual bar in some virtual game... We already have enough of the dreaded freenet virtual cafe stuff around - it's like using virtual punched cards.... Ack! Julf From BOBES_PIERRE at delphi.com Sun Feb 6 06:00:29 1994 From: BOBES_PIERRE at delphi.com (BOBES_PIERRE at delphi.com) Date: Sun, 6 Feb 94 06:00:29 PST Subject: signoff list Message-ID: <01H8K5MKMKVM90NSU2@delphi.com> Pleas remove me from the list bob From huntting at glarp.com Sun Feb 6 09:06:06 1994 From: huntting at glarp.com (Brad Huntting) Date: Sun, 6 Feb 94 09:06:06 PST Subject: doj_escrow_intercept.procedures (fwd) In-Reply-To: <199402052018.MAA14027@mail.netcom.com> Message-ID: <199402061700.AA04889@misc.glarp.com> >> Makes *what* a whole lot easier, building the bomb or catching the >> bombers? > It makes it easier for any clandestine plan to be established and > carried out. This is the greatest fear they have. Arbitrary > networks of people with arbitrary purposes can be securely formed > world wide within the limits of the trust inherent in the people. > Can you spell r e v o l u t i o n? It's not me that's paranoid, > it's them. :-) While stopping terrorists may be easier in a country with pre-taped communications, and organizing otherwise undetected insurrection will be a little closer to possible, this is not the main purpose of wiretaps today or in the future. The real targets of wiretaps (now and in the future) are political activists. Anyone who poses a serious threat to large corporate profits is a target for a wire tap. This includes organizations like Greanpeace, the communist party, CISPES, and even libertarians who oppose superfluous military intervention. Sure, blowing up the world trade center costs money, but cutting arms sales to Indonesia just because of some little genocide on an island with only a few hundred thousand inhabitants... That cuts into profits; especially if it catches on. In the past, if Dow wants to put a tap on my friend's mom's phone (a prominent anti-pesticide activist), they can just hire a private investigator to climb the poll and sift through the conversations. No, they never found out who was taping the line, for some reason they didn't think to ask the guy who came around once a week to change the tapes on top of the pole (go figure). In the world where Clipper is predominant, the government will have a monopoly on this sort of activity. Two things are clear to follow: First, there will be fewer PIs able to do wiretaps. People chasing after abducted children or forgoten alimony cheques will be out of luck. Second, the government will be pressured into taking on the activities that are now done by PIs (at a substantially greater cost of course). This will force some relaxing of the rules governing obtaining escrowed keys. Since anyone purchasing the key escrow devices will have implicitly agreed to (amongst other things) wave any expectation of privacy associated with using the device, they probably wont have to much legal ground to stand on when they discover the their phone conversations have been sold to Exon. brad From nobody at jarthur.Claremont.EDU Sun Feb 6 09:30:31 1994 From: nobody at jarthur.Claremont.EDU (nobody at jarthur.Claremont.EDU) Date: Sun, 6 Feb 94 09:30:31 PST Subject: For Pr0duct Cypher Message-ID: <9402061726.AA20879@toad.com> -----BEGIN PGP MESSAGE----- Version: 2.1e hIwCwagUhZdVih0BA/9PNJuwQk/HvaEgKPCWrkH4+f5ZCPVIdskqCloJC2DV2eMi Zcad567Ff8AJVsJ4l4u+i17d9oBNK+VbFar4uxu5OVvhugKGd2bCp1xAD/peWa+9 SNeCGamNEHZCA+kOZe4Dj8AN+tTrMfcCEYmkNdgoJjYLGxYVp6uUFrnr3fXFRqYA AApfo1NAYylYWjPGE/QHXSvXhwp4v8HLFzYh3Ye+AZozqKoak5QfcCL6THMEHOLq TXsbgdru52RrU7kKFd/keOtqkrpB+XUeO5P36tCteO3w6kSpWNzPVujqccIWiXHR t/lo70SJDUFXAVaj0DYJjCTSvbLWplbv3Cake8NLmyW1ayFqpA8go2Z3TOPZkofv rxq3PAInJT9flG/fsRTUlv8ELmkB9fhSiKhFx5u1tvZ25dc6AFqleHtNP/685bxI 5WDGlTE5lOAe4FiUDTzFx7Lp9yA4cFJvzfartdyUYVM3shQTbWRGcvEArNvHVoGO /iEWxLcRne//B8xy8StAER95KF8vBrl4r3JE7OSaQgIZc7399g2pkEALOGAIo2ZY G6ucg8CpNtQXnVm1pHGuaiPQjGIOTT0EWRXWtwfMafGBqPR1bw2FzeLA3Jc04+Js did5u0mUwNMVVPDj+wTRcUHMQ51tzT5kKDrCFqKsMvAy1bJq5hKU9EOgX8g50DRR d1EVsp2SufK9VQms9B8ptgVmiaMj/WRoX+XtJqtVvGZg4cv8UNrRXQS9PtsX9M+I L+7iG9roBKpHJGLutU2uLkAYbojGiSsrlDzq2iQWcSqeI3HXjhlO3pDjcDiz18DN AQuSJaBJloqkpRiDLLRvPbNLAERFyOjiDA1dYDprmp80XEUxTBMrSjmutWuh0sgS p2SRvStimRQTMTzIiQVyJkTv86zPVRLvNCZEaE1nCAtdgrIdaIjgJQ+wpORrEGB5 yTympGUQAJn7n4c841WupkmbTxjlY1kcllyrZ9Y8aCzNCEagmAqayElZ2lww64cl MWMm0aedA4F5D8VpI/5/JQdbuGSrSj7sVm4s0AmTCxTuq+Ww05PWbMTGtPd6fIVG xaRPVMmeoMaw1T2HMpAeDIEvc1Ab5X3dJWPeKn6X47scvKMgoDpEglE+ydx0UeUo wzi+/gZBz5TZ8sO0aBZB0Hn0Whso/LeXkqSRVWdwH8hWJz0+Z/EpsVE/sWnvzaT2 GOARq+GmedHi0d3AMvmJuTAd6BE5RczSrWZe2yQMrtybPZ1H1wYoSW05zeIgTg6H mlqA44fOlSV1/wH398cyXim/mikvfmBkbEswAAfL1L1iHTPkkgXGHucmUmvwVcrk UEyI8OcAr02o51iOp99cM16N9F7dQFhucxNxbE0KCjGHPn+UPELDucPyAC7gzOqN sKcGx8ptLtyCCu7j10PRLkt27QsBjsF7iceYIDPsjx/T3+qELOb2+t1iaJmPHW1E BiB9shLEAgmyLcCrtbvEyx0ayzYQPPw+4GyJZGtyzGwYJhKmKOUcav76Pb7vEX0R NWxf+15rNv6Ns3SoWFYmLmCrJJ4jReGus7VVIvwBBNn5+TcLATuPyWGj+kIQlgIf l25iNsjtpQ+LBeQYzRLZYG9w8oJNUllnAkf3WMgWL03txjeJ4XtfX/Gb9Lnz/6nJ wctT5sKldp2etq0nk/yQyCLW44bV7DP0cqaSlDuZABzHqoaHkqVlvIHKiC7Qg0TP UVeFJWKcAN1dr6lDmBf2VU+S5u+6TNGHWgrZ662H9vrIw5iVOpd5/LmJYVCdcWlL Lsy8XI/d3SQMbzZde0Frw/eqRHgtJrXHksf1jkxRLDoZHZQiHWPLHbWGgxoxptha baBu3Lkkpi8xFzlGwksQqaP1tN1wAF+OelZ8IpOqlJy199nScUn04wyvEd3FlhPK N4LBcHEYpRHKbdvMICyzOEwiKGuJ9l3hVV8rOtgDbJWxLsnt5XenldqvbvMb0mTy y50l1MXXi8CmncSp6YBXDWWshqCYqksOgRiErqYOxdIHzn1Xg9Z/7S8XXVr7oGup DF4521egG/0/siVHJa44vGXyc0n0mwLaWcviUoxeTZ+lFb4lkmY8s3SE4vZIz4Tt NAjmCcqpnsMScDHsSR19jPlZ9ayFMH/x0UtE3Y0COdcfvlgF3J705RrFl3CxU0SY 2gMmlL7An5K8a9hcrwpAwTWbB6yMJnD3AiE8hteIVru+2QfdPS68M0kGhcToHx57 cmrAVaCU2ywz0yBERA+SvQluTPnPuT9vQaVrh6EE7OuWhg4SG+fzAnIkJvSuPRRK gOjCj0aoM+iYD+RXzPPKIMC3gYrjq8byrj5Q0+TjJpcKSYpw1KTllL9+xgptSNlT SIrrvAYpK1SPY+GPOXwfvjx/Cud3jb7LHI7ZYmEfEAub7gVzsbbBG5ZWlrZc9rmR IQi94oZ6cXTDjuAD1eoL9nh0KlfDKsPYyW1UNuxEKfXfjPMcvEFya8pvJRBYVaDD p5GfOqn4QzeH3iGcO4w+zInroB1NWNxgnyToRoC0W1qPRgoB4xhv7gw/T7CASjmN dMzO0anYxdCHUrGpH458MB9i8eJAlu3JV87tIldasXF8B9LAICu+emW5M7f03YA6 a5Qcfqpzc4a2YQEhjqc8Lddu/9Jc6lo4ufEia2DcnG7LHak3aGR8R9RyISK58gRp CG9b6NOC14x3pYzBThZAg65HbECGdtRToN5GgT7PpXCv92FQVX3UxJryCPlELO+q L/vqXHIfmWdXW8kkr23H3tC1AXB1k6H7/hgmD21LOQNpo17JmZXAxpCENQ5oBhc1 9BabRKvzUQAhhTaADwfrSIhG/dHFhzFTrAx6qmkWJPuy+2G9nPgO+pn66DTDAhK0 SSh5MbzFjTCH3AvmkFa4yZuvdZMm3VRM9VmTkfhBiyS2wRxnACMNsCD+3zVPKp81 hg7xrMH6rvDhY0shDecEzGiC1Q1TfCLjWISTYNdxFPOXB40pQbzPqd/Hn9NGf8wR xFCfjj9ybPMJZCxUWG5bJml8TKbYjIvimpsBRfJ0+XK832aY4RFCWmu2Y8Xv1tuz ruk6hNuCA+D4ogUZVBYoeUyll/K67Ym1H3SzR2sBEddnSoBb9wPxQxYzJrCMDeNm i9wryIYlPS1kOjKprSWuC+EXSY7f5vKX6mOSuYL3GSsqAejCbgWmjvpubi/xNIry +m4NDeGkuUtA2fuBg0ehePDvRBDnG2iZJX8cv7IX90wy1HNzlcuvVwJvObvW51OL ayA67AiUwW/ufyjI76/nRRZQBXrde4cgsvD8doYHgBJybheEVshkYmLvq/yQGxX2 WDLlSmXvLvdaDsr3MBRX3LsFs2vi7GQDWi7VJeAPOOpBnDtKqKX60FLi3wPUHN+7 moL2eVPgGVGdvYSvKrCDfxjNTAb2zItsWplWYtg/j2dThtxsl96H3vw521A5l7VR 83Fr8u9I+kBRF1CR1yjiQ8iKdpJBSnmnaEmr8ebvZeObpWicNpICzNkSZ8z0nq4M jR5KTrT9vUV2Y6yycskNrva/XnFR+KmyrJBXV3Gedjyg2ExFjbTJnLj2DcWxY16F T3XwpM+NNH58vnlNvt8Sy5b1FqmuOKC/ehwpaYVJkKxFchbjXtsGLFzcIEsMd6mB ndn0478oeFh/vFzArIIqBcRf73B+qkeJ4ijSZiThvXWlRk/Sxtu9J0uTVlixNsUY FRaaRRwrfps++XBw1O21bY4v =mMHl -----END PGP MESSAGE----- From tcmay at netcom.com Sun Feb 6 11:11:08 1994 From: tcmay at netcom.com (Timothy C. May) Date: Sun, 6 Feb 94 11:11:08 PST Subject: A Nice Summary of Motives for Clipper Message-ID: <199402061911.LAA20333@mail.netcom.com> This fellow has written a nice summary of the "carrot and stick" motivations on Clipper. Nothing we haven't seen discussed, but a nice synopsis. His analysis is accurate: - the government will make Clipper use very easy to export, and to use (perhaps by subsidizing production costs of the MYK-xx chip for some time) - the government will make non-Clipper use very hard to export, may harrass those who post code to ftp sites (a la PGP, Moby Crypt, etc.), and will do other things to throw roadblocks up - the result will probably be that in 5 years mosts crypto use is of the key escrow sort, with all that that implies Comment from TCM: Yes, we've "already won" in some sense, in that strong crypto can't be completely eliminated. But if 99% of all crypto users are using key escrow in 1999, for practical reasons, then in some sense we have lost. I'm curious about what RSA Data Security Inc. thinks of all this, as this carrot-and-stick move worsens the export situation immmensely: key escrow technologies get a "pass," while non key escrow technologies get scrutinized, delayed, and generally told not to bother to try to export (this is my interpretation). Could be real bad news for Bidzos and Company. (Don't flame me for urging an alliance with RSADSI! I'm just speculating on who will be hit hard here. Could have some implications for what Cypherpunks support.) Here's the article: Newsgroups: alt.activism,alt.politics.datahighway,alt.privacy,alt.privacy.clipper,alt.security.pgp,alt.wired,comp.org.eff.talk,talk.politics.crypto From: shephard at fraser.sfu.ca (Gordon Shephard) Subject: Re: CRYPTO: DoJ's new rules for access to Clipper keys Message-ID: Sender: news at sfu.ca (seymour news) Organization: Simon Fraser University, Burnaby, B.C., Canada Distribution: inet Date: Sun, 6 Feb 1994 12:39:21 GMT Lines: 107 strnlght at netcom.com (David Sternlight) writes: >You still don't get it. Clipper is a system for the private sector with good >security except for the escrow. The escrow is there to prevent the bad guys >from using what would otherwise be a very hard to break system. This reveals some of the mindset behind Government encryption policy. For the past year or so, I've been discussing the "Clipper Concept", and have constantly bewildered myself and others with the question: Why on earth would the black hats use a system which can be compromised by law enforcement agencies? The conclusion which we normally came to was that after the introduction of Clipper technology, the United States Government would work towards making it illegal for cryptographic systems other than Clipper (or some other Government controlled Key Escrow system) to be sold or produced in the United States. Now, Mr. Sternlight's view that Government is not attempting to prevent black hats from using non-clipper technology, and that they simply do not wish to allow criminals to use the Governments strong encryption system, contrasts somewhat with the current dialogue on the subject. And it makes sense - Clipper is going to dominate the market. We may all strut about and swear up and down how we will never use a cryptographic system which the Government can break, but, given that commerical providers will probably have huge incentives to develop clipper chip systems, (Govt. Contracts and such :) this is the system that you and I will probably be purchasing. A careful re-reading of the Press Releases provides supporting evidence. In particular, the administration will allow export of key escrow technologies, and their new policies will result in: - expedited delivery of products - reduced shipping and reporting costs - fewer individual licenses - personal exemptions for the use of encryption technology taken out of the country by business persons. The administration is going to also work with industry, with the NIST leading these efforts. Mention was made of money being tossed into this effort (Staff will be hired....) So, that's the carrot, now for the stick: "The Administration will continue to restrict export of the most sophisticated encryption devices." So, picture in your mind a Company such as AT&T, or U.S. Robotics, that is about to start selling an encrypting modem/telephone: They can either provide to Joe Public a Key Escrow technology, or they can put together their own proprietary encryption system. The Key Escrow technology system can be sold to the U.S. Government (Big Bucks, How much would you like to bet that in the next 3 or 4 years, numerous government departments will be allocated large sums of money to purchase encryption devices, regardless of whether they need it or not - The press releases reveal that All Govt. Purchases will be Key Escrow - Never underestimate the impact of Government contracts) The Key Escrow technology system will be free of Red Tape, can be exported, will not require individual licensing for each country, can be taken out of the country by business persons (The vast majority of which could care less whether the Govt. can crack their communications, it's the competition they are concerned about), etc, etc.... Or, they can create a proprietary system and face the mother of all red tape trying to sell the damn thing (At a significantly increased cost.) The Result: 1) Commerical Companies will not produce Non Key Escrow Technology. 2) The few that do, will have their lives made so difficult by the Administration, it will be difficult to find their product. And this is an issue that Nobody seems to discuss: Encryption is only useful if BOTH ends of the communciation line are using the same encryption technology. Who will you be able to talk to if you are using a proprietary encryption system. (A technically alert member of the press should ask the following question: Will the administration seek to prevent encryption systems which incorporate the clipper chip from having secondary encryption technolgies embedded (I.E. Imagine if the modem you manufactured could only talk V.32terbo, and not V.32/V.32bis - Nobody would buy it because everyone else has a V.32bis modem. ) And here is where the Government may have made a strategic error though; by not revealing their encryption algorithm, they may have opened up a market for people who are concerned about the strength of the encryption algorithm. E.G. AT&T can come along and market their encrypting telephones with multiple levels of security, standard "Clipper" encryption, or new and improved AT&T laboratory technology which has been attacked by every encryption researcher on the planet. Of course this device would still face the Red tape which the government will be using as its primary weapon against non key escrow technology in the coming years. You heard it here first. (Well, maybe not. Anyone hear how the Government has been treating PGP lately? :) | Gordon Harry Shephard, shephard at sfu.ca,(message)252-4387, (res)524-8622 | In No Way am I speaking for my Employers or Simon Fraser University. -- From qwerty-remailer at netcom.com Sun Feb 6 11:30:31 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Sun, 6 Feb 94 11:30:31 PST Subject: CypherPUNKS. Not! Message-ID: <199402061927.LAA06782@mail.netcom.com> -----BEGIN PGP SIGNED MESSAGE----- Anthony Garcia wrote, "> Get Off the Internet and Write Us a Real Encryptor. Get a copy of Schneier's "Applied Crypto" and write it yourself. Don't expect other people to provide encryption technology for you, because they probably won't." You sadly misunderstand. "Us" means US. All of us. Humanity. You also didn't understand the point of the Dead Kennedy's "Anarchy For Sale." Fortunately Phil Zimmerman and a few others do, and hopefully they will also give PGP a "random data block" format output. If we (all of us using PGP on this planet), don't get PGP off the internet and into the hands of MOST Mac and Windows users, as well as in hardware form in devices like phones, then as the last song I quoted said, "You'll (Cypherpunk activists) be the first to go." I don't code. I make molecules, and soon I will be using standing waves made by lasers to deposit atoms on surfaces, working at Harvard, Bell Labs, and NIST to help develop the next next generation of CPUs, sensors and other devices. If you want something to write code for, 10 years from now, don't disrespect those who do sciences other than programming. Your answer is what the government WANTS the programmers to be like, like this: "You want bulk vitamin C powder which has been rumored to cure that new AIDS strain that started spreading by air? Well that wouldn't make me or anyone else any cash, and since the FDA has banned vitamin supplements, you better go pick up a book on synthesis. I think you start with glucose. Oh, and include organometallics, since it's only certain mixed oxidation state Copper complex dimers that seems to work. Fairly complex stuff. Hurry up though, I hear that AIDS (Clipper) virus kicks in pretty fast! But don't expect chemists to give you any, well since you see, that would be altruistic and that is not logical, since my value system is selfishness. As long as I can cure myself, and you aren't paying me large sums, well, bye bye." And making PGP better and posting it anonymously or not, is no where as illegal as if I were to offer an unapproved medicinal to patients in need, something that would immediately put me in handcuffs. Happily, drugs that are truly effective become available to terminal patients, since of course that makes money. I'm going into crystal and surface chemistry anyway, and the FDA seems to be failing in its ongoing attempts to take away my legal vitamin C powder. I fear though that they may succeed in 10 years, and the Clipper's going to send my e-mail into the FDA's "bad guy" files, as being a person who takes more vitamin C than can be found in a can of Coca Cola. I just want privacy and to be left alone. And research funds ;-). -=Xenon=- -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLVT86QSzG6zrQn1RAQGNgwP/YONeGygK20IMXXL96hgu6MKDqZToslzK BLgaWOYAvCz9e48aR6AemamQ3R7Dm9ZdqTyf2QIIgV/2VliARX4+9ADBiS3BUtET Kck3gALq88weWfysdrxkc433b+sP9s28GOdMK2sHAjWaf9PImmoeqsaVBaAi9DzN rTMRSKnp6ko= =JKEA -----END PGP SIGNATURE----- From hughes at ah.com Sun Feb 6 11:50:30 1994 From: hughes at ah.com (Eric Hughes) Date: Sun, 6 Feb 94 11:50:30 PST Subject: a reference to STS In-Reply-To: <51436.pfarrell@netcom.com> Message-ID: <9402061948.AA20879@ah.com> Here's the reference for the STS paper. STS is the Station-to-Station protocol. _Authentication and Authenticated Key Exchanges_ by Diffie, Oorschot, Wiener _Designs, Codes and Cryptography 2_, pp 107-125 1992 Eric From nobody at shell.portal.com Sun Feb 6 11:56:08 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Sun, 6 Feb 94 11:56:08 PST Subject: No Subject Message-ID: <199402061953.LAA08152@jobe.shell.portal.com> I'm moving to Oceania. From nowhere at bsu-cs.bsu.edu Sun Feb 6 13:51:07 1994 From: nowhere at bsu-cs.bsu.edu (Anonymous) Date: Sun, 6 Feb 94 13:51:07 PST Subject: No Subject In-Reply-To: <199402061953.LAA08152@jobe.shell.portal.com> Message-ID: <9402062151.AA08195@bsu-cs.bsu.edu> > I'm moving to Oceania. Yeah, let's hope it gets built first... From mg5n+ at andrew.cmu.edu Sun Feb 6 13:56:07 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Sun, 6 Feb 94 13:56:07 PST Subject: Fwd: More on remailers In-Reply-To: <9402062051.AA26116@relay2.geis.com> Message-ID: Does anyone know what this is??? ---------- Return-path: Received: from po2.andrew.cmu.edu via trymail ID ; Sun, 6 Feb 1994 15:52:27 -0500 (EST) Received: from relay2.geis.com (relay2.geis.com [192.77.188.3]) by po2.andrew.cmu.edu (8.6.4/8.6.4) with SMTP id PAA09729 for ; Sun, 6 Feb 1994 15:51:36 -0500 From: genie-postmaster at geis.com Received: by relay2.geis.com (1.37.109.4/15.6) id AA26116; Sun, 6 Feb 94 20:51:28 GMT Message-Id: <9402062051.AA26116 at relay2.geis.com> Date: Fri, 4 Feb 94 00:51:00 BST To: mg5n+ at andrew.cmu.edu Subject: More on remailers Original Msg Id: Not Found genie-postmaster response to your message Subject: More on remailers System: QUIK-COMM Date: Fri 4-Feb-94 0:51 Status: 5 Message picked up by receiving system and delivered to all recipients with NO exceptions. ---------- From R.O.Jackson-SE1 at computer-science.birmingham.ac.uk Sun Feb 6 14:46:08 1994 From: R.O.Jackson-SE1 at computer-science.birmingham.ac.uk (R.O.Jackson-SE1 at computer-science.birmingham.ac.uk) Date: Sun, 6 Feb 94 14:46:08 PST Subject: TEMPEST - Electronic eavesdropping Message-ID: <13893.9402062244@heffalump.cs.bham.ac.uk> Transient Electromagnetic Pulse Emanation Standard (TEMPEST) is the US standard defining the amount of electromagnetic radiation that a device may emit without compromising the information it is processing. In the US it not illegal to posess TEMPEST-surveillance equipment but it is illegal to take appropriate counter-measures to prevent surveillance. The US government has refused to release details of its TEMPEST research and has restricted the dissemination of independent research by classifying it. The US Drug Enforcement Agency (DEA) makes use of TEMPEST secured electronics and computers as they believe that the drug cartels may possess surveillance equipment. I am interested in gathering comments on the social, legal, ethical, and technical aspects of use of TEMPEST surveillance equipment in the US and Europe with the aim of including it in a discussion of the threats to computer/digital systems. Please reply by E-mail. I will provide a summary to anybody who requests one. thanks, - Rob Jackson (more information on TEMPEST can be found in the paper "Eavesdropping On the Electromagnetic Emanations of Digital Equipment: The Laws of Canada, England, and the US" by Cristopher Seline - available on FTP from csrc.ncsl.nist.gov) From hughes at ah.com Sun Feb 6 15:16:08 1994 From: hughes at ah.com (Eric Hughes) Date: Sun, 6 Feb 94 15:16:08 PST Subject: TEMPEST - Electronic eavesdropping In-Reply-To: <13893.9402062244@heffalump.cs.bham.ac.uk> Message-ID: <9402062314.AA21234@ah.com> >In the US it not illegal to posess TEMPEST-surveillance equipment but >it is illegal to take appropriate counter-measures to prevent >surveillance. Can we get the urban folklore set clued into this one? Electromagnetic shielding is not illegal. On the contrary, in the USA, the FCC finds shielding highly desirable. Eric From mech at eff.org Sun Feb 6 15:36:07 1994 From: mech at eff.org (Stanton McCandlish) Date: Sun, 6 Feb 94 15:36:07 PST Subject: NIST - PKP settlements not over yet Message-ID: <199402062335.SAA20726@eff.org> [from Gregory Aharonian's Internet Patent News Service] A hostile response to a tentative agreement to settle a patent dispute over the proposed Digital Signature Standard has forced the National Institute of Standards and Technology to return to negotiations. Last summer, NIST officials thought they finally settled the DSS public key patent dispute by granting Public Key Partners (PKP) of Sunnyvale, California, an exclusive worldwide license for the Digital Signature Algorithm (DSA) on which the DSS is built. In exchange for sublicensing rights, the PKP group agreed to endorse NIST's DSS proposal. But F. Lynn McNulty, associate director for computer security with NIST's Computer System Laboratory, said a majority of potential DSS users balked at the deal. NIST published the settlement terms for comment, and McNulty said all but 10 of the 270 comments were critical. [as many of you may remember, EFF coordinated the transmission of these comments to NIST, who did not widely announce the request for comment at all. The uncharitable might call that an attempt to sweep the matter under the rug. The naive might call it an oversight. At any rate almost all of the comments NIST received were routed via EFF, who were happy to publicize it "for" NIST.] Many DSS critics have argued that another algorithm promulgated by RSA Data Security (Redwood City, CA), is a de facto industry digital signature standard and that it would cost too much to comply with a separate government standard. Now NIST is attempting to hammer out a new settlement based on the comments, McNulty said. "The real hang-up continues to be the patent issue", McNulty said. "We're still trying to resolve it". Scientists at CSL designed the CSS to serve as a standard agency tool for verifying the senders and contents of messages transmitted electronically. CSL also prescribed the public key Digital Signature Algorithm (DSA). But PKP, which holds the rights to public key patents on behalf of Stanford University, MIT, and most recently, German professor Claus Schnorr, charged that CSL's proposed algorithm infringed upon these patents. NIST originally sponsored DSA research, and agencies are exempt from any licensing fees. PKP, however, has maintained that vendors that incorporate the standard into their products should pay royalties. [Government Computer News 1/24/94, 58] -- 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 tcmay at netcom.com Sun Feb 6 16:00:30 1994 From: tcmay at netcom.com (Timothy C. May) Date: Sun, 6 Feb 94 16:00:30 PST Subject: TEMPEST - Electronic eavesdropping In-Reply-To: <13893.9402062244@heffalump.cs.bham.ac.uk> Message-ID: <199402062359.PAA20879@mail.netcom.com> > In the US it not illegal to posess TEMPEST-surveillance equipment but > it is illegal to take appropriate counter-measures to prevent > surveillance. The US government has refused to release details of its Please provide a reference for this. We've discussed this _many_ times on this List, and the consensus is that no such law exists, nor is it plausible that folks could be told they cannot "shield" their computers. (In fact, FCC regulations call for various levels of RF shielding, as we all know. Is there a law which says "You must shield--but not _too_ much"? Of course not.) I don't want to sound rude, but saying it is illegal to take appropriate counter-measures to prevent surveillance is a serious statement, requiring some support. (I'll look for the ftp paper you cite later...do you have a pathname handy in the nist ftp site?) I can believe that _certain_ countermeasures, like active jamming with RF signals, may be somewhat restricted, but mainly for FCC reasons. I cannot believe that shielding a keyboard or computer, or using LCD displays to reduce Van Eck emissions, or even putting one's computer in a Faraday cage, could be illegal. > TEMPEST research and has restricted the dissemination of independent > research by classifying it. Parts of the TEMPEST spec (and TEMPEST is not an acronym for anything, I understand) are classified, for various reasons, but this does not mean shielding or other countermeasures are forbidden. In fact, shielding supplies and TEMPEST-related supplies can be bought from several companies. Every time this thread comes up, someone cites the suppliers. > The US Drug Enforcement Agency (DEA) makes use of TEMPEST secured > electronics and computers as they believe that the drug cartels may > possess surveillance equipment. I'll phone Pablo Escobar and ask him. > I am interested in gathering comments on the social, legal, ethical, > and technical aspects of use of TEMPEST surveillance equipment in > the US and Europe with the aim of including it in a discussion > of the threats to computer/digital systems. > > thanks, - Rob Jackson > > (more information on TEMPEST can be found in the paper > "Eavesdropping On the Electromagnetic Emanations of Digital > Equipment: The Laws of Canada, England, and the US" by > Cristopher Seline - available on FTP from csrc.ncsl.nist.gov) Lots of interesting stuff there. But where is the paper you cite? A pathname would be appreciated. --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. From miron at extropia.wimsey.com Sun Feb 6 16:06:07 1994 From: miron at extropia.wimsey.com (Miron Cuperman) Date: Sun, 6 Feb 94 16:06:07 PST Subject: remailer delays In-Reply-To: <199402042129.NAA11271@jobe.shell.portal.com> Message-ID: <1994Feb6.232301.2234@extropia.wimsey.com> -----BEGIN PGP SIGNED MESSAGE----- Xenon, you should add my machine to your list: xtropia - PGP SM + - - - Pr M 23a - The address is remail at extropia.wimey.com. Encryption is required. I keep logs, encrypted with my public key. - -- Miron Cuperman | NeXTmail/Mime ok Unix/C++/DSP, consulting/contracting | Public key avail AMIX: MCuperman | Cryptocosmology: sufficiently advanced communication is indistinguishable from noise - god is in the least significant bits. - fnerd -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLVV7ppNxvvA36ONDAQHDcQP9H3lpdKOF2TobH8fuZDjNQGjxh2LKKbc4 eiN961fMn0hfQaXA6TLioAyvZsvGe10CRWaTzW2tgVAL6RDgZLKji7ng87jzIfat 2O/w0uV2wNd6EWWMWdtQwkQ+J7adKNMj5IUjpYlvM5v0jicuPVotgQLMLgwQHoXA 4c5n2XLsurU= =5Re6 -----END PGP SIGNATURE----- From qwerty-remailer at netcom.com Sun Feb 6 17:30:32 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Sun, 6 Feb 94 17:30:32 PST Subject: remailer delays Message-ID: <199402070130.RAA12616@mail.netcom.com> It's half done :-) ! Unfortunately the NSA run remailers haven't been handing out info, but this should help people know which blanks are still blanks ;-). God I hate these little sideways smileys! oooooooooooooooooooooooooooooooooooooooooooooo ooo$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ooo $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o $$$$$ $$$" "$$$$$" "$ $ $ "$ $$$$$" "$ "$ $$$ $$$$" "$$ $$oo$$$$$ $$oo$ $$$$ $$$$ " $$$$$ $$ $ " $$$ o$$$$ $ $$o "$$$$$o "$ $$ $ $$$$$ $$ $ $$$o $$$$ o $""$$ $$$$$""$$ $ $$$$ $$$$ o $$$$$ $$ $ o $$$$ $$$$ $$$ $o o$$$$$o o$ $ $ $o $$$$$o o$ $o $$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$""""""""""""""""""""""""""""""""""""""$$$$$$$$$$$$""""""""""""$$$$ $$$$ "$$$$$$$$$$" o$$$$ $$$$ "$$$$$$$$" o$$$$$ $$$$ $$$$$$$$ $$$$$$ $$$$$$$$$$$$$ $$$$$$$$$ $$$$$$ $$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$ $$$$ $$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$ "$$" $$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$o "" o$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$$o o$$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$$$o o$$$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$$$$o o$$$$$$$$$$$$ "$$$$$$$$$$$$ $$$$$$$$$$$$$$$ $$$$$$$$$$$$" $$$$$$$$$$$$ $$$$$$$$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$$ $$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$ "$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$" $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ """$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$""" """""""""""""""""""""""""""""""""""""""""""""" Xenon's Full Disclosure Remailer List. Remailer Fast? OpLog SysLog Subj Batch RD NL CPU Phys PGP BitB ...and? --------- ------ ----- ------ ---- ----- -- -- --- ---- --- ---- ---------- bsu-cs + ? ?/? + ? ? ? ? ? 23a - catalyst + N? SM/MQ - - ? - PA M 23a - choas + ? ?/? + ? ? ? ? ? - - cicada ++ ? ?/? - - - - ? ? - - colostate ++ ? SM/MQ ? - ? ? Un M ? - dis.org -/-- ? ?/? - ? ? ? ? ? 23a - extropia +/- ? SM + - - - Pr M 23a - jarthur +/-- St SM/MQ - -/+ ? ? Un ? 23a - menudo -- N SM - t1 "?" Y Un H 23a - merde -/-- ? ?/? - ? ? ? ? ? - - penet.fi -- St SM - t? 24 + Pr H - - pmantis ++ ? ?/? - ? - - ? ? - - qwerty + C SM/MQ - - - - PA M 23a + rosebud ++/- N MQ - - - N Un M 23a - remba -- ? ?/? ? ? ? ? ? ? 23a - shell ++/+/- St ?/? - ? ? ? ? ? 23a - soda ++/- St+? ?/? - ? ? ? ? ? - Subj: Strips Subject header? NL: Non-linear remailing? 123->231. RD: Random delay added (max, in hours)? Batch: Batched remailing? t2 means twice daily. n5 means after 5 messages. CPU: Pr = private. PA = account on public access machine. Un = university. Phys: Physical security of the CPU, especially at night. H/M/L. BitB: BitBucket feature? Fast?: ++ <5 min + 5-10 min. - ~10-30 min delay -- Pinging isn't practical due to long delays. Probably reliable though. +/- Sometimes +, sometimes -. Normal internet mail delays are common, and are not equivalent in the two directions between any two remailers. Mail still gets through. OpLog: F: full copies of all mail is archived. My large volume mailing should help put a stop to this. St: Stats logs of when mail was remailed. St+: Stats logs of when and where mail was remailed. St-: simple counter. N: operator keeps no logs. C: Simple counter. SysLog: SM: sendmail logs of when and where mail was exchanged. Root access needed. MQ: mailqueue accessible by anyone on the site. Could make logs. I have chosen nicknames based on a string common to both the outgoing address and to the address you see on an incoming message from the remailer. bsu-cs nowhere at bsu-cs.bsu.edu catalyst catalyst at netcom.com chaos remailer at chaos.bsu.edu cicada hh at cicada.berkeley.edu colostate nate at vis.colostate.edu dis.org remailer at dis.org extropia remail at extropia.wimsey.com jarthur ebrandt at jarthur.claremont.edu menudo nobody at Menudo.UH.EDU merde remailer at merde.dis.org penet.fi anon.penet.fi pmantis hh at pmantis.berkeley.edu qwerty qwerty at netcom.com rosebud elee7h5 at rosebud.ee.uh.edu (elee6ue at rosebud.ee.uh.edu) shell hfinney at shell.portal.com soda hh at soda.berkeley.edu Discontinued remailers still on some lists out there: phantom at mead.u.washington.edu remail at tamaix.tamu.edu sameer at netcom.com sameer at berkeley.edu (spelling?) cdodhner at indirect.com remailer at entropy.linet.org?? 00x at uclink.berkeley.edu? remail at tamaix.tamu.edu? Background on each remailer: bsu-cs: Run by Chael Hall. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: History: ?? catalyst: Run by Scott Collins. Machine: personal dial-up account on Netcom. Problems policy: Outgoing address blocking, with proof of ID. Contact catalyst at netcom.com. Software: Customized Hal's ? Security: Netcom keeps sendmail logs, which root at netcom.com can read. Any Netcom user could also compile his own sendmail logs, by constantly logging mail as it arrives and leaves. Comments: History: ?? chaos: Run by Chael Hall. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: Comments: finger remailer.help at chaos.bsu.edu for info using any remailer. ?? gopher chaos.bsu.edu for a collection of info about Cypherpunks. Comments: History: ?? cicada: Run by Eric Hollander. Machine: ??? Problems policy: ?? Contact ?? Software: ?? Security: Tread lightly. Being "phased out". colostate: Run by ?? Machine: ??? Problems policy: ?? Contact ?? Software: ?? Security: ?? dis.org: Run by Peter Shipley. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: History: ?? extropia: Run by Miron Cuperman. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: Only accepts PGP remailing. ::/Encrypted:PGP header is optional. Privately owned, in Canada. Not directly connected (delays possible). History: ?? jarthur: Run by Eli Brandt. Machine: Sequent Symmetry. Problems policy: Destination blocking is available w/ sufficient ID. Contact ebrandt at jarthur.claremont.edu. Software: The usual, tweaked for MMDF. Hal's. Security: jarthur keeps sendmail logs. Comments: Although jarthur doesn't batch, its connection often results in outgoing mail getting batched out anyway (1-3 hours delay). History: Set up late '92. PGP added mid '93. menudo: Run by Karl Barrus. Machine: University machine. Problems policy: see policy at gopher site. Contact klbarrus at owlnet.rice.edu or elee9sf at menudo.uh.edu. Software: Modified Hal's. Security: Stores messages and sends them out randomly at midnight. Pads messages to 1K with random stuff. (?) Comments: elee9sf at menudo accepts RIPEM encryption. elee6ue at rosebud requires "digital cash" (basically random strings I made). Errors on elee9sf at menudo are forwarded klbarrus at owlnet.rice.edu where they are deleted. I still get mail at that address which is why I have it forwarded and not just dropped. History: No comment. merde: Run by Peter Shipley. Maching: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: History: ?? penet.fi: Run by Julf (Johan Helsingus). Machine: ?? Operator owned. Problems policy: Account revokation. Contact ??@anon.penet.fi. Software: custom. Security: Comments: By far the most popular remailer, dwarfing in a day what the entire Cypherpunk remailers combined carry in a month. Supports easy return addresses as well as non-anonymous mailing to someone's anonymous address (na1234... instead of an1234...). Your real address is kept on Julf's hard disk, but is fairly safe there, especially if you do not abuse your anonymity to harass someone. On a bad day your mail and especially Usenet posts may be delayed up to a day. Very reliable though. Sends error messages back to you for failed mail. Limited to 48K mail. History: ?? pmantis: Run by Eric Hollander. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: Tread lightly. Being "phased out". Comments: History: ?? qwerty: Run by Xenon. Machine: dial-up account on Netcom. Problems policy: "What problems?". Contact qwerty at netcom.com. Software: Hal's remailer. Security: Netcom keeps sendmail logs, which root at netcom.com can read. Any Netcom user could also compile his own sendmail logs, by constantly logging mail as it arrives and leaves. Operator often logs in using telnet. Comments: You must use na1234 at anon.penet.fi not an1234 at anon.penet.fi. Finger qwerty at netcom.com for a blurb on the remailer and updates on its software. Request-Remailing-To: /dev/null is a bit bucket. whitehouse.gov gets blocked and fully logged. History: Up 2/94. Set up by Xenon who needed more remailers to use to send PGP info to people with, since anon.penet.fi was overloaded. rembe: Run by Bill (O'Hanlon?). Machine: ? Privately owned. Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: Not directly connected (delays?). History: Second oldest remailer. rosebud:(elee7h5 at rosebud.ee.uh.edu) Run by Karl Barrus. Machine: University. Problems policy: See gopher site. Contact klbarrus at owlnet.rice.edu. Software: Hal's. Security: "syslog file can be read" Comments: Errors are "dropped". History: Third oldest remailer. rosebud: (elee6ue at rosebud.ee.uh.edu) Run by Karl Barrus. Machine: univerisity Problems policy: see gopher site. Contact klbarrus at owlnet.rice.edu. Software: standard scripts (Hal's) modified to accept cash strings. Security: "Syslog file can be read." Comments: Errors are "dropped". shell: Run by Hal Finney. Machine: ?? Problems policy: ?? Contact ?? Software: Hal's Remailer. Security: ?? Comments: whitehouse.gov blocked and fully logged. hal at alumni.caltech.edu forwards all mail to shell. History: ?? soda: Run by Eric Hollander. Run by: ?? Machine: ?? Problems policy: ?? Blocking of addresses. Mail sent to problem causer. Contact ?? Software: custom. ?? Security: Was keeping full logs till Xenon's bulk mailing venture. ?? Comments: History: ?? Remailer Public Keys: (I've got these). From nate at VIS.ColoState.EDU Sun Feb 6 17:56:08 1994 From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons) Date: Sun, 6 Feb 94 17:56:08 PST Subject: FOR Xenon (what's his email?) Message-ID: <9402070153.AA08461@vangogh.VIS.ColoState.EDU> -----BEGIN PGP SIGNED MESSAGE----- Info on the nate at vis.colstate.edu remailer colostate: Run by Nate Sammons nate at vis.colostate.edu Machine: Sun 4/280 - direct ethernet connection to the Colorado State University backbone. Getewayed to CU/BOulder, and then into the Net backbone. Problems policy: No problems yet. Nobody at CSU really knows about it yet ;-) Contact Nate Sammons nate at vis.colostate.edu Software: Hal's Remailer software, modified Security: What do you want to know? - -nate BTW, thanks for the work! - -- +-----------------------------------------------------------------------+ | Nate Sammons | | Colorado State University Computer Visualization Laboratory | | Data Visualization/Interrogation, Modeling, Animation, Rendering | +-----------------------------------------------------------------------+ From qwerty-remailer at netcom.com Sun Feb 6 18:16:08 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Sun, 6 Feb 94 18:16:08 PST Subject: FOR Xenon (what's his email?) Message-ID: <199402070215.SAA16858@mail.netcom.com> na38138 at anon.penet.fi or faster, qwerty at netcom.com. -=Xenon=- P.S. I'm e-mailing you separately. From tcmay at netcom.com Sun Feb 6 18:20:32 1994 From: tcmay at netcom.com (Timothy C. May) Date: Sun, 6 Feb 94 18:20:32 PST Subject: TEMPEST - Electronic eavesdropping In-Reply-To: <199402062359.PAA20879@mail.netcom.com> Message-ID: <199402070218.SAA06728@mail.netcom.com> OK, I've just reread the Seline paper Rob Jackson was referring to (available by ftpat csrc.ncls.nist.gov::/pub/secpubs/tempest.txt--my thanks to Rob for providing the pathname to me). I say "reread" because this is the same 1990 paper that's been reposted several times to sci.crypt and here to the Cypherpunks list. Earlier I said, quoting Rob: > > > In the US it not illegal to posess TEMPEST-surveillance equipment but > > it is illegal to take appropriate counter-measures to prevent > > surveillance. The US government has refused to release details of its > > Please provide a reference for this. We've discussed this _many_ times > on this List, and the consensus is that no such law exists, nor is it > plausible that folks could be told they cannot "shield" their > computers. ...stuff elided... Indeed, most of the Seline paper is devoted to the fact that the TEMPEST spec itself is classified, which is undoubtedly true. And the (unconfirmed) assertion that mere possession of RF intercepting gear that could be used to defeat TEMPEST is illegal. (I have doubts about this, given the various types of RF receivers, old television sets with manual tuners, etc. I suppose that if one were caught with an antenna, a tunable CRT able to "tune in" the emissions of a nearby--or distant--computer or CRT and display them the way the NSA's ELINT gadgets undoubtedly do, then this might be considered evidence of criminal intent--like burglar tools, password-cracking tools, etc. [And we've had this debate many times as well, with some saying possession of lockpicking tools is legal, others saying it's not, etc.]) However, nothing in the Seline report, flawed as it is (IMO), says "it is illegal to take appropriate counter-measures to prevent surveillance." That is, go ahead and shield away! What I think the government is saying is this, and I have no idea if this is in fact law or if it would hold up in court: * First, we (the government) have a TEMPEST spec we use to build equipment to. It tells our vendors how good their stuff has to be. We don't tell the public this spec, because this would help the Russkies and the Yellow Hordes, not to mention the French. * Second, we (your public servants) have our own tricks and techniques and dislosing the TEMPEST specs would provide damaging information to our opponents (the Mob, the Serbs, the Cypherpunks, and the Republicans)--so we aren't talking. And we insist TEMPEST contractors also keep their mouths shut. * Third, we (us again) will not allow _eavesdropping_ equipment to be publically sold, whether for intercepting cellular phone calls, CRT emissions, whatever. You may find loopholes (telephoto lenses and giant parabolic mikes, so beloved of dicks), but we've basically outlawed this stuff. (sorry if my irreverent tone and change of point of view is confusing here) So, nothing about shielding or monitoring emissions (commercial RF leakage equipment is widely available and measures stuff down many dB from the unshielded level). Just don't build a Van Eck gadget and let others know about it (though, again, it's not clear how the courts would rule on this). And don't disclose TEMPEST specs. For Cypherpunks, not too much to worry about. We don't want or need to play at being spooks by monitoring nearby systems, and shielding is available. That it's not used much, that we are "soft targets" for determined surveillance teams, and that we use PGP on insecure machines, etc., is all well-known. Everything has a cost, and most of us don't perceive a direct enough threat to our communications and computers to warrant working inside a local, Faraday-caged machine, keeping passwords in a separate laptop we carry with us at all times, etc. What's important for us is to get crypto tools spread ubiquitously. The rest can come later. --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. From nobody at shell.portal.com Sun Feb 6 18:26:08 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Sun, 6 Feb 94 18:26:08 PST Subject: PGP Tools & Magic Money Update Message-ID: <199402070226.SAA05321@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- PGP Tools and Magic Money would not run on a big-endian machine. This did not surprise me, because I don't have one to test it on. I sent a new version to csn.org which fixes a bug in fifo_moven, and includes a #define to force the precision to maximum on a big-endian machine. This should make it work, but will slow it down. The new version, when it shows up, should be in the pgp_tools directory. Go to /mpj, read README.MPJ, and it will tell you how to get into the crypto section. Check the file dates to see if the new version is there yet. I sent them on 2/6. Is there anyone who would like to fix it so it will run properly? The files pgptools.c and ptd.c in the toolkit, and mm.c, s.c, and c.c in the Magic Money system, need to be changed. There is a function called rescale which has to be run on mpi's after set_precision is called. I have no way to test any changes, so I can't write this. Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVWRMcGoFIWXVYodAQHSCwQAhA8gZTKDEnzdFyC5UbB0HpvSe299w4F0 bmAA+vplPWNIuFx+RswN6UeCqr9v32tPHTopU4y8twWWJ6p+sA0laqfPVsubtuKK 0bJkasrhIYZDfh4X+RaXgiv50hrcqm87Str0asUOiv1sA7Mv9G5cTxQPwvm0Wiq1 BEjeR5cYn8M= =6VZI -----END PGP SIGNATURE----- From mg5n+ at andrew.cmu.edu Sun Feb 6 18:51:08 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Sun, 6 Feb 94 18:51:08 PST Subject: FOR Xenon (what's his email?) In-Reply-To: <199402070215.SAA16858@mail.netcom.com> Message-ID: qwerty at netcom.com writes: > na38138 at anon.penet.fi or faster, qwerty at netcom.com. > > -=Xenon=- I thought it was na48138 ... ??? That's what it said on your earlier posts. From qwerty-remailer at netcom.com Sun Feb 6 19:40:32 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Sun, 6 Feb 94 19:40:32 PST Subject: FOR Xenon (address?) Message-ID: <199402070338.TAA25281@mail.netcom.com> Gee, someone must have snuck into my account and changed all the 48s to 38s. I stand corrected. na48138 at anon.penet.fi. Mister 38138 must be rather confused due to the "Bomb me!"s he's been getting :-). I'll send him a note to tell him. Maybe I can convince HIM to take over this project even! -=Xenon=- From hfinney at shell.portal.com Sun Feb 6 20:00:32 1994 From: hfinney at shell.portal.com (Hal) Date: Sun, 6 Feb 94 20:00:32 PST Subject: Attack on Magic Money and Chaum cash Message-ID: <199402070359.TAA19748@jobe.shell.portal.com> I think there may be a security weakness in Magic Money coins, and in Chaum's "online" cash system from the Chaum/Fiat/Naor paper. Magic Money coins are numbers of a particular form, RSA-signed by the bank. They look like Y^(1/e) where Y is the number and e is the bank's public exponent corresponding to the particular denomination of the coin. The structure of Y is a 0, a 1, a string of bytes of 0xff, then a defined 18-byte string of bytes, then 16 random bytes. This Y is generated by the user, and is then blinded by multiplying by some random r^e, and sent to the bank. The bank RSA-signs Y*r^e to get r*Y^(1/e), and the user divides by r to get Y^(1/e). This is the coin. The coin is checked by raising it to the power e, to get Y, then checking to see if it is of the proper form. Actually, the Magic Money code only checks the 18-byte special string (just above the 16 random bytes) to make sure it matches the exact byte sequence that is always supposed to be there. In addition the bank checks the 16 random bytes against a list of spent coins to make sure this coin hasn't been spent before. The other relevant point is that the bank has to sign everything you give to it (with payment) - it can't check the bit pattern for legality, since what it is signing is blinded. So you can really get the bank to sign anything. Yesterday I opined that this would be safe, but now I don't think so. The danger I would see is an attacker who gets the bank to sign 2, 3, 5, 7, 11, 13, 17, 19, .... The bank won't know it is signing these special numbers because they are blinded. If someone gets a lot of low primes signed he may be able to forge money, especially with the incomplete checks in the Magic Money program. The idea would be for him to try to factor a legal Y using just the primes he has. If he can find a factorization using only small primes of a number which holds the magic 18-byte sequence in the right place, he can multiply together the signed forms of the primes to produce a signed version of that number. This would be a successfully forged coin. So, the question is whether it would be feasible to collect enough signed small primes to be able to generate more valid coins than you have primes. (It costs you a coin each time you get the bank to sign something, so for this to be a money-making venture you want to get more out of it than you put into it!) I think there are a reasonable fraction of numbers factorable by only small primes. Since there are 2^128 possible money values (based on the 16 random bytes) there should be quite a lot which are factorable by only small primes. Magic Money could help by checking the high bytes as well as the magic 18; it would be take more time to factor 1024 bit numbers than 272 bit ones ((18+16)*8), and there would be fewer that are factorable by small primes. But the problem would still exist. The attacker can run a fast sieve to identify numbers which are factorable in his set. The same attack would apply to Chaum's online cash. His cash is of the form, (x,f(x)^(1/e)), where f() is a one-way function like MD5. To forge this you would again get signed forms of the small primes, then keep picking random x's, until you got a f(x) which could be factored by your set. Presto, you can create a fake coin. I don't know how this attack can be prevented. Hal From hfinney at shell.portal.com Sun Feb 6 20:36:08 1994 From: hfinney at shell.portal.com (Hal) Date: Sun, 6 Feb 94 20:36:08 PST Subject: Attack on Magic Money and Chaum cash Message-ID: <199402070432.UAA21889@jobe.shell.portal.com> A quick follow-up: I suppose a cut-and-choose protocol in the withdrawal would prevent this attack. Instead of sending in one blinded coin to be signed you'd send in 100 blinded candidates, then the bank would pick 99 and you'd reveal the r's for the others (remember, they are blinded with r^e) so the bank can verify they are of the proper form. The bank would then sign the one remaining one and return it to you. What a pain! I hope someone can come up with something better, or show that the attack doesn't work. Hal From nobody at rosebud.ee.uh.edu Sun Feb 6 21:16:09 1994 From: nobody at rosebud.ee.uh.edu (nobody at rosebud.ee.uh.edu) Date: Sun, 6 Feb 94 21:16:09 PST Subject: CRYPTA PLUS W/ RSA Message-ID: <9402070514.AA03925@toad.com> 01/31 0936 ( BW)(TELEQUIP) Business Editors HOLLIS, N.H. (JAN. 31) BUSINESS WIRE - January 31, 1994--Telequip Corp. today announced the first available PCMCIA compatible flash memory card with high-level embedded security functions. The credit card sized Crypta Plus is targeted at companies implementing secure tokens for mobile computer users. These tokens will allow users to conveniently communicate and access confidential data across public computer and telecommunications networks. Industry experts predict widespread use of secure tokens for corporate and customer communications, database access, electronic funds transfer, defense and government programs, and any other activity involving confidential electronic information transfer. Sales professionals will be able to travel with proprietary information and communicate securely with the home office. Physicians will be able to use tokens, loaded with patient files, to perform rounds, order tests and even write prescriptions that can be signed with a digital signature. It will be possible to process and pay insurance claims directly from the field. Mobile computer users will conveniently carry and securely communicate large amounts of confidential information. Crypta Plus cards have up to 20 Megabytes of solid-state, nonvolatile memory and require no batteries. The memory capacity will increase in conjunction with technological advancements in the flash chip industry. The patent- pending card consists of a data storage unit, storage-access locking circuitry, and a tamper-proof key information substorage unit in the form of a smartcard integrated circuit. A stored program within the smart card integrated circuit allows an access password to be programmed directly into the silicon from an external source. The locking circuitry prevents access to the data stored on the memory card unless the user inputs the identifying password. The smartcard integrated circuit can be used to perform cryptographic functions, including digital signatures. It also provides secure storage for the keys necessary to perform those functions. The Crypta Plus card satisfies three vital needs of mobile computer users: o It can securely store private information in a compact, easily transportable storage device. o It protects electronically stored data against unauthorized access if theCrypta Plus card is lost or stolen. o It makes cryptographic functions and secure key storage readily availableto allow protection and authentication of data being sent to remote sites. Several important technology trends have converged to make the development of the Crypta Plus card possible. The PCMCIA standard has been swiftly adopted by the industry leaders in personal computing. This allows the Crypta Plus card to operate cross-platform in most mobile computing devices. The explosive implementation of distributed networks and wireless communication now makes data security a vital tool for insuring and protecting personal and corporate interests. The rapid growth of Public-key cryptography and digital signature standards is creating secure environments for access, transmission and authentication of private information. Along with U.S. Government standards for digital signatures and encryption, Telequip will embed RSA, the popular Public-key cryptosystem into the Crypta Plus card. "We're excited about Telequip's Crypta Plus technology - it's a perfect match for distributed, robust security systems such as RSA," said Jim Bidzos, president of RSA Data Security Inc. The Crypta Plus card will also fully comply to the soon-to-be published PKCS 11 specification, which will be the first open, published standard for use of Public-key cryptography with tokens and smart cards. PKCS, or the Public Key Cryptography Standards, were established early in 1991 by a consortium of RSA Data Security and its major licensees, including Microsoft, Apple, Sun, Lotus, Digital, National Semiconductor, and many others. The backing of the PKCS consortium members will make PKCS 11 the most important standard for secure tokens and smartcards in the world. Michael F. Jones, president of Telequip Corp., points out that "Public-key cryptography and digital signatures are central to the future of electronic commerce. These techniques depend on successfully keeping the private key and its operations secure. The company believes the Crypta Plus card is an ideal personal token for performing private-key operations and implementing cross-platform security. It can be thought of as a portable object in which data, applications and security all travel together in one convenient package. Users will carry Crypta Plus cards with them to run applications, store data, configure systems, sign documents and access network resources." --30--ed/bos CONTACT: Telequip Corp. Greg Dunne, 603/881-5616 From remailer at merde.dis.org Sun Feb 6 21:30:32 1994 From: remailer at merde.dis.org (remailer bogus account) Date: Sun, 6 Feb 94 21:30:32 PST Subject: PGP Tools tester needed Message-ID: <9402070527.AA09890@merde.dis.org> -----BEGIN PGP SIGNED MESSAGE----- I tested PGP Tools with the #define in place to force all set_precisions to max unit precision. There didn't seem to be any speed difference, even with a 384-bit key. If this works okay, it could probably be left the way it is. Someone with a big-endian machine, please compile the new version when it arrives, and see if it works. Thank you. Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVWv78GoFIWXVYodAQElbwP+NDsswe8MDnbHhnsZaWdVsb8Nv+cRuyQ4 q1L6isffXz7CJ0I2CnS/guY7yp13qaJPJiiGCoBe+/6E1uwCKj0ePIwP2ifDxf1A 1pQ17Rc11atph4NKIRlvoLbX1xs4qyHfda9CEpccOgdNuq45KZ0d/zFxN+5XvIy8 Bp3N/K00TDM= =GmjR -----END PGP SIGNATURE----- From nobody at shell.portal.com Sun Feb 6 21:46:09 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Sun, 6 Feb 94 21:46:09 PST Subject: Magic Money attack Message-ID: <199402070541.VAA25288@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- hfinney at shell.portal.com wrote: I think there may be a security weakness in Magic Money coins, and in Chaum's "online" cash system from the Chaum/Fiat/Naor paper. [ describes the Magic Money coins ] [ only 18 bytes are checked ] Easy enough to fix. Will code this. I just sent new PGP Tools and Magic Money updates to MPJ. He must be getting tired of me sending him new code all the time. :-) The latest version does protect against garbling of the message from client to server. >The other relevant point is that the bank has to sign everything you >give to it (with payment) - it can't check the bit pattern for >legality, since what it is signing is blinded. So you can really get >the bank to sign anything. Any way to avoid this, other than a cumbersome cut-and-choose? [ attacker gets a bunch of small primes signed ] >The idea would be for him to try to factor a legal Y using just the >primes he has. If he can find a factorization using only small primes >of a number which holds the magic 18-byte sequence in the right place, >he can multiply together the signed forms of the primes to produce a >signed version of that number. This would be a successfully forged coin. How many small primes would it take? How would he know what numbers to multiply to get the coins? Just create random coins and look for one which is made of all small factors? I should try this and see if I can find one. Not being an expert in the math, would most coins have a large factor, or would there be a fair number with only small factors? >So, the question is whether it would be feasible to collect enough >signed small primes to be able to generate more valid coins than you >have primes. (It costs you a coin each time you get the bank to sign >something, so for this to be a money-making venture you want to get >more out of it than you put into it!) I think there are a reasonable >fraction of numbers factorable by only small primes. Since there are >2^128 possible money values (based on the 16 random bytes) there >should be quite a lot which are factorable by only small primes. Any math whizzes out there care to run these numbers? >Magic Money could help by checking the high bytes as well as the magic >18; it would be take more time to factor 1024 bit numbers than 272 bit >ones ((18+16)*8), and there would be fewer that are factorable by >small primes. But the problem would still exist. The attacker can run >a fast sieve to identify numbers which are factorable in his set. The high-byte check I will code up right now, but I'll wait until we figure out what to do about this problem, before dumping any more code on MPJ. Is anyone going to start up a server, when the program is debugged? >The same attack would apply to Chaum's online cash. His cash is of the >form, (x,f(x)^(1/e)), where f() is a one-way function like MD5. To forge >this you would again get signed forms of the small primes, then keep >picking random x's, until you got a f(x) which could be factored by your >set. Presto, you can create a fake coin. Anyone know Chaum's email address? We could ask him... >I don't know how this attack can be prevented. I can think of one way. Redefine the coin format so the last 2 bytes or so can be anything you want. Now when the user generates a coin, he sets these last two bytes to 0001 and then tests for primality. He keeps adding 2 and checking until he finds a coin which is prime, or at least doesn't have any small factors. When the server gets a coin, it checks it for primality, and only accepts coins that pass the prime test. This way any coin made out of small factors will not be accepted. The small-factor sieve is fast, and with the proper #defines, it checks all primes below 8192 decimal. The slowtest() PGP uses is slow even for the 512-bit primes used to make 1024 bit PGP keys. It would be useless for a full 1024-bit number. Would eliminating coins with factors below 8192 be enough? Or how could one more quickly check the coin for primality? Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVXKf8GoFIWXVYodAQHCsgQAmeUjeqb3utFdW2AwPU7a2Bs7dxRtVOPi wzS3Jcp+QVZ4GgGLJpr2ZLW4EenX/kAkF5cLBeBebt+6RHD7jel2SxbXxeZ8Ab64 o45oibcrvN9xEnBUkEinfDfH9rkAobYFgNPfGDEs1ajDzw8ISwUDOmA+glm01xzg XBZFLdyQWwM= =H+UC -----END PGP SIGNATURE----- From nobody at shell.portal.com Sun Feb 6 22:20:31 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Sun, 6 Feb 94 22:20:31 PST Subject: RE Magic Money Attack Message-ID: <199402070620.WAA27121@jobe.shell.portal.com> Pr0duct Cypher wrote, "Easy enough to fix. Will code this. I just sent new PGP Tools and Magic Money updates to MPJ. He must be getting tired of me sending him new code all the time. :-) The latest version does protect against garbling of the message from client to server." Tired of new code? NEVER. From hfinney at shell.portal.com Sun Feb 6 22:41:09 1994 From: hfinney at shell.portal.com (Hal) Date: Sun, 6 Feb 94 22:41:09 PST Subject: Magic Money attack Message-ID: <199402070641.WAA27913@jobe.shell.portal.com> >From Pr0duct Cypher: > [ only 18 bytes are checked ] > > Easy enough to fix. Will code this. I just sent new PGP Tools and Magic > Money updates to MPJ. He must be getting tired of me sending him new code > all the time. :-) The latest version does protect against garbling of the > message from client to server. I think it's great that you are able to fix these things so quickly. It's natural that there will be a lot of shaking out in any initial release. > How many small primes would it take? How would he know what numbers to > multiply to get the coins? Just create random coins and look for one which > is made of all small factors? I should try this and see if I can find one. > Not being an expert in the math, would most coins have a large factor, or > would there be a fair number with only small factors? Knuth has some discussion of this in Seminumerical Algorithms. The term for numbers which have only small factors is that they are "smooth". He has some formulas for what fraction of numbers are smooth based on the size of the largest allowed prime and the size of the numbers. Unfortunately I won't have access to my copy until Tuesday. Perhaps someone else can look it up. > >I don't know how this attack can be prevented. > > I can think of one way. Redefine the coin format so the last 2 bytes or so > can be anything you want. Now when the user generates a coin, he sets these > last two bytes to 0001 and then tests for primality. He keeps adding 2 and > checking until he finds a coin which is prime, or at least doesn't have any > small factors. Clever idea. If only it wouldn't be so slow. > The small-factor sieve is fast, and with the proper #defines, it checks > all primes below 8192 decimal. The slowtest() PGP uses is slow even for the > 512-bit primes used to make 1024 bit PGP keys. It would be useless for a > full 1024-bit number. Would eliminating coins with factors below 8192 be > enough? Or how could one more quickly check the coin for primality? The 8192 cutoff might work. We would have to check it out, but it could be that finding 1024-bit numbers in a relatively narrow range of +/- 2^64 which are composed solely of factors in the range, say, 8192 to 16384 would be infeasible. I don't recall whether Knuth considers the problem in this form. This would be a great save if it works. Hal From qwerty at netcom.com Sun Feb 6 23:10:32 1994 From: qwerty at netcom.com (Xenon / Qwerty Remailer) Date: Sun, 6 Feb 94 23:10:32 PST Subject: Qwerty/Xenon update. Message-ID: <199402070708.XAA17393@mail.netcom.com> -----BEGIN PGP SIGNED MESSAGE----- "I am not a number!" - The Prisoner Though na48138 at anon.penet.fi is still forwarded to me, I have decided to change the PGP Info Clearing House address to qwerty at netcom.com. When I first got an anon.penet.fi nickname I figured (wrongly) that people could mail me at Xenon at anon.penet.fi. Oh well. So now the qwerty-account/remailer will be receiving mail from basically random addresses out there. This is a fun twist, being a unique partial solution to the traffic analysis problem. All the remailers are now sending to other than the Cypherpunks now as well. And the people wanting PGP info will get it without anon.penet.fi delays. No more of their forgetting to use na instead of an too. So how hard is that to remember?: Send mail to QWERTY at NETCOM.COM with Subject "Bomb me!" for Gary Edstrom's PGP FAQ and Xenon's "Here's How to MacPGP!". Finger qwerty at netcom.com for info on the remailer there. It would be nice if every remailer gained a standardized BitBucket. To keep things simple, I suggest nothing more complicated than what qwerty uses; just request remailing to /dev/null. I'm using Hal's remailer, with a few updated files, and have used his outgoing address filter. These lines thus appear in my maildelivery file: # Blocked outgoing addresses Request-Remailing-To whitehouse.gov file A LOG.BLOCKED Request-Remailing-To /dev/null file R /dev/null Request-Remailing-To /dev/null pipe A "/usr/bin/echo BB >> LOG" The A means after the "BB" has been appended to my counter file, the mail is considered delivered. -=Xenon=- -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLVWh4QSzG6zrQn1RAQHnUAQAxyr390k7jkQFKm6YK6DPCINifAwwDAQA Kg+TA5fctD2ggU2l9DiZC7IJZPK+Kwv3u1Kz/NlpheO9vMQaDSCxad0fFl7V8LYm QUMW+vRn8h3/OTMlqMSEOC3Xry9A9n1RAmpmZpQtwSWIoSBaAt8M9KClm8NBdkgC KWghYDHhGTk= =pKJn -----END PGP SIGNATURE----- From Rolf.Michelsen at delab.sintef.no Mon Feb 7 00:41:11 1994 From: Rolf.Michelsen at delab.sintef.no (Rolf Michelsen) Date: Mon, 7 Feb 94 00:41:11 PST Subject: Magic Money questions In-Reply-To: <199402051111.DAA11286@mail.netcom.com> Message-ID: On Sat, 5 Feb 1994 catalyst-remailer at netcom.com wrote: [ Stuff deleted ] > >Similarly, how can the consumer trust the bank's representation that > >money has already been spent? Surely the bank should be required to > >publish a list of cancelled coins and timestamps with a running MD5 > >hash periodically for inspection by the unwashed masses. > > There is no punishment for double-spending. The transaction is simply thrown > out. The bank, in fact, has no way to identify the customer. What could the > bank hope to accomplish by claiming that a coin was already spent? It can > print more coins at any time, so it has no reason to cheat. A server will > have to protect its reputation by not printing too much money or otherwise > making its users angry. If you want to put in an MD5, it wouldn't be hard. > [ more stuff deleted ] False! If digital coins represent some kind of value the bank will "earn" something by not accepting a coin presented for deposit. The bank will not have to provide the value or the service the depositor is entitled to. This was also pointed out by someone else posting to this list. I haven't studied the maths and protocols of the original post to closely, but just to show that it is possible to *prove* double spending I present a deposit protocol. I don't know if this protocol fits in the implementation discussed here. If I remember correctly, some of Chaum's (?) digital coin systems proved double spending by using a protocol resembling the one below: 1) Depositor presents a part of the coin to the bank and asks "Is this coin already deposited?" 2) The bank answers "yes" and proves this by revealing some information about the coin which it should now know unless the coin has already been deposited. The "no" answer together with the information presented by the depositor is signed by the bank and is a *commitment* by the bank to accept the coin when the "real" deposit takes place. 3) The depositor sends the rest of the coin to the bank if the answer was a "no". This is taken from memory -- I could probably produce some references if someone is interested. By the way -- I don't think you should use the "digicash" word to describe this implementation. David Chaum's company carries that name! -- Rolf ---------------------------------------------------------------------- Rolf Michelsen Phone: +47 73 59 87 33 SINTEF DELAB Email: rolf.michelsen at delab.sintef.no 7034 Trondheim Office: C339 Norway ---------------------------------------------------------------------- From nobody at shell.portal.com Mon Feb 7 01:16:12 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Mon, 7 Feb 94 01:16:12 PST Subject: Magic Money attack feasible? Message-ID: <199402070913.BAA09983@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- I've done some experiments with this factor-multiplication problem. I think the solution is to check the whole coin rather than just the ASN string, and possibly to make sure the coin has no small factors. Doing a slowtest() on a 1024-bit number takes slightly under a minute on a fast PC, so that is too slow. But the sieve is fast, and if you #define BIGSIEVE, it catches all factors below 8192. I tried making some coins and trial-dividing them by the small primes in the primetable[] (up to 8191). There were a few factors being found, mostly 8-bit ones, but the remaining coin, when all the factors were divided out, wasn't much smaller. I think finding coins with all small factors will be pretty intractible. The paper refers to Chaum's digicash, using x and f(x). If f(x) were only 16 bytes, and not padded, this attack would be a serious problem. But the padding (01 and then repeat FF until the last 34 bytes) makes the attack much harder and probably impractical. The PKCS-format signature was, after all, designed to break up the multiplicativity of RSA. What exactly does the ASN string (those magic 18 bytes) do, other than pad out the MPI? Does it have some special mathematical properties? Personally, I think the padding gets rid of the problem. A 1024-bit number, padded with FF's to make it as big as possible, is very likely to have two or more fairly large factors (more than 16 bits or so). Since you would have to get two or more signatures to forge one, you lose money instead of gaining it. You are unlikely to find two coins which have the same large factors, so you can't re-use signed primes - the whole key to this attack. It is possible to move everything up, and leave the last 16 bits open. Then you could sieve the coin, and add 2 until you found one which had no factors below 8192, making the attack even harder. I don't think this is necessary, but I hope someone will work out the math. And if it turns out to be necessary, it is at least possible to make all the coins prime, making this attack completely impossible. For now, I will modify the code to check the whole number, and to make sure that the coin is as long as the modulus it's signed with. If the other change is necessary, let me know. I'm not going to post any more code to csn.org until someone (1) checks the existing (sent today) code on a big- endian machine, and (2) figures out if this attack is a problem. It should be mathematically possible to find the probability that a number of size m is composed only of primes smaller than size n, but I don't know how to do it. Does anyone? Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVXwJsGoFIWXVYodAQEZ4gP/QOGoZgRcR1CJkaWErSesMCzsEAu1fCVB OAhLGXI8hIErDuMy9f395agFxjPK3EgSWF6nnoze+BbfZDF0nTAgbgdEroHPy3k7 Pp/FV0jES3BqPFOX/0JCWHx8LRm4n2tMqUgLsX0125xywU9tk097DJTPxrAh9Xbs zrEVlsJuGRs= =akie -----END PGP SIGNATURE----- From remailer at merde.dis.org Mon Feb 7 01:30:32 1994 From: remailer at merde.dis.org (remailer bogus account) Date: Mon, 7 Feb 94 01:30:32 PST Subject: More on Magic Money attack Message-ID: <9402070928.AA10499@merde.dis.org> -----BEGIN PGP SIGNED MESSAGE----- (I sent that last message before receiving Hal's response) hfinney at shell.portal.com wrote: >I think it's great that you are able to fix these things so quickly. >It's natural that there will be a lot of shaking out in any initial >release. But what does MPJ think of getting a 400K mailbomb? If you object, MPJ, feel free to flame me and I'll stop sending them. >>How many small primes would it take? How would he know what numbers to >>multiply to get the coins? Just create random coins and look for one which >>is made of all small factors? I should try this and see if I can find one. >>Not being an expert in the math, would most coins have a large factor, or >>would there be a fair number with only small factors? >Knuth has some discussion of this in Seminumerical Algorithms. The term >for numbers which have only small factors is that they are "smooth". He >has some formulas for what fraction of numbers are smooth based on the >size of the largest allowed prime and the size of the numbers. >Unfortunately I won't have access to my copy until Tuesday. Perhaps >someone else can look it up. Someone please do. I can make the changes as needed tomorrow, if someone posts the math results. I am anxious to play with a real live digicash system, and transferring money between two directories on my hard drive does not count. >>The small-factor sieve is fast, and with the proper #defines, it checks >>all primes below 8192 decimal. The slowtest() PGP uses is slow even for >>the 512-bit primes used to make 1024 bit PGP keys. It would be useless >>for a full 1024-bit number. Would eliminating coins with factors below >>8192 be enough? Or how could one more quickly check the coin for >>primality? >The 8192 cutoff might work. We would have to check it out, but it >could be that finding 1024-bit numbers in a relatively narrow range of >+/- 2^64 which are composed solely of factors in the range, say, 8192 >to 16384 would be infeasible. I don't recall whether Knuth considers the >problem in this form. This would be a great save if it works. Whoever has the Knuth book, please check this out. Maybe we should patent this solution, if it works, and make Chaum pay us, since he patented his blind signature protocol. :-) Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVX0s8GoFIWXVYodAQG2TwP/Qa2Ql5JGu3aaYTvyfMLXeICCSQTWH2al Mx4XxAEMgsh31JH18McVwltla6I33hndYfLyFwRKetPaNW5EKO/ypzZFPHIN6m5k J9iiYDUk/FsKxScR//yjUTEsOu/3UQwczk3qRadJkNOBZQBo+qDpXewASJlVEewH 0oCWeXmqoZU= =beCP -----END PGP SIGNATURE----- From nobody at shell.portal.com Mon Feb 7 02:26:14 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Mon, 7 Feb 94 02:26:14 PST Subject: PGPTOOLS and Magic Money Message-ID: <199402071025.CAA13685@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- I've got the code written to check the whole coin, and I found another subtle bug caused by precision setting. Since setting precision does not seem to affect the speed of the decryption (I think the mpi library sets it internally during modexp) I'm just going to fix it at MAX_UNIT_PRECISION and leave it there. Tomorrow I will strip out all of these damn things. Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVYNRcGoFIWXVYodAQHdCAP/WZwBMm5NFUzYHaYXhE+d3OAXSlNKpGxD ttHtNJCI1gIZGBc2chDrMxdAa7/3xx+WdAAQ20pM/MLF44S2JVHcxnlum7oSsC9r O04uzdNGprZ1v/K/rZtc8o/xkUAUjctVY0qPGO5hK+Cyl9lABtwBeBPRslUCPYgv A1DjN0E6QNc= =HR0H -----END PGP SIGNATURE----- From jkreznar at ininx.com Mon Feb 7 03:06:15 1994 From: jkreznar at ininx.com (John E. Kreznar) Date: Mon, 7 Feb 94 03:06:15 PST Subject: Magic Money attack In-Reply-To: <199402070541.VAA25288@jobe.shell.portal.com> Message-ID: <9402071101.AA08570@ininx> -----BEGIN PGP SIGNED MESSAGE----- > >The idea would be for him to try to factor a legal Y using just the > >primes he has. If he can find a factorization using only small primes > >of a number which holds the magic 18-byte sequence in the right place, > >he can multiply together the signed forms of the primes to produce a > >signed version of that number. This would be a successfully forged coin. > How many small primes would it take? How would he know what numbers to > multiply to get the coins? Just create random coins and look for one which > is made of all small factors? I should try this and see if I can find one. > Not being an expert in the math, would most coins have a large factor, or > would there be a fair number with only small factors? > >So, the question is whether it would be feasible to collect enough > >signed small primes to be able to generate more valid coins than you > >have primes. (It costs you a coin each time you get the bank to sign > >something, so for this to be a money-making venture you want to get > >more out of it than you put into it!) I think there are a reasonable > >fraction of numbers factorable by only small primes. Since there are > >2^128 possible money values (based on the 16 random bytes) there > >should be quite a lot which are factorable by only small primes. > Any math whizzes out there care to run these numbers? A useful and delightful reference on this subject (and many others) is _Number Theory in Science and Communication_ by M.R.~Schroeder, Springer-Verlag, 1984. Let me quote the first few paragraphs of Chapter 11, ``The Prime Divisor Functions''. I use LaTeX coding. Here we consider only {\em prime\/} divisors of $n$ and ask, for given order of magnitude of $n$. ``how many prime divisors are there typically?'' and ``how many {\em different\/} ones are there?'' Some of the answers will be rather counterintuitive. Thus, a 50-digit number ($10^{21}$ times the age of our universe measured in picoseconds) has only about 5 different prime factors on average and --- even more surprisingly --- 50-digit numbers have typically fewer than 6 prime factors in all, even counting repeated occurrences of the same prime factor as separate factors. We will also learn something about the distribution of the number of prime factors and its implications for the important factoring problem. Thus, we discover that even for numbers as large as $10^{50}$, the two smallest primes, 2 and 3, account for about 25\% of all prime factors! {\large\bf 11.1 The Number of Different Prime Divisors} In connection with encrypting messages by means of Euler's theorem, the number of distinct {\em prime\/} divisors of a given integer $n$, $\omega(n)$, is of prime importance. Its definition is similar to that of the divisor function $d(n)$, except that the sum is extended --- as the name implies --- only over the prime divisors of $n$: $$ \omega(n) := \sum_{p_i \mid n} 1 . $$ It is easily seen that $\omega(n)$ is additive, i.e., for $(n,m) = 1$, $$ \omega(nm) = \sum_{p_i \mid nm} 1 = \sum_{p_i \mid n} 1 + \sum_{p_i \mid m} 1 = \omega(n) + \omega(m) . $$ Of particular interest to our encrypting desires will be the behavior of $\omega(n)$ for large $n$, i.e., its asymptotic behavior. We shall try to get an idea of this behavior by means of our usual ``dirty tricks.'' ...and so on. It seems unlikely that this development would be useless in answering the question at hand. I don't have time now to study further. John E. Kreznar | Relations among people to be by jkreznar at ininx.com | mutual consent, or not at all. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVYddsDhz44ugybJAQHpZAP/azfOzvVEkymO3rh/4HbTc537zuEajoW+ Kz+03iRenJh/Xe7906t9EmxqK9Bx2Zu28AbGonUfBSg39agrGfSyCqMltvapIbhw m2MCf25UIn5q69WB6pbIA0/V77xNFx1YEm7CtTeuBO9vqrtYW7DirJKk29brAd4d 6FlX6+nbyd8= =JuTg -----END PGP SIGNATURE----- From O.Nwosu at cs.ucl.ac.uk Mon Feb 7 03:10:34 1994 From: O.Nwosu at cs.ucl.ac.uk (Obi) Date: Mon, 7 Feb 94 03:10:34 PST Subject: unsubscribe Message-ID: <9402071109.AA09100@toad.com> Please unsubscribe me. Thank You. Obi. ==== From warlord at MIT.EDU Mon Feb 7 03:26:15 1994 From: warlord at MIT.EDU (Derek Atkins) Date: Mon, 7 Feb 94 03:26:15 PST Subject: PGPTOOLS and Magic Money In-Reply-To: <199402071025.CAA13685@jobe.shell.portal.com> Message-ID: <9402071121.AA04510@toxicwaste.media.mit.edu> PC> > I've got the code written to check the whole coin, and I found another > subtle bug caused by precision setting. Since setting precision does not > seem to affect the speed of the decryption (I think the mpi library sets > it internally during modexp) I'm just going to fix it at MAX_UNIT_PRECISION > and leave it there. Tomorrow I will strip out all of these damn things. Yea, MPI lets the precision. This is not a bug -- the MPI library needs to know how big the number is. (The bug is that its done in a global variable and not as a part of the number internally, but thats a different matter). The reason it needs to know is so that it doesn't need to perform large operations for small numebers. For example, there is no reason to perform a 1024-bit modexp when you are dealing with 384-bit numbers! FYI: I have both big-endian and little-endian machines at my disposal. Also, I was having problems building PGP Tools under mips-ultrix -- you have some global variables in ptd that you expect from time.h which don't exist. In particular, timezone and daylight. -derek -----BEGIN PGP MESSAGE----- Version: 2.3a hIwCwagUhZdVih0BA/0XHyUO7jSVHijFk98o3X3YK+pYZNQxmg+QfiNKvVXjPk6B HqM2kKTZXMngoBBl1dC+ps1jFdFI5Anxwdb/Sjg3VpQVvv/fsiK6G9V7Om6xp3Li 5v7xQ6dPRtcgmvI9WHje9OM2fhdgNsgPePEOj4odfuoYHp+9b2qlmyPYY4lChqYA AAIYLZFtfA3yFO8Lq719Jh5oIGS+JfLG6VA2Q3Tzkf7iGob17yN9poa4GvnQZP23 m1nsBYAajPKp0Odvrs3yrb1LrQAxDRNqV4hj/YTbIITqDCqdXYrUYf64JyWjaqXS lMBQG0hHDgWYLewtYEtS7VDI/yOGk4/qrJxN39xcYNVhkiD6ETTi6/wUnWCLL6aW EIM0rjwIyydaeqQmAPsj+AP+qZioyuqXNibMg95tLs5HVsDUIO7BLqhIFcnrX0Vj EIO4qBXRT2fxCnM0sxFN+vsbE+8ZNx8l1Y4dWjOQCQVpzU11IBr3Gs0Ql9U5BUAc lgD3qjf4zTTMDniTRf+r/h8PUVyj10T9C2LOylDDJ0H/uRKpMUrliA3xFvUjThc5 ORVdp1BEhnxDViArn5+MfUm37L8J81bTUMYvFBz5BLsxjznnfZoactQ6x1al3tgF 1k/c7mjIUSGA1Btxo+zkS140Jd3lJ+alXQkCOr6Zgg/nPy1nQa+vdVPN38zzzhUn fkRbvgFb9Eq5QYZTuhcXg4gsQIKT519zMVgx4LnJWyGhxKM01YA3jr7XFZ9apKfE Ot4ry1P7mR2oPykKENucWRAqgzc91YvNw471wANcbbyJkIgZxeWg/oXidocfWonR gyZLGxfyOB+9LbVIOxHJc+wskPUAQhdN+BEdp+Y3uBjJGRJalAWwLdcAPrNmvnyX DELrdVfLGFZ3xwE= =uBDq -----END PGP MESSAGE----- From edgar at spectrx.saigon.com Mon Feb 7 04:31:17 1994 From: edgar at spectrx.saigon.com (Edgar W. Swank) Date: Mon, 7 Feb 94 04:31:17 PST Subject: Remailer Tearline Conventions Message-ID: <4XLDHc12w165w@spectrx.saigon.com> -----BEGIN PGP SIGNED MESSAGE----- Anonymous (not me again) posted this reply to my msg: Uu> At the time I brought this up, the attitude of most remailer operators Uu> (Chael Hall and Miron Cuperman notably excepted) was that anyone who Uu> couldn't figure out how and remember to turn off their auto sig didn't Uu> deserve any privacy. An astonishing bit of Internet provincial fuckheadedness, I must say! Well, you're at least 1/3 right! (:} Uu> I recommend that you always use the wimsey (extropia) remailer as the Uu> first (or only) leg of a remailer chain. It is also the only Uu> Cypherpunks remailer outside the USA (it's in Canada) which will make Uu> tracing msgs a little more difficult for USA authorities. That remail at extropia.wimsey.com is in Canada specifically makes communications with it fair game for NSA interception, however. Good luck, NSA. Better warm up those Crays. Wimsey is also the only remailer to -require- the entire incoming msg to be encrypted with a strong PGP key pub 1024/B5A32F 1992/12/13 Remailer Note this feature doesn't allow the encrypted SASE supported by other Cypherpunks remailers which -allow- encryption but remail any unencrypted text following the encrypted portion (which often includes the auto sig, our original topic). Instead, wimsey supports a pool address: pool0 at extropia.wimsey.com which is essentially a mailing list devoted to broadcasting to its list of subscribers anything mailed to it. You join the mailing list by sending a request to pool0-request at extropia.wimsey.com Typically reply mail would be encrypted to a pseudonymous key you sent via the conventional forward remiler method, so although everyone on the list would receive the message, only the intended recipient could read it. Note that even if the authorities learn you are on the mailing list, you have absolute deniability that you are the intended recipient of any particular message. (But keep the pseudonymous secret key encrypted when not in use). -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVYke94nNf3ah8DHAQHyCgP+N2c32DsO96vUB/bacRqJ0srqKwN7ioJj 1fGT5iNfdYpoXUr/JaDgMs3dX/wjJmA0v7j7GypN7Cla/qmekhRyKqglOmI+U2W4 jsfMO1DfV0MpezyOpQlSjoO1q7cXMjMmbZQl9rQfiRKcaWKT2MeuwF1JQj7ZD3jE YzMlzaC5AsU= =ujoi -----END PGP SIGNATURE----- -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca From dmandl at lehman.com Mon Feb 7 05:46:19 1994 From: dmandl at lehman.com (David Mandl) Date: Mon, 7 Feb 94 05:46:19 PST Subject: Clipper "Above the Fold" Message-ID: <9402071342.AA22956@disvnm2.lehman.com> > From: Duncan Frissell > > Clipper and the Admin decision to adopt same is reported in a front page > (above the fold) article in the Saturday New York Times. > > Usual errors about how the "backdoor" would work and about how warrants > would be required to get the keys. > > All the usual suspects. Good placement though. > > DCF Unfortunately, though, it was pretty soft on Clipper. Significantly, the piece was not written by John Markoff, who's been covering cypherpunk- and crypto-related issues for the Times for a while now. Markoff has been very friendly to "our side." This other guy (sorry, name escapes me) seemed to swallow the USG's line much more uncritically. I wonder why Markoff didn't write Saturday's piece? I'm not subtly suggesting conspiracy theories here, though I'm certainly open-minded about them. Mainly, I'm noting the difference between the two guys' approaches and how strongly they affect the coverage. I did a mini- rant about the piece on my radio show Saturday. --Dave. From mnemonic at eff.org Mon Feb 7 06:26:23 1994 From: mnemonic at eff.org (Mike Godwin) Date: Mon, 7 Feb 94 06:26:23 PST Subject: Clipper "Above the Fold" In-Reply-To: <9402071342.AA22956@disvnm2.lehman.com> Message-ID: <199402071423.JAA26318@eff.org> David Mandl writes: > I wonder why > Markoff didn't write Saturday's piece? Markoff's on vacation. --Mike From danisch at ira.uka.de Mon Feb 7 06:51:35 1994 From: danisch at ira.uka.de (Hadmut Danisch) Date: Mon, 7 Feb 94 06:51:35 PST Subject: ADMIN: list statistics Message-ID: <9402071205.AA05885@deathstar.iaks.ira.uka.de> > 4 de Denmark ^^^ .de is Germany , it stands for 'Deutschland,' the german word for 'Germany'. Don't know what is the sign of Denmark... Hadmut ( danisch at ira.uka.de sitting in Karlsruhe, Germany) From nate at VIS.ColoState.EDU Mon Feb 7 07:11:22 1994 From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons) Date: Mon, 7 Feb 94 07:11:22 PST Subject: some assmunch Message-ID: <9402071510.AA12125@vangogh.VIS.ColoState.EDU> Some assmunch out there sent information on my remailer to a mailing list of list managers of subnets at CSU. This was uncalled for. The list has about 71 people on it, and they really have better things to do. -nate -- +-----------------------------------------------------------------------+ | Nate Sammons | | Colorado State University Computer Visualization Laboratory | | Data Visualization/Interrogation, Modeling, Animation, Rendering | +-----------------------------------------------------------------------+ From adam at bwh.harvard.edu Mon Feb 7 07:31:39 1994 From: adam at bwh.harvard.edu (Adam Shostack) Date: Mon, 7 Feb 94 07:31:39 PST Subject: ADMIN: list statistics In-Reply-To: <9402071205.AA05885@deathstar.iaks.ira.uka.de> Message-ID: <199402071531.KAA16820@duke.bwh.harvard.edu> Hadmut wrote: | > 4 de Denmark | | ^^^ | .de is Germany , it stands for 'Deutschland,' the | german word for 'Germany'. Don't know what is the | sign of Denmark... Its nl, for (I think) Netherlands. Adam From mpjohnso at nyx10.cs.du.edu Mon Feb 7 07:36:23 1994 From: mpjohnso at nyx10.cs.du.edu (Michael Johnson) Date: Mon, 7 Feb 94 07:36:23 PST Subject: PGP Tools & Magic Money Update Message-ID: <9402071530.AA17018@nyx10.cs.du.edu> > it work, but will slow it down. The new version, when it shows up, should > be in the pgp_tools directory. Go to /mpj, read README.MPJ, and it will tell > you how to get into the crypto section. Check the file dates to see if the > new version is there yet. I sent them on 2/6. Sorry, I fumbled reception of the pgptools.zip update... tried an mv to a full disk. The magic money update is there, but the pgptools.zip update will be delayed while I wait for retransmission via some slow remailers. mpj at csn.org From Rolf.Michelsen at delab.sintef.no Mon Feb 7 07:36:26 1994 From: Rolf.Michelsen at delab.sintef.no (Rolf Michelsen) Date: Mon, 7 Feb 94 07:36:26 PST Subject: ADMIN: list statistics In-Reply-To: <9402071205.AA05885@deathstar.iaks.ira.uka.de> Message-ID: On Mon, 7 Feb 1994, Hadmut Danisch wrote: > > 4 de Denmark > > ^^^ > > > .de is Germany , it stands for 'Deutschland,' the > german word for 'Germany'. Don't know what is the > sign of Denmark... > > Hadmut ( danisch at ira.uka.de sitting in Karlsruhe, Germany) > Denmark is ".dk". -- Rolf ---------------------------------------------------------------------- Rolf Michelsen Phone: +47 73 59 87 33 SINTEF DELAB Email: rolf.michelsen at delab.sintef.no 7034 Trondheim Office: C339 Norway ---------------------------------------------------------------------- From pmetzger at lehman.com Mon Feb 7 07:36:37 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Mon, 7 Feb 94 07:36:37 PST Subject: your mail In-Reply-To: <199402051538.KAA07593@eff.org> Message-ID: <199402071535.KAA04605@snark> Mike Godwin says: > > David Koontz writes: > > > All this bullshit doesnot state that a court order is required, rather > > 'legal authorization', which means the NSA for foreign intellingence > > purposes without a court order. > > The Foreign Intelligence Surveillance Act (FISA) requires a court order > for such taps. I seem to remember something about this from The Puzzle Palace. Am I mistaken, or are such orders not made by a special court, which holds secret proceedings and which, so far as is known, has never denied a request? Perry From warlord at MIT.EDU Mon Feb 7 07:46:22 1994 From: warlord at MIT.EDU (Derek Atkins) Date: Mon, 7 Feb 94 07:46:22 PST Subject: ADMIN: list statistics In-Reply-To: <9402071205.AA05885@deathstar.iaks.ira.uka.de> Message-ID: <9402071543.AA05472@toxicwaste.media.mit.edu> Denmark is dk -derek From pmetzger at lehman.com Mon Feb 7 07:51:37 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Mon, 7 Feb 94 07:51:37 PST Subject: Crypto Regulation Reform In-Reply-To: <9402052019.AA10570@vail.tivoli.com> Message-ID: <199402071551.KAA04645@snark> Mike McNally says: > > Robert Cain writes: > > A device can be made right now at lower cost > > than a computer modem, much lower, that could be inserted between any > > phone and the wall that would make it impossible, no matter what laws > > are in place, to tap either passively or acitively, communication that > > passes between two of these devices. I know how to do it, could do it > > and probably will just for the fun of it at least. > > Uhh, could you tell us? Sounds like quite a breakthrough. Credit > card sized? Much cheaper than a modem, like $50 maybe? And it > digititizes and securely encrypts speech (full duplex?) on the fly? By definition anything that does this in the digital domain needs a modem, so it can't be cheaper than a modem. None of the analogue methods are going to be terribly secure. .pm From pmetzger at lehman.com Mon Feb 7 07:56:22 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Mon, 7 Feb 94 07:56:22 PST Subject: Some stuff about Diffie-Hellman (and more :-) In-Reply-To: <199402052205.OAA06854@jobe.shell.portal.com> Message-ID: <199402071555.KAA04653@snark> Hal says: >From: rcain at netcom.com (Robert Cain) > > Now, the tutorial over :-), the question is; is there a "standard" > > well-known-prime, w, and a "standard" well-known-modulus, m, and if > ^^^^^-- generator > > not, let's define one. > > I don't think there is a need for this. The two sides need to agree on > a pair but they could just pick it at the beginning. If everyone uses > the same m,w it would help attackers of the scheme to focus their efforts > on these numbers. Indeed, a paper has been published on how to break Sun Secure RPC based on the idiotic decision by someone at Sun to standardise the modulus used. It is basically a matter of precomputing a lot of data based on the numbers which allows you to break any particular discrete log in that field on the fly. The suggestion by Mr. Cain to use a single generator and modulus for all traffic is astonishingly naive. Perry From frissell at panix.com Mon Feb 7 08:06:22 1994 From: frissell at panix.com (Duncan Frissell) Date: Mon, 7 Feb 94 08:06:22 PST Subject: Safire Mentions NSA Message-ID: <199402071604.AA18104@panix.com> In a column explaining (to the uninitiated) what the networked transformation of human society means (your own Genie sans bottle) William Safire mentioned the wiretap controversy. He has done this before. "Dangers abound: President Clinton has cravenly allowed N.S.A. (No Such Agency) to bug the info highway. Futurethicists wonder if virtuous-reality love can compete with virtual-reality porn. And the big one: how to get our personal genies back in the bottle." DCF --- WinQwk 2.0b#1165 From mnemonic at eff.org Mon Feb 7 08:10:37 1994 From: mnemonic at eff.org (Mike Godwin) Date: Mon, 7 Feb 94 08:10:37 PST Subject: your mail In-Reply-To: <199402071535.KAA04605@snark> Message-ID: <199402071608.LAA27625@eff.org> Perry writes: > Mike Godwin says: > > > > David Koontz writes: > > > > > All this bullshit doesnot state that a court order is required, rather > > > 'legal authorization', which means the NSA for foreign intellingence > > > purposes without a court order. > > > > The Foreign Intelligence Surveillance Act (FISA) requires a court order > > for such taps. > > I seem to remember something about this from The Puzzle Palace. Am I > mistaken, or are such orders not made by a special court, which holds > secret proceedings and which, so far as is known, has never denied a > request? You remember it correctly. --Mike From cfrye at ciis.mitre.org Mon Feb 7 08:16:22 1994 From: cfrye at ciis.mitre.org (Curtis D. Frye) Date: Mon, 7 Feb 94 08:16:22 PST Subject: ADMIN: list statistics Message-ID: <9402071620.AA24015@ciis.mitre.org> Hadmut wrote: > 4 de Denmark ^^^ .de is Germany , it stands for 'Deutschland,' the german word for 'Germany'. Don't know what is the sign of Denmark... Hadmut ( danisch at ira.uka.de sitting in Karlsruhe, Germany) *** The abbreviation for Denmark is ".dk". -- Best regards, Curtis D. Frye - Economic Analyst, Software Alchemist, Aspiring Author cfrye at ciis.mitre.org "If you think I speak for MITRE, I'll tell you how much they pay me and make you feel foolish." From pmetzger at lehman.com Mon Feb 7 08:16:26 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Mon, 7 Feb 94 08:16:26 PST Subject: No Subject In-Reply-To: <199402061953.LAA08152@jobe.shell.portal.com> Message-ID: <199402071615.LAA04694@snark> nobody at shell.portal.com says: > I'm moving to Oceania. Not all of us have the luxury of moving to non-existant places -- most of us are stuck living in real ones. .pm From andrewl at wtg20.wiltel.com Mon Feb 7 08:20:36 1994 From: andrewl at wtg20.wiltel.com (Andrew Loewenstern) Date: Mon, 7 Feb 94 08:20:36 PST Subject: Magic Money on Big Endian Message-ID: <9402071617.AA28202@wtg20> -----BEGIN PGP SIGNED MESSAGE----- I retrieved the latest version of Magic Money from the mpj archive and compiled it on a big-endian machine (a 68k NeXT). It seems to work now... I was able to setup the server and client and move a little cash around whereas before the server would never sucessfully find a q.... andrew -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVZpUXIOIr9VPTMNAQHhjwP/faQUinjX7MxfW84rRfFKhf1TgZcveaPM AjVO8uws3aLv2mhvKl2kYdxLj9LAOzzidZE8bw5RSG6cD4ox90MHjZao9ZOfwvyz VfpWAvWGirrKSGLrrvEXOZnnIk+R2m4ZPFV+duLNjmN6Aw3sa89VLqkiK4me3y1w 1MosXdYtocU= =rdbz -----END PGP SIGNATURE----- From pmetzger at lehman.com Mon Feb 7 08:21:22 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Mon, 7 Feb 94 08:21:22 PST Subject: TEMPEST - Electronic eavesdropping In-Reply-To: <13893.9402062244@heffalump.cs.bham.ac.uk> Message-ID: <199402071617.LAA04702@snark> R.O.Jackson-SE1 at computer-science.birmingham.ac.uk says: > In the US it not illegal to posess TEMPEST-surveillance equipment but > it is illegal to take appropriate counter-measures to prevent > surveillance. This is not true. This is an urban legend that doesn's of fools keep posting over and over again. There is nothing illegal against shielding your equipment -- in fact you are legally obliged to reduce emmissions so as not to interfere with radio and TV signals. Perry From julf at penet.fi Mon Feb 7 08:26:22 1994 From: julf at penet.fi (Johan Helsingius) Date: Mon, 7 Feb 94 08:26:22 PST Subject: ADMIN: list statistics In-Reply-To: <199402071531.KAA16820@duke.bwh.harvard.edu> Message-ID: <199402071622.AA02209@lassie.eunet.fi> > | .de is Germany , it stands for 'Deutschland,' the > | german word for 'Germany'. Don't know what is the > | sign of Denmark... > > Its nl, for (I think) Netherlands. Sigh. Yes. .nl is for The Netherlands. Holland, that is. Denmark is .dk. Julf From mnemonic at eff.org Mon Feb 7 08:26:26 1994 From: mnemonic at eff.org (Mike Godwin) Date: Mon, 7 Feb 94 08:26:26 PST Subject: DOJ procedures relating to Clipper Chips and key escrow Message-ID: <199402071624.LAA27967@eff.org> One of the interesting passages comes at the end of the DOJ memo about obtaining Clipper keys pursuant to an interception: "These procedures do not create, and are not intended to create, any substantive rights for individuals intercepted through electronic surveillance, and noncompliance with these procedures shall not provide the basis for any motion to suppress or other objection to the introduction of electronic surveillance evidence lawfully acquired." What this means, apparently, is that keys or communications obtained through noncompliance with these procedures are nevertheless considered to be "lawfully acquired." No suppression of evidence. No civil suit. In other words, "if we break our rules, tough." --Mike From m5 at vail.tivoli.com Mon Feb 7 08:41:22 1994 From: m5 at vail.tivoli.com (Mike McNally) Date: Mon, 7 Feb 94 08:41:22 PST Subject: ADMIN: list statistics In-Reply-To: <199402071531.KAA16820@duke.bwh.harvard.edu> Message-ID: <9402071640.AA23668@vail.tivoli.com> Adam Shostack writes: > > Don't know what is the sign of Denmark... > > Its nl, for (I think) Netherlands. Gee, that's odd. Oh, I get it! It's a code, explaining the relevance to cypherpunks! -- | 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 m1tca00 at FRB.GOV Mon Feb 7 08:46:22 1994 From: m1tca00 at FRB.GOV (Tom Allard) Date: Mon, 7 Feb 94 08:46:22 PST Subject: A serious question of ethics Message-ID: <9402071643.AA25305@mass6.FRB.GOV> -----BEGIN PGP SIGNED MESSAGE----- nobody at pmantis.berkeley.edu wrote: > Ok, I'm in a bit of a quandry. While surfing the net last week, I > happened across an address addached to a machine that belongs the the > federal reserve. No big deal. I telnetted there on a lark, and entered > 'guest' for the account. It dropped me into a shell. It didn't ask for > a password. Intrigued, I did a little looking around. Nothing special, > a CDRom and about 80 accounts. But(!!), /etc/passwd was there and > available and not using shadows. No, I didn't snatch a copy. - ------- Forwarded Message Date: Mon, 07 Feb 94 11:10:05 -0500 From: m1rcd00 To: m1tca00 Subject: Cypherpunk... Guest login was denied this morning... Well, since someone seems to be home now at Minneapolis, if you wanted to send something back to that list, I suppose it would be OK. If you happened to mention in such a missive that the technical contact here at the Board has no responsibility for or involvement with the Bank machine or network involved, did not fuck up, and was not amused, the technical contact would probably not mind. - - --Bob - ------- End of Forwarded Message -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVZFT6AudFplx0TNAQGZqgP/f8NOdlitIfBV/pAVTBviJ6IOvBArS42L Ntq1+hiXkUbavx3FOdoQCjiQ7IGPHOsH053nY+7YnwECU/Wyatfle2d0JHVNDyxZ ZX1DIKBT+Pkck9fa1xVkdXp86ZTJofNfbykOou+vNqENanTtDeglU9ytzNTA1/fP 1ptoUYFmoGM= =ppC+ -----END PGP SIGNATURE----- From hughes at ah.com Mon Feb 7 08:56:22 1994 From: hughes at ah.com (Eric Hughes) Date: Mon, 7 Feb 94 08:56:22 PST Subject: ADMIN: list statistics In-Reply-To: <9402071205.AA05885@deathstar.iaks.ira.uka.de> Message-ID: <9402071655.AA23516@ah.com> I got .de wrong in the stats. .de is Germany (Deutschland) .dk is Denmark (the incorrect identification for .de) Eric From hughes at ah.com Mon Feb 7 09:06:21 1994 From: hughes at ah.com (Eric Hughes) Date: Mon, 7 Feb 94 09:06:21 PST Subject: Some stuff about Diffie-Hellman (and more :-) In-Reply-To: <199402071555.KAA04653@snark> Message-ID: <9402071704.AA23562@ah.com> >Indeed, a paper has been published on how to break Sun Secure RPC >based on the idiotic decision by someone at Sun to standardise the >modulus used. It wasn't standardization that was the problem. The Sun modulus was just too small. My take on the idiocy was that the designers were assuming that because they didn't know how to break such a large modulus, that no one else did either. >The suggestion by Mr. Cain to use a >single generator and modulus for all traffic is astonishingly naive. It's not naive (as such), it's just that any such modulus must be chosen with extreme care. Here are some very basic rules of thumb: -- Don't use a 2^k modulus. In addition to the exponentiation taking place faster, they're much easier to break. -- Use a single large prime p for the modulus of size > 600 bits. -- Make sure that you can prove that your generator actually generates the group. This requires knowing the factors of p-1. Burt Kaliski told me that he picked a D-H modulus by searching for a pair of primes < q, p=2q+1 >. It took a _long_, _long_ time, but it was then easy to show that the element 2 generated the group. It may be that there is a clever attack based on the generator 2, but I haven't seen one published. Eric From hfinney at shell.portal.com Mon Feb 7 09:10:36 1994 From: hfinney at shell.portal.com (Hal) Date: Mon, 7 Feb 94 09:10:36 PST Subject: A Nice Summary of Motives for Clipper Message-ID: <199402071710.JAA29030@jobe.shell.portal.com> Several people on sci.crypt have pointed to the following paragraph in Matt Blaze's report of the NSA briefing on Clipper, posted here and in the newsgroups: > Clipper chips should be available (to product vendors) in June. You > can't just buy loose chips - they have to be installed in approved > products. Your application interface has to be approved by NIST for > you to get your hands on the chips. This could explain a lot. In particular, if they can enforce this, it could put an end to the dreams of multiple encryption. For months people have been saying, "Clipper? No problem. I'll just encrypt with PGP then pass it through Clipper and the Feds won't ever guess! Ha, ha, ha!" Maybe this won't be so easy. From Blaze's description it sounds like such devices wouldn't be approved. It could be the only Clipper phones will be ones that don't do anything to keep the Feds from picking up the conversation. People could still build non-Clipper encrypting phones (assuming that the constant rumors of threatening midnight visits from NSA agents are false), but the users of those phones could no longer blend in with the Clipper traffic. Hal From mnemonic at eff.org Mon Feb 7 09:36:22 1994 From: mnemonic at eff.org (Mike Godwin) Date: Mon, 7 Feb 94 09:36:22 PST Subject: Safire Mentions NSA In-Reply-To: <199402071604.AA18104@panix.com> Message-ID: <199402071731.MAA00969@eff.org> Duncan writes: > In a column explaining (to the uninitiated) what the networked > transformation of human society means (your own Genie sans bottle) William > Safire mentioned the wiretap controversy. He has done this before. What's the date on this column? --Mike From freeman at MasPar.COM Mon Feb 7 09:40:37 1994 From: freeman at MasPar.COM (Jay R. Freeman) Date: Mon, 7 Feb 94 09:40:37 PST Subject: Cryptographic funnies... Message-ID: <9402071741.AA00535@cleo.MasPar.Com> The 7 Feb. '94 Doonesbury involves encyphered electronic communications... From frissell at panix.com Mon Feb 7 09:41:22 1994 From: frissell at panix.com (Duncan Frissell) Date: Mon, 7 Feb 94 09:41:22 PST Subject: Safire Mentions NSA In-Reply-To: <199402071731.MAA00969@eff.org> Message-ID: On Mon, 7 Feb 1994, Mike Godwin wrote: > > Duncan writes: > > > In a column explaining (to the uninitiated) what the networked > > transformation of human society means (your own Genie sans bottle) William > > Safire mentioned the wiretap controversy. He has done this before. > > What's the date on this column? > > > --Mike > > Sorry, I should have been clearer. The column I quoted appeared in today's NYT. 07 Feb 1994. DCF From dm at hri.com Mon Feb 7 09:46:26 1994 From: dm at hri.com (dm at hri.com) Date: Mon, 7 Feb 94 09:46:26 PST Subject: STEG: a real-life use for steganography In-Reply-To: <9402041840.AA21942@ah.com> Message-ID: <9402071745.AA01363@sparc31.hri.com> I think the proposed scheme is a little top-heavy. What's wrong with clear text? When the Shah still governed Iran, the followers of Khomeini would smuggle his speeches into the country (in clear-text) on cassette tapes of Western popular music. I guess you could call this steganography --- so many ``legitimate'' copies of the tapes were pouring into the country, that the ``subversive'' ones were hard to find among them. I think the tapes actually held a few minutes' worth of the original music, to discourage those zealous customs agents who would actually listen to part of the tape to make sure it is authentic. Similar things existed in the Soviet Union, where they were known as ``Magnetizdat''. And, well, if the police have already gone to the length of confiscating your tapes and listening to them all to find the ones which contain Khomeini's speeches, they've also probably already got you on the train for the Gulag, no matter what they find. From tcmay at netcom.com Mon Feb 7 10:00:36 1994 From: tcmay at netcom.com (Timothy C. May) Date: Mon, 7 Feb 94 10:00:36 PST Subject: Defeating Clipper and Skipjack is Still Possible In-Reply-To: <199402071710.JAA29030@jobe.shell.portal.com> Message-ID: <199402071757.JAA17170@mail.netcom.com> (I've changed the article title to reflect my point here.) Hal Finney writes: ... > This could explain a lot. In particular, if they can enforce this, it > could put an end to the dreams of multiple encryption. For months people > have been saying, "Clipper? No problem. I'll just encrypt with PGP then > pass it through Clipper and the Feds won't ever guess! Ha, ha, ha!" > > Maybe this won't be so easy. From Blaze's description it sounds like > such devices wouldn't be approved. It could be the only Clipper phones > will be ones that don't do anything to keep the Feds from picking up the > conversation. > > People could still build non-Clipper encrypting phones (assuming that > the constant rumors of threatening midnight visits from NSA agents are > false), but the users of those phones could no longer blend in with the > Clipper traffic. For voice use, this may be so (but I think pre-encryption before Clipper is still possible....see discussion at the end). But for the forthcoming _data encryption_ use (Skipjack, etc.), I don't see how "pre-encryption" can be detected, much less blocked, banned, or otherwise interfered with. After all, "data are data." Frankly, it has always been the (presumably) impending restrictions on data encryption that have worried me the most, because it is the application of strong crypto to data encryption that holds the most promise (in such things as digital money, remailers, all the stuff we deal with here on this list). Voice scrambling has never been a high priority for me, personally. Requiring Skipjack encryption for all packets entering the Federal Interstate Dataway (tm) could be a constraining hassle, but what's _inside_ those Skipjacked packets could be arbitrary. (Even an "entropy" filter as part of Skipjack--an implausible complication--could easily be defeated.) If the government requires Skipjack, I can't see any way of preventing pre-encryption, short of "random searches" (analogous to random searches of cargo to detect contraband, etc.). And I suspect some clever work could allow pre-encryption even with Clipper. After all, if the canonical (expected) mode is for two Clipper users to be speaking English to each other, and they start to speak Croation, this is a crude form of encryption (security through obscurity, for a few minutes at least). Even more so if they started speaking their own private code. Clipper would just take the audio signal, manipulate it as it is supposed to, send it, etc. Thus, putting one's own cipher system in _front_ of Clipper (and _after_ it at the receiving end, of course) should work, providing the output of the cipher system is standard audio (constrained by the phone system(s) used). But isn't this exactly what existing secure phones are (like the STU-III)? That is, nothing inside the Clipperphone need be touched or interfaced with. Just use the Clipperphone as usual, but speak in a "language" that cannot be deciphered by the surveillors, even if they get a warrant to look at the Clipper keys. Am I missing something? --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. From nate at VIS.ColoState.EDU Mon Feb 7 10:10:36 1994 From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons) Date: Mon, 7 Feb 94 10:10:36 PST Subject: nate@vis.colostate.edu remailer *GONE* Message-ID: <9402071806.AA12892@vangogh.VIS.ColoState.EDU> -----BEGIN PGP SIGNED MESSAGE----- Everyone out there, plese listen up! The remailer at nate at vis.colostate.edu has been taken down as a result of the posting by some anonymous person to a local list of administrators. I will also be taking down my GUI in Mosaic for the remailer, but the software is still available at: ftp://vangogh.vis.colostate.edu/pub/nate/remailer-GUI/cpremailer.tar.Z thanks for the support, and could someone send me info about netcom accounts? Thanks, - -nate - -- +-----------------------------------------------------------------------+ | Nate Sammons | | Colorado State University Computer Visualization Laboratory | | Data Visualization/Interrogation, Modeling, Animation, Rendering | +-----------------------------------------------------------------------+ From pmetzger at lehman.com Mon Feb 7 10:11:23 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Mon, 7 Feb 94 10:11:23 PST Subject: Some stuff about Diffie-Hellman (and more :-) In-Reply-To: <9402071704.AA23562@ah.com> Message-ID: <199402071810.NAA04869@snark> Eric Hughes says: > >Indeed, a paper has been published on how to break Sun Secure RPC > >based on the idiotic decision by someone at Sun to standardise the > >modulus used. > > It wasn't standardization that was the problem. The Sun modulus was > just too small. My take on the idiocy was that the designers were > assuming that because they didn't know how to break such a large > modulus, that no one else did either. Standardization was also a problem. It meant that the effort to break one exchange could be used to break all of them at once. This seems like a very bad thing. Perry From tcmay at netcom.com Mon Feb 7 10:36:25 1994 From: tcmay at netcom.com (Timothy C. May) Date: Mon, 7 Feb 94 10:36:25 PST Subject: Defeating Clipper and Skipjack is Still Possible In-Reply-To: <199402071757.JAA17170@mail.netcom.com> Message-ID: <199402071833.KAA22964@mail.netcom.com> Let me briefly elaborate on a point I made in my last post: > For voice use, this may be so (but I think pre-encryption before > Clipper is still possible....see discussion at the end). But for the > forthcoming _data encryption_ use (Skipjack, etc.), I don't see how > "pre-encryption" can be detected, much less blocked, banned, or > otherwise interfered with. After all, "data are data." In both this data case and the Clipper voice case, I am assuming the keys for the pre-encryption are negotiated by either prearrangement or by some back-channel, and don't involve D-H or any other such protocol through the Skipjack or Clipper system. (Perhaps this situation, where a bunch of key exchange protocols must be gone through before communication takes place, is what Hal Finney was referring to when he said that the Clipper proposal looks like it will make multiple encryption impossible.) Most of my (few) encrypted communications are by this kind of prearrangement, with PGP being the most obvious case of this, and so a multiple encryption scheme is workable. With voice encryption, I guess the Clipper system will not be very cooperative with D-H and similar protocols. But it will still be possible: 1. Use the Clipperphone to establish who one is communicating with. Alice and Bob thus start talking to each other. 2. Alice says: "Switch to PGP-Voice with my P-K" (and so on). 3. Bob and Alice are thus communicating with PG-Voice, with Clipper doing a further encryption. If the Feds get a warrant to get the Clipper keys, then all they get is PGP-Voice-encrypted junk. Clipper then serves the admirable purpose of _covering_ the further use of encryption! --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. From nobody at pmantis.berkeley.edu Mon Feb 7 10:40:37 1994 From: nobody at pmantis.berkeley.edu (nobody at pmantis.berkeley.edu) Date: Mon, 7 Feb 94 10:40:37 PST Subject: A serious question of ethics Message-ID: <9402071839.AA15102@pmantis.berkeley.edu> On Mon, 7 Feb 1994, Tom Allard wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > nobody at pmantis.berkeley.edu wrote: > > > Ok, I'm in a bit of a quandry. While surfing the net last week, I > > happened across an address addached to a machine that belongs the the > > federal reserve. No big deal. I telnetted there on a lark, and entered > > 'guest' for the account. It dropped me into a shell. It didn't ask for > > a password. Intrigued, I did a little looking around. Nothing special, > > a CDRom and about 80 accounts. But(!!), /etc/passwd was there and > > available and not using shadows. No, I didn't snatch a copy. > > - ------- Forwarded Message > > Date: Mon, 07 Feb 94 11:10:05 -0500 > From: m1rcd00 > To: m1tca00 > Subject: Cypherpunk... > > Guest login was denied this morning... > > Well, since someone seems to be home now at Minneapolis, if you wanted > to send something back to that list, I suppose it would be OK. If you > happened to mention in such a missive that the technical contact here > at the Board has no responsibility for or involvement with the Bank > machine or network involved, did not fuck up, and was not amused, the > technical contact would probably not mind. > > - - --Bob > > > - ------- End of Forwarded Message Does that mean that I no longer should report the open system (I don't dare telnet there to find out if it is the same one)? Also, and I'm purely curious, what actually became of my anonymous report, and do I need to be worried about SS agents in dark sunglasses coming to my home and dragging me away? (Truely worried and scared) From mg5n+ at andrew.cmu.edu Mon Feb 7 10:46:24 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Mon, 7 Feb 94 10:46:24 PST Subject: In-Reply-To: <199402071615.LAA04694@snark> Message-ID: <0hJciae00VojIMAkQt@andrew.cmu.edu> "Perry E. Metzger" wrote: > nobody at shell.portal.com says: > > I'm moving to Oceania. > > Not all of us have the luxury of moving to non-existant places -- > most of us are stuck living in real ones. Yep... but if the Atlantis Project succeeds, I would probably move there, assuming I could find a good source of income... From schneier at chinet.com Mon Feb 7 11:16:25 1994 From: schneier at chinet.com (Bruce Schneier) Date: Mon, 7 Feb 94 11:16:25 PST Subject: Applied Cryptography - Errata Version 1.5.5 Message-ID: APPLIED CRYPTOGRAPHY ERRATA Version 1.5.5 - February 7, 1994 This errata includes all errors I have found in the first and second printings of 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. Page 13: 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 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". Page 36: "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". Page 40: 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 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 in 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 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 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". 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 expansion, not after. And "L_(i)-1" should be "L_(i-1)". 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 3 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 3, 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 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). 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 286: 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 295: First line: "t random integers fewer than n" should be "t random numbers less than n". 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 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". 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:". Page 322: Second paragraph: "over 500 pairs of people" should be "253 pairs of people". 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)". Page 347: 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". Page 353: 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 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: Line 18: "2^t" should be "2^(-t)". Page 407: 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". Page 437: "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 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." 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 mnemonic at eff.org Mon Feb 7 12:16:26 1994 From: mnemonic at eff.org (Mike Godwin) Date: Mon, 7 Feb 94 12:16:26 PST Subject: Newspaper coverage of Administration encryption announcements (fwd) Message-ID: <199402072012.PAA04958@eff.org> Forwarded message: From hughes at ah.com Mon Feb 7 12:31:28 1994 From: hughes at ah.com (Eric Hughes) Date: Mon, 7 Feb 94 12:31:28 PST Subject: DOJ procedures relating to Clipper Chips and key escrow In-Reply-To: <199402071624.LAA27967@eff.org> Message-ID: <9402072025.AA23949@ah.com> >"These procedures do not create, and are not intended to create, >any substantive rights for individuals intercepted through >electronic surveillance, and noncompliance with these procedures >shall not provide the basis for any motion to suppress or other >objection to the introduction of electronic surveillance evidence >lawfully acquired." This reminds me a lot of the language used when describing the changes in FOIA policy, which was something like "The agencies are supposed to be good, but if they're not, this change doesn't change your ability to do anything about it." Is this a Clinton administration policy to make such feel-good, govern-bad pronouncements? Eric From nowhere at bsu-cs.bsu.edu Mon Feb 7 12:36:27 1994 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Mon, 7 Feb 94 12:36:27 PST Subject: MAIL: questionnaire In-Reply-To: <9402051721.AA05442@arcadien.owlnet.rice.edu> Message-ID: <9402072035.AA22679@bsu-cs.bsu.edu> Karl Barrus writes: >bsu-cs: >Run by Chael Hall. >Contact at same address Machine: University departmental machine (fairly secure) Security: syslog file can be read >chaos: >Run by Chael Hall. >Contact at same address Machine: Privately owned (secure) Security: syslog file can only be read by root (me) [used for statistics] Contact nowhere at chaos.bsu.edu or remailer-admin at chaos.bsu.edu (both) Software: C program written by myself. Source available upon request. Policy: Under construction Chael -- Chael Hall nowhere at bsu-cs.bsu.edu nowhere at chaos.bsu.edu From wcs at anchor.ho.att.com Mon Feb 7 12:40:37 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Mon, 7 Feb 94 12:40:37 PST Subject: DOJ procedures relating to Clipper Chips and key escrow Message-ID: <9402072039.AA26355@anchor.ho.att.com> Mike Godwin writes: > One of the interesting passages comes at the end of the DOJ memo > about obtaining Clipper keys pursuant to an interception: > > "These procedures do not create, and are not intended to create, > any substantive rights for individuals intercepted through > electronic surveillance, and noncompliance with these procedures > shall not provide the basis for any motion to suppress or other > objection to the introduction of electronic surveillance evidence > lawfully acquired." > > What this means, apparently, is that keys or communications obtained > through noncompliance with these procedures are nevertheless considered > to be "lawfully acquired." No suppression of evidence. No civil suit. > > In other words, "if we break our rules, tough." I thought that was particularly amusing as well. On the other hand, the mere fact that it says it doesn't mean it invalidates any other privacy laws or rules about illegal surveillance or exclusion of evidence, though it does mean you need to argue a lot harder to get a judge to agree. # Bill Stewart AT&T Global Information Solutions, aka NCR Corp # 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204 # email bill.stewart at pleasantonca.ncr.com billstewart at attmail.com # ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465 From mnemonic at eff.org Mon Feb 7 12:41:44 1994 From: mnemonic at eff.org (Mike Godwin) Date: Mon, 7 Feb 94 12:41:44 PST Subject: DOJ procedures relating to Clipper Chips and key escrow In-Reply-To: <9402072025.AA23949@ah.com> Message-ID: <199402072040.PAA05318@eff.org> Eric writes: > This reminds me a lot of the language used when describing the changes > in FOIA policy, which was something like "The agencies are supposed to > be good, but if they're not, this change doesn't change your ability > to do anything about it." > > Is this a Clinton administration policy to make such feel-good, > govern-bad pronouncements? If anything, the Clinton announcements are far more generous than those of Reagan and Bush. --Mike From wcs at anchor.ho.att.com Mon Feb 7 12:50:37 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Mon, 7 Feb 94 12:50:37 PST Subject: Bogus paper on TEMPEST floating around Message-ID: <9402072047.AA26538@anchor.ho.att.com> This bogus paper with lots of misinformation about TEMPEST is still around, though I'm surprised to see it on a NIST machine. (FTP didn't want to connect this morning, so I can't be sure it's still there.) Papers by the fictitious Hagbard Celine can't always be trusted, though they make good rolling papers if you print them out :-) But it's clearly a bunch of Discordian Disinformation. Yes, some of the TEMPEST specs are classified, it's perfectly legal to disseminate the publicly available information and technology, apply it, and use it, and do anything you want to make your equipment quiet. Even the expansion of the acronym given in the paper was bogus, and it went downhill from there. # Bill Stewart AT&T Global Information Solutions, aka NCR Corp # 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204 # email bill.stewart at pleasantonca.ncr.com billstewart at attmail.com # ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465 From gnu Mon Feb 7 13:14:48 1994 From: gnu (John Gilmore) Date: Mon, 07 Feb 94 13:14:48 -0800 Subject: [whitfield.diffie@Eng.Sun.COM: Preliminary remarks] Message-ID: <9402072114.AA20669@toad.com> ------- Forwarded Message To: gnu at toad.com From: whitfield.diffie at Eng.Sun.COM From koontzd at lrcs.loral.com Mon Feb 7 13:20:37 1994 From: koontzd at lrcs.loral.com (David Koontz ) Date: Mon, 7 Feb 94 13:20:37 PST Subject: DOJ procedures relating to Clipper Chips and key escrow Message-ID: <9402072119.AA10397@io.lrcs.loral.com> > From: hughes at ah.com (Eric Hughes) >Is this a Clinton administration policy to make such feel-good, >govern-bad pronouncements? Double plus ++ungood. Needless to say, I had trouble parsing this. From mg5n+ at andrew.cmu.edu Mon Feb 7 13:36:29 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Mon, 7 Feb 94 13:36:29 PST Subject: Atlantis Project/Oceania In-Reply-To: <199402072012.OAA10440@alpha1.csd.uwm.edu> Message-ID: Since the subject came up, I'll explain it to those of you who hadn't heard of the Atlantis Project: The Atlantis Project is a group in Las Vegas which is trying to build a floating city in the Caribbean sea. Their new city would be an independant nation called Oceania. The country would have a limited government, and their constitution outlines many specific rights given to the people, among them, the right to use cryptography. You can email them at oceania at world.std.com and ask for more info. From mnemonic at eff.org Mon Feb 7 14:06:30 1994 From: mnemonic at eff.org (Mike Godwin) Date: Mon, 7 Feb 94 14:06:30 PST Subject: EFF Wants You (to add your voice to the crypto fight) Message-ID: <199402072201.RAA06559@eff.org> Forwarded message: From hayden at krypton.mankato.msus.edu Mon Feb 7 14:16:29 1994 From: hayden at krypton.mankato.msus.edu (Robert A. Hayden) Date: Mon, 7 Feb 94 14:16:29 PST Subject: Atlantis Project/Oceania In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- On Mon, 7 Feb 1994, Matthew J Ghio wrote: > Since the subject came up, I'll explain it to those of you who hadn't > heard of the Atlantis Project: > > The Atlantis Project is a group in Las Vegas which is trying to build a > floating city in the Caribbean sea. Their new city would be an > independant nation called Oceania. The country would have a limited > government, and their constitution outlines many specific rights given > to the people, among them, the right to use cryptography. You can email > them at oceania at world.std.com and ask for more info. Sounds kool, in a utopian sort of way. Of course, the U.S. will immediately declare they a national threat and bomb them back to the stone age. :-) ____ Robert A. Hayden <=> hayden at krypton.mankato.msus.edu \ /__ -=-=-=-=- <=> -=-=-=-=- \/ / Finger for Geek Code Info <=> In the United States, they \/ Finger for PGP 2.3a Public Key <=> first came for us in Colorado... - -=-=-=-=-=-=-=- (GEEK CODE 1.0.1) GAT d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++ n-(---) h+(*) f+ g+ w++ t++ r++ y+(*) -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVa94p3BsrEqkf9NAQF9gQP/f71hQtnsZUYA8sxABa69RItyA8pOQ2QQ F9y9cuk0QKzabfEo6uColYpdtk0AVt57pFh+bSivUNjrOYfdj42J6MZf2eT2mDt9 O7JhmdP9hSPIMx2IdfEq+aCOF0SO47lSmJsqct51o5TUvCx0mC9SLTBqWT3ZCbcS Ho7lrI4b0SY= =k2vE -----END PGP SIGNATURE----- From qwerty at netcom.com Mon Feb 7 14:30:40 1994 From: qwerty at netcom.com (Xenon) Date: Mon, 7 Feb 94 14:30:40 PST Subject: Nate's Remailer Shutdown. Message-ID: <199402072231.OAA10521@mail.netcom.com> -----BEGIN PGP SIGNED MESSAGE----- I am responding publicly to a letter I got from Nate about his wanting to know who sent the naughty mail to the subnet- managers at yuma.acns.colostate.edu. It was remailed from somewhere to qwerty, and then through Nate's remailer. For gossip's sake, I'd sure like to see what it said :-). Sorry to hear about your remailer. It's good for all of us to have such "minor" problems come up and be dealt with. I am keeping no logs except a counter. This isn't a policy, it's just a decision for now. However, if the 70 people on the list care to they can certainly contact Netcom and ask for a copy of their sendmail logs for that day. I'm sure if the mail was sent to a police address saying "Nah nah you can't find me I'm selling guns to little kids." then this would happen. I know that with my software (Hal's updated), once such a problem happens, I can just block that outgoing address. This isn't exactly a perfect solution, but I don't WANT a perfect solution. This isn't IRAQ, no matter how global the internet is. I'm not sure how to block an incoming address from say Detweiler. My model is based on the postal service. Why is e-mail supposed to be so much more accountable? With snail mail someone can send a real bomb, not a wimpy mail bomb. And yet it is perfectly legal to leave out a return address. Qwerty is a mailbox. An inanimate object. I do not like the internet. I like the postal service. You NEVER see someone like Detweiler abusing snail mail anonymity with the purpose of trying to shut down or change the policy of the US Postal Service! I think remailers should be able to strip the From line completely, but as I pointed out, this would be "frowned upon", and may not even be feasible to do vigorously. I thought the internet was anarchic and free. Fun and creative. Oops. Oh well. Again, "You ain't PUNKS, if you timidly play by the rules of others." I'm not talking illegality. In fact, I'm talking life, liberty, and pursuit of happiness. Insert constituion and Bill of Rights buzzwords here. I think it might be nice for the remailers to block certain outgoing address TYPES, such as "subnet-manager", but I don't know which others since I'm new around here. The information is available on Netcom's logs. It probably just points to another remailer. Welcome to the postal service. Same as it ever was. Don't blame the mailman, and especially not the mailbox. The day all mailboxes have cameras atop them and require retinal ID before they take your logged mail is the day people realize how bad it is out here in cyberspace. 8, 8 ,8 8, 8 ,8 8, 8 ,8 Yb d8b dY Yb d8b dY Yb d8b dY `8, ,8'8, ,8' `8, ,8'8, ,8' `8, ,8'8, ,8' Yb dY Yb dY Yb dY Yb dY Yb dY Yb dY `8, ,8' `8, ,8 `8, ,8' `8, ,8' `8, ,8' `8, ,8' Y8 8Y Y8 8Y Y8 8Y Y8 8Y Y8 8Y Y8 8Y YaY YaY YaY YaY YaY YaY `8' `8' O R L D `8' `8' I D E `8' `8' I R E T A P -=Xenon=- P.S. "Get Off the Internet and Write Us a Real Encryptor." Your species desires PGP to have a random data block output format. Now. -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLVZ5vASzG6zrQn1RAQEEMwQAwejxfCFLdKy/jsggYfU1qANBXYe17oTt o31cMzEsFeS1cSyrexEObohZM6HKZefM34SMj5saaxn0HsR+sT3Xk2i+VIqPfBJf K17wa1jnOQDc77UYGy+f3KulNkHstCeE05D2GGA471NirwW8/YrC2tGKe4TqrFLP XEtvD9mPO2M= =huRE -----END PGP SIGNATURE----- From mnemonic at eff.org Mon Feb 7 14:31:29 1994 From: mnemonic at eff.org (Mike Godwin) Date: Mon, 7 Feb 94 14:31:29 PST Subject: reno_key_escrow.statement (fwd) In-Reply-To: <9402071501.AA11306@mail.wm.edu> Message-ID: <199402072231.RAA07108@eff.org> Trotter writes: > Thanks to Mike Godwin for forwarding the announcement about the > Clipper chip stuff. I am not a Constitutional law person or > criminal preceedure person, but if I understand this proposal > correctly, it does not require a member of the judiciary to be > involved. Not at the key-escrow phase, no. But you have to have a valid search warrant or authorization order in hand before you can go to the escrow agencies and request the partial keys. Here's the relevant language: > > ATTORNEY GENERAL MAKES KEY ESCROW ENCRYPTION ANNOUNCEMENTS > > > > When an authorized government agency encounters suspected key- > > escrow encryption, a written request will have to be submitted to > > the two escrow agents. The request will, among other things, have > > to identify the responsible agency and the individuals involved; > > certify that the agency is involved in a lawfully authorized ^^^^^^^^^^^^^^^^^^^^^ > > wiretap; specify the wiretap's source of authorization and its ^^^^^^^^^^^^^^^^^^^^^^^ > > duration; and specify the serial number of the key-escrow > > encryption chip being used. In every case, an attorney involved in > > the investigation will have to provide the escrow agents assurance > > that a validly authorized wiretap is being conducted. The reason that Reno doesn't just say "a court-ordered wiretap" is that there are some emergency circumstances under which wiretap authorization can be gotten in advance of approval by a neutral magistrate. Both the Wiretap Act and the Foreign Intelligence Surveillance Act make provisions for such emergencies. Eventually, such emergency wiretaps do have to be reviewed by a magistrate, however. In the Wiretap Act, and, I believe, in FISA, the time limit is 48 hours. --Mike From mnemonic Mon Feb 7 12:10:49 1994 From: mnemonic (Mike Godwin) Date: Mon, 7 Feb 1994 15:10:49 -0500 (EST) Subject: Newspaper coverage of Administration encryption announcements Message-ID: <199402072010.PAA04906@eff.org> The Washington Post, the New York Times, and the Wall Street Journal have all published stories over the last three days concerning the Administration's announcement on Friday, Feb. 5, 1994, that it will continue to deploy the controversial "Clipper Chip" encryption technology and will not significantly change its export controls. >From the Post on Saturday: "That means the administration will continue long-standing restrictions on exports of powerful encryption devices that the NSA cannot crack, and continue to encourage use of NSA-developed encryption gear, called the "Clipper chip," by all U.S. firms. The Clipper Chip makes it relatively easy for the government to eavesdrop on encrypted communications.... "Further, government officials said, the administration is expected in a few weeks to endorse an FBI proposal that U.S. telecommunications firms be required to guarantee law enforcement agencies' ability to tape phone and computer lines regardless of where the technology goes. "At the core of these high-tech disputes lies a fundamental conflict between Americans' cherished privacy rights and the government's investigative needs." >From the Times on Saturday: "But the Administration's action immediately drew a chorus of criticism from both business and privacy-rights groups. Computer and software companies, including Apple Computer, I.B.M. and Microsoft, have adamantly opposed the Clipper Chip because they believe customers will not trust an encryption program that was built by the government and whose inner workings remain a secret. "Perhaps more importantly, they fear that it will harm their ability to export products; they predict that foreign customers will resist buying computers and telecommunications equipment built with decoding technology devised by the National Security Agency. "Privacy-rights groups argue that the technology could lead to unauthorized eavesdropping, because the keys for unscrambling the code will remain in official hands. "'This is bad for privacy, bad for security and bad for exports,' said Jerry Berman, executive director of the Electronic Frontier Foundation, a Washington nonprofit group that lobbies on privacy issues related to electronic networks. 'The Administration is preparing to implement systems that the public will not trust, that foreign countries will not buy, and that terrorists will overcome.'" >From the Wall Street Journal on Monday: "The issue has become a controversial one between law enforcement officials and the computer industry and civil libertarians. In unfolding details of the administration's decision, Mike Nelson, an official at the Office of Science and Technology Policy, said the issue was so difficult it represented 'the Bosnia of telecommunications policy.' "Jerry Berman, executive director of the Electronic Frontier Foundation, a Washington-based computer users' civil-rights group, said the administration's handling of the Clipper Chip policy could make it 'as successful' as the Bosnia policy, which has come under widespread criticism." William Safire has also written about this in today's NYTimes. >From owner-cypherpunks Mon Feb 7 15:40:40 1994 From kevin at axon.cs.byu.edu Mon Feb 7 15:16:30 1994 From: kevin at axon.cs.byu.edu (Kevin Vanhorn) Date: Mon, 7 Feb 94 15:16:30 PST Subject: reno_key_escrow.statement (fwd) In-Reply-To: <199402072231.RAA07108@eff.org> Message-ID: <9402072316.AA20220@axon.cs.byu.edu> Mike Godwin writes, about Clipper's key-escrow: > But you have to have a valid search > warrant or authorization order in hand before you can go to the escrow > agencies and request the partial keys. > > Here's the relevant language: > > > ATTORNEY GENERAL MAKES KEY ESCROW ENCRYPTION ANNOUNCEMENTS > > > > > > When an authorized government agency encounters suspected key- > > > escrow encryption, a written request will have to be submitted to > > > the two escrow agents. The request will, among other things, have > > > to identify the responsible agency and the individuals involved; > > > certify that the agency is involved in a lawfully authorized > ^^^^^^^^^^^^^^^^^^^^^ > > > wiretap; specify the wiretap's source of authorization and its > ^^^^^^^^^^^^^^^^^^^^^^^ > > > duration; and specify the serial number of the key-escrow > > > encryption chip being used. In every case, an attorney involved in > > > the investigation will have to provide the escrow agents assurance > > > that a validly authorized wiretap is being conducted. But the word "warrant" appears nowhere in there. The agencies requesting the keys aren't required to present a warrant; they're only required to promise that they're lawfully authorized. And if they lie the evidence is still admissible in court and they suffer no penalty. And what does "lawfully authorized" really mean? Depending on what legislation Congress passes, it could mean no more than "my supervisor approved it". ----------------------------------------------------------------------------- Kevin S. Van Horn | It is the means that determine the ends. kevin at bert.cs.byu.edu | From mnemonic at eff.org Mon Feb 7 15:20:41 1994 From: mnemonic at eff.org (Mike Godwin) Date: Mon, 7 Feb 94 15:20:41 PST Subject: reno_key_escrow.statement (fwd) In-Reply-To: <9402072316.AA20220@axon.cs.byu.edu> Message-ID: <199402072319.SAA08343@eff.org> Kevin writes: > But the word "warrant" appears nowhere in there. The agencies requesting > the keys aren't required to present a warrant; they're only required to > promise that they're lawfully authorized. You're misunderstanding the language. Strictly speaking, law-enforcement agents who seek wiretaps receive "authorization orders," not warrants. So the word "authorized" is perfectly appropriate. --Mike From Patrick_May at dtv.sel.sony.com Mon Feb 7 15:36:30 1994 From: Patrick_May at dtv.sel.sony.com (Patrick May) Date: Mon, 7 Feb 94 15:36:30 PST Subject: A Nice Summary of Motives for Clipper In-Reply-To: <199402061911.LAA20333@mail.netcom.com> Message-ID: <9402072329.AA24031@hugehub> Timothy C. May writes: > [Explanation of why Clipper will be prevalent in five years > deleted.] Mr. May's arguments are eloquent and convincing as usual, but it occurs to me that one important point is being overlooked in this discussion: the algorithm will not be a secret forever. Even in the worst case scenario, where all major players in the industry knuckle under to the government (including those currently planning to use other systems), the situation will be resolved as soon as either Clipper or one of its designers is reverse-engineered. The more widespread is the chip, the greater the blow to the government. With the algorithm known there is no way to prevent compatible, non-escrowed, devices from being used, and it would be costly and embarrassing to attempt to recall 100 million "secure" chips. So, how long will we likely have to put up with this abomination? Regards, Patrick May (no known relation, tentacular or otherwise) From freeman at MasPar.COM Mon Feb 7 16:20:41 1994 From: freeman at MasPar.COM (Jay R. Freeman) Date: Mon, 7 Feb 94 16:20:41 PST Subject: A Nice Summary of Motives for Clipper Message-ID: <9402080022.AA00944@cleo.MasPar.Com> Patrick May says: > the [Clipper] algorithm will not be a secret forever ... A fascinating point! Perhaps Clipper's accomplishment will ultimately be positive, serving to inculcate upon us all the habit and administrative forms of routine use of cryptography, albeit in flawed implementation. Thus when the algorithm is unraveled, the transition to widespread use of a more nearly adequate cryptographic standard may well be very rapid indeed. -- Jay Freeman From wcs at anchor.ho.att.com Mon Feb 7 16:40:41 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Mon, 7 Feb 94 16:40:41 PST Subject: Atlantis Project/Oceania Message-ID: <9402080036.AA00215@anchor.ho.att.com> > > The Atlantis Project is a group in Las Vegas which is trying to build a > > floating city in the Caribbean sea. Their new city would be an > .... > Of course, the U.S. will immediately declare they a national threat and > bomb them back to the stone age. :-) Which is kind of a problem for a floating city, since stones don't float very well, concrete canoes excepted :-) I'm not sure their economics can float that well either - if it costs $500M to build, and holds 1000 people, that means $500K/person.... Maybe they're looking at more people or less money. Nice T-Shirts and promo material, though. From qwerty-remailer at netcom.com Mon Feb 7 16:41:30 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Mon, 7 Feb 94 16:41:30 PST Subject: Nate's Remailer Shutdown. Message-ID: <199402080041.QAA02332@mail.netcom.com> The reasons the Post Office gets more slack are that 1) They're the government, or at least used to be 2) They can randomly open mail when they feel like it, see 1) From mnemonic Mon Feb 7 13:59:32 1994 From: mnemonic (Mike Godwin) Date: Mon, 7 Feb 1994 16:59:32 -0500 (EST) Subject: EFF Wants You (to add your voice to the crypto fight) Message-ID: <199402072159.QAA06512@eff.org> * DISTRIBUTE WIDELY * Monday, February 7th, 1994 From: Jerry Berman, Executive Director of EFF jberman at eff.org Dear Friends on the Electronic Frontier, I'm writing a personal letter to you because the time has now come for action. On Friday, February 4, 1994, the Administration announced that it plans to proceed on every front to make the Clipper Chip encryption scheme a national standard, and to discourage the development and sale of alternative powerful encryption technologies. If the government succeeds in this effort, the resulting blow to individual freedom and privacy could be immeasurable. As you know, over the last three years, we at EFF have worked to ensure freedom and privacy on the Net. Now I'm writing to let you know about something *you* can do to support freedom and privacy. *Please take a moment to send e-mail to U.S. Rep. Maria Cantwell (cantwell at eff.org) to show your support of H.R. 3627, her bill to liberalize export controls on encryption software.* I believe this bill is critical to empowering ordinary citizens to use strong encryption, as well as to ensuring that the U.S. software industry remains competitive in world markets. Here are some facts about the bill: Rep. Cantwell introduced H.R. 3627 in the House of Representatives on November 22, 1993. H.R. 3627 would amend the Export Control Act to move authority over the export of nonmilitary software with encryption capabilities from the Secretary of State (where the intelligence community traditionally has stalled such exports) to the Secretary of Commerce. The bill would also invalidate the current license requirements for nonmilitary software containing encryption capablities, unless there is substantial evidence that the software will be diverted, modified or re-exported to a military or terroristic end-use. If this bill is passed, it will greatly increase the availability of secure software for ordinary citizens. Currently, software developers do not include strong encryption capabilities in their products, because the State Department refuses to license for export any encryption technology that the NSA can't decipher. Developing two products, one with less secure exportable encryption, would lead to costly duplication of effort, so even software developed for sale in this country doesn't offer maximum security. There is also a legitimate concern that software companies will simply set up branches outside of this country to avoid the export restrictions, costing American jobs. The lack of widespread commercial encryption products means that it will be very easy for the federal government to set its own standard--the Clipper Chip standard. As you may know, the government's Clipper Chip initiative is designed to set an encryption standard where the government holds the keys to our private conversations. Together with the Digital Telephony bill, which is aimed at making our telephone and computer networks "wiretap-friendly," the Clipper Chip marks a dramatic new effort on the part of the government to prevent us from being able to engage in truly private conversations. We've been fighting Clipper Chip and Digital Telephony in the policy arena and will continue to do so. But there's another way to fight those initiatives, and that's to make sure that powerful alternative encryption technologies are in the hands of any citizen who wants to use them. The government hopes that, by pushing the Clipper Chip in every way short of explicitly banning alternative technologies, it can limit your choices for secure communications. Here's what you can do: I urge you to write to Rep. Cantwell today at cantwell at eff.org. In the Subject header of your message, type "I support HR 3627." In the body of your message, express your reasons for supporting the bill. EFF will deliver printouts of all letters to Rep. Cantwell. With a strong showing of support from the Net community, Rep. Cantwell can tell her colleagues on Capitol Hill that encryption is not only an industry concern, but also a grassroots issue. *Again: remember to put "I support HR 3627" in your Subject header.* This is the first step in a larger campaign to counter the efforts of those who would restrict our ability to speak freely and with privacy. Please stay tuned--we'll continue to inform you of things you can do to promote the removal of restrictions on encryption. In the meantime, you can make your voice heard--it's as easy as e-mail. Write to cantwell at eff.org today. Sincerely, Jerry Berman Executive Director, EFF jberman at eff.org P.S. If you want additional information about the Cantwell bill, send e-mail to cantwell-info at eff.org. To join EFF, write membership at eff.org. The text of the Cantwell bill can be found with the any of the following URLs (Universal Resource Locaters): ftp://ftp.eff.org/pub/Policy/Legislation/cantwell.bill http://www.eff.org/ftp/EFF/Policy/Legislation/cantwell.bill gopher://gopher.eff.org/00/EFF/legislation/cantwell.bill From mg5n+ at andrew.cmu.edu Mon Feb 7 17:50:40 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Mon, 7 Feb 94 17:50:40 PST Subject: Atlantis Project/Oceania In-Reply-To: <9402080036.AA00215@anchor.ho.att.com> Message-ID: wcs at anchor.ho.att.com (bill.stewart at pleasantonca.ncr.com +1-510-484-6204) wrote: > > Of course, the U.S. will immediately declare they a national threat > > and bomb them back to the stone age. :-) > > Which is kind of a problem for a floating city, since stones don't > float very well, concrete canoes excepted :-) Actually, they plan to build it on 3-acre concrete hexagonal platforms with hollow centers so that they float. > I'm not sure their economics can float that well either - if it > costs $500M to build, and holds 1000 people, that means > $500K/person.... Maybe they're looking at more people or less > money. Nice T-Shirts and promo material, though. I think their projections were a billion dollars to build it and a population of 20,000 - 30,000... I was just wondering what sort of business one might engage in in Oceania? Cryptographic software is a possibility, but I wonder how much revenue that might bring in. A electronic bank would probably be a more profitable venture, but getting a high bandwidth net connection in the middle of the ocean would increase startup costs. Telecom, electricity, and water supply would probably be good businesses...but they require a local market that would be fairly small in the startup country. There is also international shipping and trade, but there you have large startup costs and would need to do extensive work to get clients. And there is tourism...gambling, recreational drugs, etc.... From blancw at microsoft.com Mon Feb 7 18:20:41 1994 From: blancw at microsoft.com (Blanc Weber) Date: Mon, 7 Feb 94 18:20:41 PST Subject: Atlantis Project/Oceania Message-ID: <9402080217.AA23708@netmail.microsoft.com> "I'm not sure their economics can float that well either - if it costs $500M to build, and holds 1000 people, that means $500K/person.... Maybe they're looking at more people or less money. Nice T-Shirts and promo material, though." ...................... Does it not seem that they are putting more effort into the publicity, marketing, & attraction of money for support of this virtual country, than into the establishment of other fundamentals? Like: setting up an alternative currency & banking system, the manner of conducting business with the rest of the conventional world, and resolving the many little problems that would be of concern when living under such conditions? Blanc From nate at VIS.ColoState.EDU Mon Feb 7 18:56:32 1994 From: nate at VIS.ColoState.EDU (CVL staff member Nate Sammons) Date: Mon, 7 Feb 94 18:56:32 PST Subject: Atlantis Project/Oceania In-Reply-To: Message-ID: <9402080248.AA14992@vangogh.VIS.ColoState.EDU> writes Matthew J Ghio: > >profitable venture, but getting a high bandwidth net connection in the >middle of the ocean would increase startup costs. Telecom, electricity, Well, a satellite dish can transfer around 100MB (megaBytes, not bits) per second. I'm not too sure how much this kind of link costs, but I would also assume that the Oceania people aren't going to go without a network conection to start. -nate -- +-----------------------------------------------------------------------+ | Nate Sammons | | Colorado State University Computer Visualization Laboratory | | Data Visualization/Interrogation, Modeling, Animation, Rendering | +-----------------------------------------------------------------------+ From cknight at crl.com Mon Feb 7 19:06:32 1994 From: cknight at crl.com (Chris Knight) Date: Mon, 7 Feb 94 19:06:32 PST Subject: Atlantis Project/Oceania In-Reply-To: Message-ID: On Mon, 7 Feb 1994, Matthew J Ghio wrote: > I was just wondering what sort of business one might engage in in > Oceania? Cryptographic software is a possibility, but I wonder how much > revenue that might bring in. A electronic bank would probably be a more > profitable venture, but getting a high bandwidth net connection in the > middle of the ocean would increase startup costs. Telecom, electricity, > and water supply would probably be good businesses...but they require a > local market that would be fairly small in the startup country. There > is also international shipping and trade, but there you have large > startup costs and would need to do extensive work to get clients. And > there is tourism...gambling, recreational drugs, etc.... Have you read "Oath of Fealty" by Larry Niven? Check it out, it's a good sci-fi that outlines just this kind of project. And please, read the tribute in the front... -ck From mg5n+ at andrew.cmu.edu Mon Feb 7 19:10:42 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Mon, 7 Feb 94 19:10:42 PST Subject: Atlantis Project/Oceania In-Reply-To: <9402080217.AA23708@netmail.microsoft.com> Message-ID: Blanc Weber wrote: > Does it not seem that they are putting more effort into the publicity, > marketing, & attraction of money for support of this virtual country, > than into the establishment of other fundamentals? Like: setting up > an alternative currency & banking system... I thought that's what cypherpunks were supposed to be doing... :-) > ... the manner of conducting business with the rest of the conventional > world, and resolving the many little problems that would be of > concern when living under such conditions? All they said on the subject was that the government would be on the gold standard and everyone else could use whatever currency they wanted. As for the other little problems, I'd guess they haven't got a clue. However, they did hire an architect who is experienced in building floating structures, so I guess he's considered those things, ya know like fresh water and electricity. You could drop them an email and ask... From karn at qualcomm.com Mon Feb 7 19:16:32 1994 From: karn at qualcomm.com (Phil Karn) Date: Mon, 7 Feb 94 19:16:32 PST Subject: Atlantis Project/Oceania In-Reply-To: <9402080248.AA14992@vangogh.VIS.ColoState.EDU> Message-ID: <199402080314.TAA24549@servo.qualcomm.com> >Well, a satellite dish can transfer around 100MB (megaBytes, not bits) >per second. I'm not too sure how much this kind of link costs, but I >would also assume that the Oceania people aren't going to go without a >network conection to start. Depends entirely on what it's pointing at. The actual throughput for a single transponder on a conventional Ku-band DOMSAT is more like 45 megabits/sec. Because of fiber, satellites are fast falling out of favor for high capacity point-to-point links. They're now used mainly for "thin route" traffic, especially to remote or mobile locations, and for broadcasting. Phil From mg5n+ at andrew.cmu.edu Mon Feb 7 19:41:32 1994 From: mg5n+ at andrew.cmu.edu (Matthew J Ghio) Date: Mon, 7 Feb 94 19:41:32 PST Subject: nate@vis.colostate.edu remailer *GONE* In-Reply-To: <9402071806.AA12892@vangogh.VIS.ColoState.EDU> Message-ID: nate at VIS.ColoState.EDU typed: > Everyone out there, plese listen up! The remailer at > nate at vis.colostate.edu has been taken down as a result of the posting > by some anonymous person to a local list of administrators. Sorry to hear that. I have removed it from my listing at . Perhaps in the future, remailers will make it a policy to block all mail addressed to their site. At least that way you could blame it on a remailer at another site. :-( From banisar at washofc.cpsr.org Mon Feb 7 20:00:42 1994 From: banisar at washofc.cpsr.org (Dave Banisar) Date: Mon, 7 Feb 94 20:00:42 PST Subject: Campaign Against Clipper Message-ID: <00541.2843506175.2994@washofc.cpsr.org> Campaign Against Clipper CPSR ANNOUNCES CAMPAIGN TO OPPOSE CLIPPER PROPOSAL Embargoed until 2 pm, Monday, February 7, 1994 contact: rotenberg at washofc.cpsr.org (202 544 9240) Washington, DC -- Following the White House decision on Friday to endorse a secret surveillance standard for the information highway, Computer Professionals for Social Responsibility (CPSR) today announced a national campaign to oppose the government plan. The Clipper proposal, developed in secret by the National Security Agency, is a technical standard that will make it easier for government agents to wiretap the emerging data highway. Industry groups, professional associations and civil liberties organizations have expressed almost unanimous opposition to the plan since it was first proposed in April 1993. According to Marc Rotenberg, CPSR Washington director, the Administration made a major blunder with Clipper. "The public does not like Clipper and will not accept it. This proposal is fatally flawed." CPSR cited several problems with the Clipper plan: o The technical standard is subject to misuse and compromise. It would provide government agents with copies of the keys that protect electronic communications. "It is a nightmare for computer security," said CPSR Policy Analyst Dave Banisar. o The underlying technology was developed in secret by the NSA, an intelligence agency responsible for electronic eavesdropping, not privacy protection. Congressional investigations in the 1970s disclosed widespread NSA abuses, including the illegal interception of millions of cables sent by American citizens. o Computer security experts question the integrity of the technology. Clipper was developed in secret and its specifications are classified. CPSR has sued the government seeking public disclosure of the Clipper scheme. o NSA overstepped its legal authority in developing the standard. A 1987 law explicitly limits the intelligence agency's power to set standards for the nation's communications network. o There is no evidence to support law enforcement's claims that new technologies are hampering criminal investigations. CPSR recently forced the release of FBI documents that show no such problems. o The Administration ignored the overwhelming opposition of the general public. When the Commerce Department solicited public comments on the proposal last fall, hundreds of people opposed the plan while only a few expressed support. CPSR today announced four goals for its campaign to oppose the Clipper initiative: o First, to educate the public about the implications of the Clipper proposal. o Second, to encourage people to express their views on the Clipper proposal, particularly through the computer network. Toward that goal, CPSR has already begun an electronic petition on the Internet computer network urging the President to withdraw the Clipper proposal. In less than one week, the CPSR campaign has drawn thousands of electronic mail messages expressing concern about Clipper. To sign on, email clipper.petition at cpsr.org with the message "I oppose clipper" in the body of the text. o Third, to pursue litigation to force the public disclosure of documents concerning the Clipper proposal and to test the legality of the Department of Commerce's decision to endorse the plan. o Fourth, to examine alternative approaches to Clipper. Mr. Rotenberg said "We want the public to understand the full implications of this plan. Today it is only a few experts and industry groups that understand the proposal. But the consequences of Clipper will touch everyone. It will affect medical payments, cable television service, and everything in between. CPSR is a membership-based public interest organization. For more information about CPSR, send email to cpsr at cpsr.org or call 415 322 3778. For more information about Clipper, check the CPSR Internet library CPSR.ORG. FTP/WAIS/Gopher and listserv access are available. From dwomack at runner.utsa.edu Mon Feb 7 21:36:33 1994 From: dwomack at runner.utsa.edu (David L Womack) Date: Mon, 7 Feb 94 21:36:33 PST Subject: keyservers Message-ID: <9402080535.AA19289@runner.utsa.edu> I just downloaded the demon.co.uk public keyring...but, since I don't have mosaic or WWW and can't use the ai.mit.edu server, how would I add my public key to such a keyring? Thanks for any thoughts. From karn at qualcomm.com Mon Feb 7 21:36:43 1994 From: karn at qualcomm.com (Phil Karn) Date: Mon, 7 Feb 94 21:36:43 PST Subject: New remailer up In-Reply-To: <9402041508.AA18037@jungle.meaddata.com> Message-ID: <199402080532.VAA24768@servo.qualcomm.com> >You can get spread spectrum radio/data modems that do 256Kbits/sec >(Cylink) and can go up to 30 Miles. It is unlicensed in the US >because it is limited to .8watts (I think). I believe 10 miles is the >limit with an omnidirectional antenna. Spread spectrum should be >pretty hard to triangulate on. Remember that the technology came from >unjammable military radios. >I think you'd have to have a fairly sophisticated scanner to even pick >it up. Not quite. Very few, if any, Part 15 spread spectrum modems do automatic transmitter power control, and as a result they generally run much more power than necessary. That makes you much easier to spot. It also pollutes the spectrum. Even spread spectrum transmitters with tight power control (e.g, our IS-95 cellular system) are easily detected (though not demodulated) with simple AM scanners when you're close enough. Especially when the mobile in question is a long way from the cell and transmitting near full power as a result. On the other hand, if you're not close, any particular mobile will be drowned out by the several dozen others sharing the same channel. Phil From oseiler at unixg.ubc.ca Mon Feb 7 21:50:42 1994 From: oseiler at unixg.ubc.ca (Oliver Seiler) Date: Mon, 7 Feb 94 21:50:42 PST Subject: Atlantis Project/Oceania In-Reply-To: <9402080217.AA23708@netmail.microsoft.com> Message-ID: On Mon, 7 Feb 1994, Blanc Weber wrote: > > Does it not seem that they are putting more effort into the publicity, > marketing, & attraction of money for support of this virtual country, > than into the establishment of other fundamentals? Like: setting up an They have a rather complete constitution, legal system, etc. Monetary systems would likely appear as needed. Most businesses would likely take all major currencies - good market for a bank to get into. Business relations with the rest of the world? This isn't in general specified in advance in any country, and why should it be? The only real rule I've seen is making it illegal (for good reason) to export drugs (eg. recreational drugs, synthesized for use on the island) to countries where they are illegal. Besides, since they moeny is far more important on this project than vague untested notions of how everything should work (hey isn't that how communist countries are set up?) in advance, they have been doing quite well. I wish them all the luck I can spare, and plan to pick up a t-shirt (if only for being able to tell people about it in 100 years or so...) or a flag... > alternative currency & banking system, the manner of conducting > business with the rest of the conventional world, and resolving the > many little problems that would be of concern when living under such > conditions? How much government intervention do you see in your day to day affairs? Personally, I see virtually nil... Free-market's tend to sort themselves out quite nicely... > Blanc -Oliver (who's not waiting for somebody else to build him a country, and is instead doing whatever it takes to get the same effect now) | Oliver Seiler + Erisian Development Group + Amiga Developer + | oseiler at unixg.ubc.ca +-------------Reality by the Slice--------------+ | oseiler at nyx.cs.du.edu | Phone: (604) 683-5364 Fax: (604) 683-6142 | | ollie at BIX.com | POB 3547, MPO, Vancouver, BC, CANADA V6B 3Y6 | From oseiler at unixg.ubc.ca Mon Feb 7 21:56:33 1994 From: oseiler at unixg.ubc.ca (Oliver Seiler) Date: Mon, 7 Feb 94 21:56:33 PST Subject: Atlantis Project/Oceania In-Reply-To: <9402080248.AA14992@vangogh.VIS.ColoState.EDU> Message-ID: On Mon, 7 Feb 1994, CVL staff member Nate Sammons wrote: > writes Matthew J Ghio: > > > >profitable venture, but getting a high bandwidth net connection in the > >middle of the ocean would increase startup costs. Telecom, electricity, > > Well, a satellite dish can transfer around 100MB (megaBytes, not bits) > per second. I'm not too sure how much this kind of link costs, but I > would also assume that the Oceania people aren't going to go without a > network conection to start. As soon as it's built, I would move in with a business offering just this sort of connectivity. If I can swing the capital at the time (probably not too hard) I'd also lay down swaths of fibre, set up a packet radio network, and connect the island up... > -nate -Oliver | Oliver Seiler + Erisian Development Group + Amiga Developer + | oseiler at unixg.ubc.ca +-------------Reality by the Slice--------------+ | oseiler at nyx.cs.du.edu | Phone: (604) 683-5364 Fax: (604) 683-6142 | | ollie at BIX.com | POB 3547, MPO, Vancouver, BC, CANADA V6B 3Y6 | From hfinney at shell.portal.com Mon Feb 7 22:36:33 1994 From: hfinney at shell.portal.com (Hal) Date: Mon, 7 Feb 94 22:36:33 PST Subject: WRONG: Attack on Magic Money and Chaum cash Message-ID: <199402080633.WAA27612@jobe.shell.portal.com> I was thinking over the attack I described on Magic Money and Chaum cash, and I now think it will not actually work, especially in the case of the Chaum cash. Specifically, it will take as much work to forge cash as to factor the modulus. My idea was to collect signed forms of small primes, then try to find a "smooth" number of the proper form, one which can be factored over this set of primes. By multiplying together the proper primes, one could generate a signed number which would look like cash. What I was remembering as I was driving tonight is that this is very similar to a family of algorithms for factoring large numbers. The one I know best is the continued fraction algorithm, but I think the number field sieve uses broadly similar principles. In the cfrac algorithm, the goal is to find two squares which are equal mod n. This lets you factor n immediatly by taking its gcd with the sum or difference of the two numbers. This is done by taking a bunch of squares and trying to factor them over a set of small primes. If you generate enough factorizations, approximately as many as there are primes, you can multiply selected ones together and generate two equal squares. The point is, finding as many smooth numbers as there are small primes will let you factor n. But that is the same criterion I had to meet in my proposed attack in order to make a profit. So it seems that in general my attack will not work; it will be as hard as factoring the modulus. There may still be a problem with Magic Money because its cash values leave the low order 128 bits free, but I'm not so sure about it. I was wrong, I think, to suggest that a simple sieve could quickly identify smooth numbers. Although a sieve will easily tell you that a number has _no_ factors less than some cutoff, it will not easily tell you that a number has _only_ factors in that range. It may be that the only way to identify smooth numbers is by trial division, which would be the same situation as for Chaum cash. So, unless there is in fact some trick that can be used to quickly find smooth numbers given that the low order 128 bits are free, I don't think there is any need to worry about my attack on Magic Money. And it looks like Chaum's online cash is completely invulnerable to this approach. Sorry to have raised a red flag unnecessarily. Hal From qwerty-remailer at netcom.com Mon Feb 7 22:41:33 1994 From: qwerty-remailer at netcom.com (qwerty-remailer at netcom.com) Date: Mon, 7 Feb 94 22:41:33 PST Subject: Nate's Remailer Shutdown. Message-ID: <199402080641.WAA24210@mail.netcom.com> -----BEGIN PGP SIGNED MESSAGE----- Anonymous said, "The reasons the Post Office gets more slack are that 1) They're the government, or at least used to be 2) They can randomly open mail when they feel like it, see 1)" So what's your point? Talk is cheap. The situation remains the same. The message in my post remains valid. The reason why it is so doesn't matter to someone desiring privacy. The internet still sucks and always will, due to the From and Received by e-mail headers as well as many other Unix system problems like sendmail logs, and the fact that you can't trust a wire 'cause you can't see it. -=Xenon=- -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLVbo8wSzG6zrQn1RAQEZqgP+LOHqzsOR+mbHjagehpv12qvihvJl9SSm f1Rz/iVtyKhPVpvsmwhIm3S/F6AmAikQwuO7Kt90BFpS8Q2tfV+iL4mRr1009xKi LovMs+oeydinlH6uOvKGvS4vtaju3dd7+SXQIa0sR46cN8r7O0BiVA6K+9AZ91Cx 6oONCh2Wpfo= =7yq9 -----END PGP SIGNATURE----- From remailer at merde.dis.org Mon Feb 7 22:50:42 1994 From: remailer at merde.dis.org (remailer bogus account) Date: Mon, 7 Feb 94 22:50:42 PST Subject: PGP Tools Debugging Message-ID: <9402080648.AA17257@merde.dis.org> -----BEGIN PGP SIGNED MESSAGE----- >> Pr0duct Cypher > Warlord >>I've got the code written to check the whole coin, and I found another >>subtle bug caused by precision setting. Since setting precision does not >>seem to affect the speed of the decryption (I think the mpi library sets >>it internally during modexp) I'm just going to fix it at maximum >>and leave it there. Tomorrow I will strip out all of these damn things. >Yea, MPI lets the precision. This is not a bug -- the MPI library >needs to know how big the number is. (The bug is that its done in a >global variable and not as a part of the number internally, but thats >a different matter). The reason it needs to know is so that it >doesn't need to perform large operations for small numebers. For >example, there is no reason to perform a 1024-bit modexp when you are >dealing with 384-bit numbers! The bug was in my code, not in mpilib, but the need to set precision can be a real pain. I've been plagued by intermittent bugs caused by mpis not being completely cleared or fully calculated out. Since modexp does it automatically, I'm just going to set it to max. If you or someone else with both types of machines wants to fix that, feel free. I don't have the means to do so, and it's been my experience that writing code you can't test is a waste of time. >FYI: I have both big-endian and little-endian machines at my disposal. >Also, I was having problems building PGP Tools under mips-ultrix -- >you have some global variables in ptd that you expect from time.h >which don't exist. In particular, timezone and daylight. PTD is a kludge. There are no similar dependencies in the library itself. PTD was just written as needed to test the rest of the library, and was not intended to be a usable application. You can either put in #ifdefs for your machine, or set up another module with the needed globals. I just wanted to code around the need for timezone stuff and get the test code working. I've got another version of PGP Tools ready which removes most of the set_precision stuff, and a version of Magic Money which checks the whole coin when it receives it. There are a few more changes for Magic Money, but I should be mailing out soon. Someone wrote that they had success with a big-endian machine - whew! and thanks for testing it. Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVcQUsGoFIWXVYodAQEiQQP/Tsm/AIi+zNJ5YIzPfaEjzeSyyi4pwLTp ZYzo88FyBBrayFpt+CkSdlatnOVu7EwyHcNBgh8Z3LJeffOcI8Wiw9WPO9v0vqHj yE35Yq9rFfBnTjQuZ3uNnb03l1G0XfyG2AyuYer3Y4shEKwO/6DgYr4b5K9Y2Wqc p8qpWGwUC6I= =itBc -----END PGP SIGNATURE----- From orion at crl.com Mon Feb 7 23:06:33 1994 From: orion at crl.com (Colin Orion Chandler) Date: Mon, 7 Feb 94 23:06:33 PST Subject: Clipper Qs Message-ID: Hurm...I have had a couple of thoughts, no dowbt simple ones, but maybe you can help: If I bought a a ClipperFone and switched chips with my neighbors chips (Clipper Chip, that is), could the .gov tell what was going on? Also, can these chips be re programmed? ;) I'd like a cracker... ___________________________________________________________________________ |---===================================--| /\ | | \ |_ _\ \ / | |---Colin Titus Orion Xavier Chandler----| \\ \ | | . | | > < | |---===================================--| \ \\ / \__/ _|\_|___|_/\_\ | | _____ | / \/ / / | |/\ __ \ __ "What year is it?" | / / \//\ "If it's not a | |\ \ \/\ \ _ __ /\_\ ___ ___ | \//\ / / Sun, it's not a | | \ \ \ \ \/\`'__\/\ \ / __`\ /' _ `\ | / / /\ / computer." | | \ \ \_\ \ \ \/ \ \ \/\ \L\ \/\ \/\ \ | / \\ \ .__ __ | | \ \_____\ \_\ \ \_\ \____/\ \_\ \_\ | \ \\ |_. | | |\ | -| | | \/_____/\/_/ \/_/\/___/ \/_/\/_/ | \/ __| I_| | \| __|/160| +________________________________________+_______________________________+ | Colin Chandler |"It can only be accountable to *human* error."-HAL9000| | (415) 388-8055 | orion at crl.com, wizard @ BayMOO (mud.crl.com 8888) | |________________________________________________________________________| From karn at qualcomm.com Mon Feb 7 23:10:43 1994 From: karn at qualcomm.com (Phil Karn) Date: Mon, 7 Feb 94 23:10:43 PST Subject: STEG: a real-life use for steganography In-Reply-To: <9402041840.AA21942@ah.com> Message-ID: <199402080707.XAA24919@servo.qualcomm.com> The biggest problem I see with your scheme is that it won't remain secret for very long, and the government will probably just ban all CD imports as a result. And possession of a CD player or CDs (even "legit" ones) would be enough to send you off to kamp. > -- A decryption system to get the data off the CD. There's a practical problem here. Audio CD players generally provide no easy way to get the raw bits into a computer (SPDIF interface cards exist for PCs, but they're rare and expensive). And I haven't yet figured out how to get a CD-ROM drive to read the raw bits off an audio CD; I suspect it requires munging the firmware in the drive, which makes anything you do highly manufacturer specific. Phil From qwerty at netcom.com Tue Feb 8 00:06:34 1994 From: qwerty at netcom.com (Xenon) Date: Tue, 8 Feb 94 00:06:34 PST Subject: What's a "real encryptor"? Message-ID: <199402080803.AAA16148@mail.netcom.com> -----BEGIN PGP SIGNED MESSAGE----- I (Nik) got a letter from a mathamatician asking me to clarify what I meant by a "real encryptor". Here is the answer I gave. It is for the newbies out there, not the serious cryptographer types who know this already. Warning: one of my Xenon character's last rants will be arriving shortly. Take it with a grain of salt; it's pretty nasty, and not meant for those who already understand its message. I'm trying to drum up some public demand for a "real encryptor", for one thing. Think of it as propoganda, for it appeals to emotion not logic, and it is not very fair. Steganography involves hiding a message in a file. I can use the Mac program Stego to place say a PGP message into a Mac PICT (just a picture) file as the least significant bit of each pixel. If it is a 24 bit per pixel color picture, then you can't even see a difference. If it is 8 bit color, then you CAN. It looks like digital noise. On off, on off. No matter. The problem IS, anyone with Stego can extract the file and immediately see that it is an encrypted PGP message. When PGP encrypts a file, after compressing it, it includes in the final output all sorts of extra things like a checksum at the end, and full information given out to anyone about the name of the key that it was encrypted with. It will proudly announce, for instance, "This message can only be read by Pr0duct Cypher. You do not have the secret key required to read it." I don't know the full details. The PGP documentation mentions some of them, for the binary format PGP output files. I could send you this if you want. What I mean by a "real encryptor" is something just like PGP, but minus the convenience features that get tagged onto the PGP messages. It might be as simple as stripping them away the PGP convenience procedures. If the output was simply an encrypted message, and it seems to me PGP could do this, it should be hard to distinguish it from a random series of bits. Hopefully nearly impossible! Then you can use steganography for your messages but no one can tell if what they extracted is a message or not! The least significant bit of most messages such as sound files is noise anyway. On off, on off. They can't even tell how big it might be. That is a potential mega problem with PGP itself not being able to know how big it is though. You would have to know before hand, or make the picture or sound file BE the right size, EXACTLY. That's certainly easy for sound files! Just send voice mail! You could pad the content of the PGP message if you wanted to hide the actual size of the decrypted message. If you get voice mail from a stranger saying something vaque, you can check if it contains a PGP message encypted with your public key. If PGP outputted such a hard-to-distinguish-from-random data format, it opens up many different possibilities for sending your messages. Ideally, no one would be able to tell if it was an encrypted message except by successfully decrypting it. As it is now, such schemes have to rely on "encrypting" an already encrypted PGP message to hide the fact that it IS a PGP message! Many of us just want to be left alone and are tired of having our files tagged as BEING encrypted. Personally, I suggest using PGP as a Clipboard utility so I can cut a message out, encrypt it, paste it back in and save it as a word processor file which I then Macintosh BinHex encode as text, and e-mail off. Now I'm just sending a BinHexed word processor file, just like thousands of other Macintosh e-mailers out there every day! This isn't good enough since it is so easy reverse, by anyof them ;-), and they are still struggling with just e-mail. PGP is still a program only used by those why really need it. It may remain that way, so for those people, having a random data block output would mean they wont set off alarms and catch the attention of the government, just for sending a love letter to their mistress ;-). -Nik (-=Xenon=-) -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLVb/QgSzG6zrQn1RAQHPRgQAttdvv7y01xE0+8xKOnoODYJ3Xmlw0Wrs hIlMIGglirxY8Q244EEfjA538QES19jS95+8G5q9p5eEjM6w0apkRKQbyQOxme8j tfBU+yhhtqTGPUidLdiOWNszn2DvD0hrTVFH15b3yFoB2F1mA1kkjbfmXAm1r7gS MmJaO0c6ZNE= =SIQx -----END PGP SIGNATURE----- P.S. Were PGP like many programs, able to accept modular "Plug ins" like say Adobe Photoshop, this "bare" data block output could be an add-on featue ("feature stripper?") that those who want it would use. Or at least a separate utility that would strip and restore PGP messages. From hughes at ah.com Tue Feb 8 00:06:46 1994 From: hughes at ah.com (Eric Hughes) Date: Tue, 8 Feb 94 00:06:46 PST Subject: Magic Money coins In-Reply-To: <199402080633.WAA27612@jobe.shell.portal.com> Message-ID: <9402080759.AA00803@ah.com> >I was thinking over the attack I described on Magic Money and Chaum >cash, and I now think it will not actually work, especially in the case >of the Chaum cash. Well, with Chaum's signature pairs of the form , you'd still have to calculate some inverse value of a one-way function. On he other hand, Hal says that his attack against MM coins doesn't work. That's OK, as far as it goes. The problem is really quite general. Given a set of signatures on the same modulus, how can one calculate signed values of a particular sort? In the proceeding, let { < a_i, a_i^(1/e) > } be the set of signatures one has, e the public key, n = pq the modulus, S the set of acceptable signed elements. Note that the product of any two signatures, pairwise, yields another valid signature. A signature can be multiplied by itself as well. These are valid as RSA signatures but possibly not as any special coin format. Note that the Chaum signature pair above prevents multiplicative combinations entirely. The problem is then "Can we find an element of S in the multiplicative span of the { a_i } modulo n?" (The multiplicative span is any product of the a_i, possibly taken multiple times.) Hal's attack was about the about problem, _but without the modulo n_. There's a subtlety to remember here: factoring doesn't mean anything in a field. The RSA ring is almost-a-field; if you can find a non-invertible element, you've factored the modulus. Factoring only make good sense in rings where lots of elements are _not_ invertible. So Hal's factoring attack only considered direct multiplication, forgetting that that modular equality was what was relevant. The upshot is this. Let s be in S. What we are looking for is a factorable (in integers) number of the form s+kn. Now s can be any element in S, and k any integer. That's a wide range to choose from. A. First off, what is the size of the possible multiplicative span? The short answer is "It's likely the whole thing". Recall that in an RSA cryptofield (my term for a ring where it's infeasible for an outsider to find a zero-divisor) the invertible elements form a multiplicative group which comprise all the 'normal' operations in the cryptofield. Its structure is the product of two groups, one of order p-1 and one of order q-1. Now the number of generators of the Z_p is \phi(p-1). (That's the Euler \phi function.) The average value of \phi(x) is x * (6 / \pi^2), i.e. on average 61% of the numbers. [N.B. This is for random x. p and q can be picked to change these values.] Eliding the rest of the calculation, we see that with a few signatures, it's very likely that _every_ cryptofield number is in the multiplicative span. B. The next question is "How tractable is finding particular combinations?" I don't know, but I wouldn't trust on the lack of an efficient algorithm. Remember, we can pick and set of numbers to get signed to span with, any coin format to try to create [RANT: forge indicates intent] with that span, and we're working in a modular cryptofield. That's lots of possibilities. Here is one idea for such attack. The numbers in S all have the same upper bits. Suppose one could calculate a number u which was 'close to' 1 in a range containing S. To be specific, suppose that P( | s - u*s | < sqrt(s) ) > .1 that is, multiplication by u likely doesn't move the value around by more than the square root of s. Then one can randomly pick coin values, multiply by u, and likely get new coin values, since all the upper bits are the same. Are such u rare? Maybe not. Consider the number 3 and values near n/2. Observe that 3 * ((n-1)/2) = ((n-1)/2) - 1 (mod n) 3 * ((n+1)/2) = ((n+1)/2) + 1 (mod n) So for the numbers close to half the modulus, 3 is exactly such an almost-identity. But can we find one for our given range? I think so. Here's my first guess at how to proceed. And it really is a guess, even if it is inspired by a Gauss sum. Consider the following. Take the range S and choose random { x_i } in S with, say, some truncated Gaussian distribution in order to favor number in the center. Now calculate the term 1 x_1 x_3 x_(2n-1) - * ( --- + --- + ... + -------- ) n x_2 x_4 x_2n In other words, just calculate an average of a bunch of values that move one element of S to some other element of S. Such an element *might* tend to preserve values of S near the center, maybe not. It may be that diddling the distribution helps. It may be that a different average works, say a geometric average (although taking roots becomes an issue). It may be that this technique works but doesn't converge rapidly. I don't know; I haven't tried it. In any case, if it does work, there are lots of candidate u's that one can sample. It also appears that one might be able to directly calculate some of these near-identities with continued fractions. C. Recommendations In any case, the issue of creating new signatures out of old is sufficiently unsettled in my mind that I would avoid the issue entirely. 1. Don't rely only on format of the signed number for validity. 2. Do use a one-way function in the signature in order to prevent multiplicative attacks. 3. Use both techniques above. Therefore I recommend the Magic Money signature format be changed. Eric From qwerty at netcom.com Tue Feb 8 00:16:34 1994 From: qwerty at netcom.com (Xenon) Date: Tue, 8 Feb 94 00:16:34 PST Subject: What's a "real encryptor"? Message-ID: <199402080814.AAA17429@mail.netcom.com> Typo correction from first post: If PGP outputted such a hard-to-distinguish-from-random data format, it opens up many different possibilities for sending your messages. Ideally, no one would be able to tell if it was an encrypted message except by successfully decrypting it. As it is now, such schemes have to rely on "encrypting" an already encrypted PGP message to hide the fact that it IS a PGP message! Many of us just want to be left alone and are tired of having our files tagged as BEING encrypted. Personally, I suggest using PGP as a Clipboard utility so I can cut a message out, encrypt it, paste it back in and save it as a word processor file which I then Macintosh BinHex encode as text, and e-mail off. Now I'm just sending a BinHexed word processor file, just like thousands of other Macintosh e-mailers out there every day! This isn't good enough since it is so easy to reverse, AND can be automated. Honestly, I'm not doing this much yet with distant friends, but then there are only two of them ;-), and they are still struggling with just e-mail. PGP is still a program only used by those why really need it. It may remain that way, so for those people, having a random data block output would mean they wont set off alarms and catch the attention of the government, just for sending a love letter to their mistress ;-). It would also render the Clipper issue moot. -=Xenon, who never could type, and breaks things a lot still=- From wcs at anchor.ho.att.com Tue Feb 8 01:10:45 1994 From: wcs at anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) Date: Tue, 8 Feb 94 01:10:45 PST Subject: Clipper Qs Message-ID: <9402080909.AA04864@anchor.ho.att.com> Doesn't matter if you switch CLipper Chips - the chip squawks its serial number when it starts a session, and they simply get the keys for *all* clipperphones that they overhear while wiretapping. That way they don't need to keep track of who's got what chip (which is impossible, since you could switch with your neighbor), though that may be some help if they happen to know some eavesdropping victim's serial number and are tapping all the pay phones in an area. As far as reprogramming goes, no. They're a fancy tamperproof design, which they hope will make it difficult or impossible for people to get the algorithm or the key out of. From nobody at shell.portal.com Tue Feb 8 02:26:36 1994 From: nobody at shell.portal.com (nobody at shell.portal.com) Date: Tue, 8 Feb 94 02:26:36 PST Subject: Magic Money -> Chaum Cash Message-ID: <199402081025.CAA20709@jobe.shell.portal.com> -----BEGIN PGP SIGNED MESSAGE----- Ok, let's try this one more time... Based on Eric's long and mathematical explanation, which I did not fully understand and was therefore convinced by, I have changed the program to use full Chaum cash. It takes the 16-byte random number, takes its MD5, and stores the MD5 in the coin. The coin is now a triple (id,e,mpi) and the bank never sees id when blind-signing the coin, thus preserving anonymity. I sent this new version to csn.org as mgmny10c.zip. I haven't had a chance to update the manual or the comments in the code, but it does seem to work. At least, I was able to mint coins and cycle them through the server a few times, so the basic coin cycle seems to work. Please check it out, on machines of both endians, and let me know what happens. Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVdfXcGoFIWXVYodAQExBQQAlAOtfHApmQlmj1bk2kdBEg+Rst0I4CcB vIoxQ/iXiAS5c9fGdl5WNWpBk5TYCQSHm3jyzAoYaeLwJ4XsgnH5WbvB+UeRzwJX VatnTUK7x7wZMtIBAAaaPGX2woosns83bnXMa5voKkiYeESFFLgU5Dw5zw24xFas 1fkwlBSnyRA= =L9Ei -----END PGP SIGNATURE----- From pmetzger at lehman.com Tue Feb 8 06:30:47 1994 From: pmetzger at lehman.com (Perry E. Metzger) Date: Tue, 8 Feb 94 06:30:47 PST Subject: Atlantis Project/Oceania In-Reply-To: <9402080248.AA14992@vangogh.VIS.ColoState.EDU> Message-ID: <199402081429.JAA09219@snark> CVL staff member Nate Sammons says: > writes Matthew J Ghio: > > > >profitable venture, but getting a high bandwidth net connection in the > >middle of the ocean would increase startup costs. Telecom, electricity, > > Well, a satellite dish can transfer around 100MB (megaBytes, not bits) > per second. I'm not too sure how much this kind of link costs, but I > would also assume that the Oceania people aren't going to go without a > network conection to start. Perhaps the appropriate time to worry about Oceania's network connection would be when Oceania's builders have the $ 1 Billion they need instead of begging for $20 or $30k for models. In any case, this is NOT appropriate stuff for cypherpunks. Perry From paul at poboy.b17c.ingr.com Tue Feb 8 07:10:51 1994 From: paul at poboy.b17c.ingr.com (Paul Robichaux) Date: Tue, 8 Feb 94 07:10:51 PST Subject: STEG: a real-life use for steganography In-Reply-To: <199402080707.XAA24919@servo.qualcomm.com> Message-ID: <199402081509.AA17293@poboy.b17c.ingr.com> -----BEGIN PGP SIGNED MESSAGE----- > There's a practical problem here. Audio CD players generally provide > no easy way to get the raw bits into a computer (SPDIF interface cards > exist for PCs, but they're rare and expensive). And I haven't yet > figured out how to get a CD-ROM drive to read the raw bits off an > audio CD; I suspect it requires munging the firmware in the drive, > which makes anything you do highly manufacturer specific. Apple's CD-300/300i drives can read audio bits directly and turn them into a QuickTime sound channel, as can SGI's SCSI CD. Apple uses a Sony mechanism, and SGI uses a Toshiba. The SGI drives use modified firmware and (AFAIK) are not available elsewhere, but you can get the Apple drives at Circuit City, Sears, etc. With the right sequence of SCSI commands you could easily capture an "audio" bitstream, then munge it as desired to extract the stegged data, play it backwards, or whatever. IIR, code to directly read arbitrary audio data on an Apple CD-ROM was recently posted in comp.sys.mac.programmer, but I didn't save it. - -Paul - -- Paul Robichaux, KD4JZG | "Though we live in trying times perobich at ingr.com | We're the ones who have to try." - Neil Peart Intergraph Federal Systems | Be a cryptography user- ask me how. Of course I don't speak for Intergraph. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVen7SA78To+806NAQG3sAQAu8prXRUkJKWwmQBIeJxwQIDK+2ilvyxe 24rcK89EInIyEdLnsSrx4uly3CBpS7iWdOmoAQ9tNu5tOOi3xc+5W5cvUTJ4t/NR gblnKM/qevO6PCdQFiJXNgzg/1DkY2LsrvnH3I+8lxXeNn06CQKB85r5COY2vL3I ldqrGjLScHU= =GjEo -----END PGP SIGNATURE----- From norm at netcom.com Tue Feb 8 08:06:46 1994 From: norm at netcom.com (Norman Hardy) Date: Tue, 8 Feb 94 08:06:46 PST Subject: Magic Money ftp Message-ID: <199402081606.IAA16443@mail.netcom.com> Is there somewhere that I can ftp the Magic Money protocol from? From cfrye at ciis.mitre.org Tue Feb 8 09:11:45 1994 From: cfrye at ciis.mitre.org (Curtis D. Frye) Date: Tue, 8 Feb 94 09:11:45 PST Subject: Clipper Opposition Message-ID: <9402081718.AA04480@ciis.mitre.org> Fellow C'punks- This is a copy of a posting I made to comp.eff.org.talk and other groups. >-------< In article Robert I. Eachus, eachus at spectre.mitre.org writes: >In article strnlght at netcom.com (David >Sternlight) writes: > > > Once they made it voluntary and promised not to outlaw non-Clipper > > crypto, the game was over. Arguments about its becoming de facto > > standard and driving out other crypto are simply too complex and > > iffy to convince the average reader. > > David, this is where you and I part ways. You believe that the >adminstration is promising not to outlaw non-Clipper crypto. But the >reality is that the adminstration IS and has been trying its damnedest >to harrass, intimidate, and suppress any alternative strong crypto. >The current situation--and the recent announcements confirm this--is >the adminstration requires a special license to export crypto, which >you CAN'T get to publish strong crypto (And in some cases to publish >junk crypto. If I can't publish a public key and the algorithm to use >it, what good is it? David does raise a valid point that I don't think Robert deals with - how does fighting Clipper help us in the struggle to prevent the outlawing of all non-Clipper crypto? If the CPSR and other organizations spend their political capital on a losing fight, does the credibility loss kill effective future resistance? While the Clipper proposal *as it stands now* is most likely a done deal, there are ways to keep up the pressure to make sure it doesn't snowball: o Mount effective resistance against the Wiretap proposal and *link the two issues* in the eyes of the public. This shouldn't be done completely up front - instead, the association should begin to build after a few weeks or months to ensure that the original message is received and is not blocked out by the "you already lost Clipper" signal; o Quote export sale figures of Clipper technology often and loud - I don't see how any foreign company would let such suspect equipment on their property, let alone use it to transmit anything sensitive. I truly hope I'm not wrong on this count - if the tech sells, the case against Clipper becomes darn near unwinnable; o Track Clipper equipment purchases by US entities that do not have government contracts; o Maintain close vigilance over the law enforcement community. How many mid-level drug dealers would be willing to use Clipper technology to implicate their bosses in exchange for lighter sentences? Expect this tactic and similar ones to be used; o Compile a list and analysis of all crypto software and equipment available overseas and compare it to commonly used US techniques. If the exported stuff has identical or near-identical functionality to the US tech, there's no case for Clipper. Combine this analysis with the export figures and industry is bound to take notice, with their Congressional reps following. There should be a follow-up analysis on foreign purchases before and after Clipper is introduced. THE FIRST PART OF THIS DOCUMENT SHOULD BE PREPARED IMMEDIATELY!!! If someone hasn't already begun this survey, I'll volunteer and will put out a call for information shortly. This battle needs to be fought on our ground - the Administration is defining how the argument is being carried out, for now. Do we know what our ground is? What strategy we'll take to counter the Administration's initiative? The list I just gave is a series of tactical devices that could produce specific effects, all of which are USELESS without a coherent strategy to apply the information gained. Do I have any suggestions? Nope, not beyond the tactics I discussed above. I am, however, going to start some serious cogitating and hope to come up with something. That last bit shouldn't be seen as a slam on the EFF or CPSR as I don't know what level of planning they've invested in strategy. What I do know is that we've lost the initiative and need to regain it; these newsgroups are a great place to start, but most of us agree on the basic principles that information should be free etc. etc. etc. Why should Middle America care what happens to terrorists and dope pushers? How long until "electornic privacy advocates" join that elite group? It isn't time to push the PANIC BUTTON yet, but there needs to be a heightened sense of urgency in everything we do to fight against the possibility that the Administration wants to ban all non-Clipper crypto. That possibility scares the hell out of me and is enough to make me act RIGHT NOW! Curtis Frye PRIVATE! Citizen I don't speak for MITRE, they don't speak for me. >-------< -- Best regards, Curtis D. Frye - Economic Analyst, Software Alchemist, Aspiring Author cfrye at ciis.mitre.org "If you think I speak for MITRE, I'll tell you how much they pay me and make you feel foolish." From qwerty at netcom.com Tue Feb 8 09:30:49 1994 From: qwerty at netcom.com (Xenon) Date: Tue, 8 Feb 94 09:30:49 PST Subject: X's Last R. Message-ID: <199402081729.JAA05241@mail.netcom.com> -----BEGIN PGP SIGNED MESSAGE----- Disclaimer: The usual. Take this with a grain of salt. As propaganda, at least its purpose is noble. In this, the final episode in the rant series, the character Xenon is angry at the evil media-grubbing Cypherpunks for not noticing, or worse ignoring, that PGP is indeed only "Pretty Good" when it is considered in its present form. I hope I haven't lost full respect due to these essays. I did? Oh well ;-). P.S. The new finger key server is very happy. Thank-you. P.S.S Is it easy to modify PGP to remove its "convenience features"? How about a utility that will strip away the "bare" encrypted message and later restore it to life. The hell with checksums and the rest. I want my VGP! I asked this on alt.security.pgp and the silence was amazing. Just a bunch of flames, and one person who introduced me to steganography. -Nik (-=Xenon=-) AnD br0ught t0 y0u by -=XeNoN=-, an0ther DaMNiNg CrItICism of the Cypherpunk fad, er... m0vement. "It'S NEW nEw NeW BuT We'Ll JuSt HiT ThAT 'd' KeY kEy kEY and iT's ByE bYe DoN't MaKe mE THiNk! THeN, LikE AlWayS, We CAn iGn0re 0uR gReAT SelF DeCePti0n tHaT wE HaVE a ReaL EncRYpToR. ThIS GuY iSn'T In 0uR Cli-PuBliC- QuEy liTtlE E-cLuB anYWaY. He'S GoT n0 TitS. hE d0n'T CodE. We JUst WanT t0 TaLK AboUt PoLIticS, NoT bUidIng NeW T0oLs. PhiL DId ThAT ALrEaDy. HE mAdE uS Co0l. wE LiKE t0 TalK AboUt US, sInCe In US liVEs PhiL. PhiL pHil PHil. PgPGpGPgpGpGpGPgPgP. Lo0k wh0 SigNed My KeY! I'M oN mTv!" "But when are you going to write VGP?", asks the quite voice of humanity, the ones who weren't invited to your e-party. If VGP had a "random data block" output format, THEN it doesn't matter if the Clipper Keys are known. "I'm sending a porno jpeg; my scanner isn't that great, so it's noisy." Playboy can tag you for copyrights, but if the fact that "noise" is really an encrypted message is ONLY known by successfully decrypting it, then even random information highway spot- checks would be useless. Are they going to outlaw noise? That's like trying to legislate a change in the speed of light. I wish they WOULD outlaw noise; it would make my stereo sound better. Phil Zimmerman didn't put a backdoor in PGP. No, he put a front door. He fucked up, but like the Founding Fathers who fucked up the Bill of Rights and the Constitution due to their concern about keeping their Mercedes from the hands of the poor, he's only human. "Encryption Always Wins." So write us a real encryptor. Write VGP. Hurry up or I'm going to hire someone to do it for me, then you wont be the next Phil Zimmerman, I will. Good programmers aren't cheap, but luckily I don't have to hire a cryptographer, since the equations are already in text books. And if you think your a hacker, Cypherpunk, try hacking together a complicated molecule sometime. The laws of nature constitute a mathematical computer, and it's so much more rewarding to hack, cause God never updates His CPU, and the programming language is beautiful and mysterious. Try coding in DNA or in the language of chemical synthesis if you want to earn the name "hacker". The interesting people out there are using Macs and Windows for their personal e-mail. 100 million people who don't have the time to learn command-line PGP, because their too busy running the world and getting things done. Write them a fun encryptor and you will find you have a lot more people who are worth talking to. Since MacPGP2.3 was obviously never beta tested, it's just not up to snuff. With my guide, it is at least usable without the frustrating 3 month learning curve needed for each new user to make own bug work-arounds. At least Detweiler had the insight to put a useful help feature into MacPGP to make up for the cryptic documentation, and thus got his name on the startup screen. I also think that the cryptographers, like the atomic scientists of only a FEW years ago, should be just as concerned about the impact of their science. The NSA is our friend damn it, no matter how irresponsible that friend may at times be. The NSA has been through REAL wars, not internet pranks. They are OUR National Security Agency. This isn't patriotism; it's common sense. Tell them we want backdoors to be used for NATIONAL SECURITY concerns, not to wiretap Greenpeace, and that we want SERIOUS assurances about this. Let's get the NSA to realize they need to work WITH privacy activists, not try to ignore or work against them. "Encryption Always Wins." This isn't about political power and supercomputer resources. Us versus them. It's about the laws of nature and science leading to technology being available to the common man. But the government isn't concerned yet because we haven't yet coded a real encryptor. All we have is PGP. They can't read content, but they can, like anyone else, see that it IS encrypted and most often find out who sent it to whom. Clipper also allows anyone to start recording your Clipper calls NOW, even if they don't have the keys yet. A random block output would mean anyone could record your calls and never prove it was anything other than a noisy microphone or a jpeg of Madonna. Detweiler became an idiotic child with his "death threats" and "anarchy" concerns limited to internet (World Wide Wiretap) remailers, added to the fact that HE seems to be the only one abusing the remailers. He is just noise (no pun), if this be a discussion of cryptography/anonymity. It doesn't matter shit if a Detweiler or a Depew takes away our internet toys. His biggest mistake was to take you guys seriously. Stop talking about the internet and get serious. Think POSTAL SERVICE encrypted remailing services, where the pass phrase stays in someone's head, and there is no e- mail headers telling where that floppy hidden between two halves of a postcard came from. Think encryption with random data block output. (Think software to allow me to read that floppy after the rotational indexing is lost when I separate the metal hub and later put one back on). The "collapse of governments" claim might get a few rebellious school girls in cheap leather to follow you home, but it's not worrying the NSA or the tax man. "You want to drive on this highway? Pay up or go back home." "You want that CAT scan? We accept cash." "You need unemployment support? Well, you never paid your insurance tax." Encryption isn't going to end taxes. It will just change the way they are collected. It will tie a service to your payment of a tax. "You want us to shoot down that missile headed your way? Sorry, your community didn't pay for military protection and we don't have any strategic targets there." "You want to live in this community? Sorry you have to pay this tax for military protection or you aren't welcome here." "You want to sell secrets to IRAQ? We've bugged your left ear, the one you use for the phone. Sorry about the ear ache we had to cause to get you into the local hospital." I think the time is coming when we are going to discover what our species is really all about, since encryption will set us free to be ourselves, as individuals. I think we will be pleasantly surprised. I just hope we don't hurt each other trying to resist change. As Bucky Fuller said, "Utopia or Oblivion." He also warned that we "NOW" (1969) have the technology to provide everyone on this planet with adequate food and shelter, but that if we don't give it to them, they are going to walk up that crunchy imported gravel driveway, past your BMW, and kill you. Was Phil Zimmerman a "Cypherpunk who wrote PGP"? Or are you guys just strip mining the CRYPTOGRAPHY movement and selling it back to us at twice the price? "Anarchy for sale." - Dead Kennedys. Cypherpunks. Cypherpunks. Fuck off! Send me a computer virus and I'll send you a REAL virus ;-). Stop talking about the obsolete internet. It's just a primitive non-multimedia medium for discussion about real life, real privacy, and real people's needs. The information highway isn't likely to involve Unix or RFC standards. "Can I send you a gigabyte of my latest movie? Or you can ftp it from my laptop. You do have 2 gigs of RAM don't you?" Don't follow internet-like standards when coding an encryptor ["PGP versions 2.3 and later use a new format for encoding the message digest into the MPI in the signature packet, a format which is compatible with RFC1425 (formerly RFC1115)." - Phil Zimmerman]. Do something timeless and historically significant. Write a real encryptor. Then it doesn't matter if everyone isn't using it, 'cause you're just sending "noise", like everyone else. Who cares about Clipper? Don't argue politics. Write code. Easy to use code. Plug and play user interfaces for the Mac and Windows. Or who else you gonna talk to? E-lovers? E-people? I'm not a "Cypherpunk", I'm a scientist. An introvert who values his privacy. I don't need PGP, except for fun, to sign things, and to reduce the most blatant internet privacy violations. For now it's the internet standard, but Clipper is good enough for me, personally. It will keep those around me who I do not wish to share my personal life with from reading my e-mail and files on my floppies. I don't mind the NSA reading my e-mail. But I do worry for others, who are trying to change the world in more political ways, and fear that the NSA will not be the only ones with access to the keys. PGP activism is just my latest hobby. I just want more people to talk to, using PGP. I don't want my picture in Wired. You're not PUNKS. Your just entertainment, until you get off the internet and WRITE A REAL ENCRYPTOR. The bad guys love PGP. They don't want it to loose its underground appeal, lest it become less popular and they can no longer identify encrypted messages. See the big picture and do something useful, or your just a bunch of e-yuppies worshipping money and attention as the center of meaning in your life. Fun toys and babes. Die e-yuppie scum. UNSUBSCRIBE. -=Xenon=- P.S. Thanks for not putting my "Here's How to MacPGP!" guide on any of your ftp sites. It would have lost its edge, mixed in with all the e-bullshit already there about "anarchy" on the internet (WWW). And I might not have had to send it to people by e-mail, people who don't know what ftp MEANS, because they don't have the time to figure out stupid command-line operating systems, the historical equivalent of programming via hard-wiring or punch cards. -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLVeCJwSzG6zrQn1RAQFnYwP/WAqeptD+rDCU9Cfyf91IJ6FPmkWJT/mF 5gGhhQmjuugn1VNTzifgh2R6aDtCMA8QkGYbsmSSsphHNhNQbPRhE7/dBj6xMq7F RjTcfH3Ff1bNXE6y16AVnGGOdAuEEWwCSordu27sR9CJSKSnm2tTOMsxYxEOGsfZ wX3E2atuek0= =bYZ6 -----END PGP SIGNATURE----- From m1tca00 at FRB.GOV Tue Feb 8 09:46:47 1994 From: m1tca00 at FRB.GOV (Tom Allard) Date: Tue, 8 Feb 94 09:46:47 PST Subject: A serious question of ethics In-Reply-To: <9402071839.AA15102@pmantis.berkeley.edu> Message-ID: <9402081742.AA26012@mass6.FRB.GOV> - -------- nobody at pmantis.berkeley.edu wrote: > Does that mean that I no longer should report the open system (I don't > dare telnet there to find out if it is the same one)? > Also, and I'm purely curious, what actually became of my anonymous > report, and do I need to be worried about SS agents in dark sunglasses > coming to my home and dragging me away? (Truely worried and scared) I work on the Federal Reserve *Board*'s Research Network. This network is hidden behind a firewall, and won't even let you finger (much less telnet) into. I sent your message to the network administrator, Janice Shack-Marquez (m1jsm00 at frb.gov). Obtw, Libby Flanagan has fled to the private sector (lf at nwu.edu) where vendors can now give her coffee cups with filling out forms. Janice (quickly) got at least three people looking into the problem. Bob Drzyzgula (m1rcd00 at frb.gov) found a machine that perfectly matched the problems you described. Bob contacted them, and they seem to have corrected the problem. Don't worry about black hats, though. If anything gets investigated, it outta be the district bank. I *would* like to know the IP address you had connected to to verify that we're talking about the same machine. You can use the remailers, and encrypt to my public key (available on the servers, key ID C744CD). All the "cool" secrets (wire transfers and the like) don't get anywhere NEAR the internet. The Federal Reserve System has a separate (yes, encrypted) network for sharing data. The Federal Reserve Banks are all "private" companies, and several offer various other services (such as economic bulletin boards and the like). The Federal Reserve *Board* has Research network (where I am) used to prepare statistical releases and act as a data service for the Chairman & Governors. The Board does not offer any services to the internet (we should, but that's a long story). The point of all this is that you didn't really find anything very sensitive, although we do appreciate closing gaping holes like that. rgds-- TA (tallard at frb.gov) [awaiting approval of new disclaimer] pgp fingerprint: 10 49 F5 24 F1 D9 A7 D6 DE 14 25 C8 C0 E2 57 9D -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVekwaAudFplx0TNAQHOdAP/WqSUic8PwvEuCkdOBSPZVlxJFwTlYXr8 0lLhnJDgs8+tUPp0Vd9Atc7nsvQM3mZ56xOIWED21KBcBRpaNlUG4E6bT9QrKKDi dwfR/sHHysdpHx9yB2xlpunlkeBw2jMDEm5YbusgZNHbVpt7AaixcqKVyRrL2wJM aNaFwEBJFOM= =gME3 -----END PGP SIGNATURE----- From beep at how.com Tue Feb 8 09:56:46 1994 From: beep at how.com (beep at how.com) Date: Tue, 8 Feb 94 09:56:46 P