- cypherpunks-legacy@lists.ogf.org

PKP/RSA comments on PGP legality
by Bruce F. Webster 21 Dec '92

21 Dec '92

(Cross-posted with permission of Eben Moglen): Newsgroups: sci.crypt,alt.security.pgp From: em21(a)cunixf.cc.columbia.edu (Eben Moglen) Subject: Re: PKP/RSA comments on PGP legality Message-ID: <1992Dec17.150409.17696(a)news.columbia.edu> Date: Thu, 17 Dec 1992 15:04:09 GMT I have been following with interest, and distress, the conversation about legal risks in using PGP set off by Carl Ellison's posting of a document said to reflect the legal position of PKP. Perhaps a Columbia Law professor's views on these questions may be helpful. I'm going to discuss the realities of the situation, without jargon, rather than the legal technicalities. Those who want to discuss the legal detail should feel free to contact me, but for legal advice I usually get paid. PKP says that any user of PGP is "inducing" infringement. Here's the reality of the situation. PKP is the licensee of a presumptively valid US patent, which it claims PGP 2.1 infringes. If the patent is valid, and PGP infringes, every user is not just inducing infringement--he/she/it is infringing the patent. This is not a crime; it's a civil wrong, for which, as the PKP statement says, damages are available at law. But this is true every time a manufacturer sells or distributes an infringing article. As you may recall, for example, an inventor recently won an enormous damages judgment against a major US auto company for infringing his patent for intermittent windshield wipers. Theoretically, under the patent law, he could instead have notified all Ford buyers in the past decade that they were personally infringing his patent. But it is grossly impracticable to do that, and a suit against the manufacturer accomplishes exactly the same result, since the total amount of the damages available is the same either way, while the litigation cost is not. PKP can test the validity of its patent and recover its damages, if any, in a suit against the developers and distributors of PGP, if it cares to. Without any knowledge of their thinking, I predict the partners won't want to do that. It would be expensive, the damages to be recovered would be slight or none, and they would risk having the only patent anywhere in the world protecting their technology declared invalid. But in any event, it is virtually unheard-of to sue individual end-use consumers of allegedly infringing technology. If PKP's investors had $100 million or so they wanted to waste in litigation anything could happen, but they don't, and it won't. In any event, in such a situation a lawyer certainly might advise her client to wait for the patent-holder to assert his rights directly. When PKP sends you a personal letter claiming that you are infringing its patent, and asking you to take out a license, you can decide what you want to do about it. In the meanwhile, the patent claim against end users is mostly, probably entirely, just noise. The Munitions Act bluster contained in the post is not even that important. It's just ridiculous. Others have said some of the most important things well, so I'll be brief. First, even if PKP believes its own arguments interpreting the ITARs, PKP doesn't have squat to do with ITAR enforcement. This is a question addressed to the discretion of the Treasury, the Department of Justice, and local United States Attorneys. ITAR enforcement against distributors of PGP would require a decision by all those agencies that the highest-priority Munitions Act enforcement problem at some future moment is the prohibition of IMPORTATION of a CONSUMER SOFTWARE PRODUCT embodying TECHNICAL INFORMATION IN THE PUBLIC DOMAIN. I challenge PKP, or anyone else, to show any past example of such an approach to ITAR enforcement by any Administration. I cannot myself imagine any United States Attorney's office wanting to bring such a case, which is of nightmarish complexity, would be politically unpopular, and does nothing whatever to stem the global arms trade or increase the national security of the US. I very much doubt that PKP really believes that the domestic circulation of PGP violates the ITARs, since PKP itself terms as "unfortunate" the application of the Munitions Act to cryptographic technology. But even if that's really what PKP or its officers think, so what? The chances that the United States Government will ever agree, and put weight behind agreement, are within fuzz of zero. UseNet serves many social purposes. One, apparently, is the no-cost distribution of negative advertising and legal chest-pounding, intended to frighten people away from experimentation with a piece of interesting freeware. Myself, I would just put the PKP temper tantrum in the bitbucket. But since other people have taken it seriously (much more seriously than it deserves) I thought a few more sober comments might be warranted. _____________________________________________________________________ Fiat Justitia, "Quoi que vous fassiez, ecrasez l'infame, ruat Coelum. et aimez qui vous aime." Eben Moglen voice: 212-854-8382 Professor of Law & Legal History fax: 212-854-7946 Columbia Law School, 435 West 116th Street, NYC 10027 moglen(a)lawmail.columbia.edu --

1 0

Re: Remailer Policies
by hkhenson＠cup.portal.com 21 Dec '92

21 Dec '92

Re logs and trying to destroy them when the cops are beating down your door, wouldn't it be a lot better to keep them encrypted? Keith

1 0

Re: Destroying Data
by jim＠tadpole.com 21 Dec '92

21 Dec '92

> Consider also the technique used in the Norton Utilities > program "Diskwipe" which takes a /g switch which "Follows > certain government rules for wiping". I can't find the manual > but I think it specifies how many repetitions are used and > different values to write in each. SunOS 4.X 'format/analyze/purge', (which was done at the request of SunFed, for some Fed contract) uses 4 repetitions with patterns: 0xaaaaaaaa (10101010) 0x55555555 (01010101) 0xaaaaaaaa (10101010) 0xaaaaaaaa (10101010) Followed by a final pass with: 0x40404040 (10000000) Consider this secure if you want. :-) For Unix variants, one might consider a 'patch' to libc that scribbled on the file passed to the 'unlink()' system call before actually performing the syscall. This will, of course, break Unix semantics because there is no way to tell from userland that no other process is holding the file open, so you'll scribble on the file prematurely. I guess itrunc() is what really need changing. Jim

1 0

Re: Destroying Data (Re: Remailer Policies)
by wcs＠anchor.ho.att.com 21 Dec '92

21 Dec '92

Yanek points out that "rm" doesn't destroy data on disks, just inodes, and that you have to overwrite the data to destroy it. However, he suggests that you do this by > 'cat /dev/null > /dev/hdxxx' which overwrites with zeroes all as well as overwriting swap space and powering off RAM. Won't work, and it's the hard way to do it: cat /dev/null produces zero bytes of output (there's a /dev/zero on some systems which produces lots of bytes of zeros.) If you're dealing with amateurs (i.e. local cops or maybe FBI, but not NSA/KGB, who can take the disk apart and use fancy magnetic techniques), you can get away with overwriting the data once with zeros or other stuff; a simple approach is to create a file large enough to fill all the unallocated space on the disk (either using /dev/zero or writing your own); be sure to be root so you get the last 10% of a BSD file system. For professionals, overwrite it once with 0s, once with 1s, and once with some test pattern like Xs or /etc/termcap. This still won't help if there are bad blocks which the disk controller is mapping out transparently to your system, of course, but amateurs can't read them. Swap space is tougher - you'll need to look at how your kernel allocates it to know how to fill it all up, or else zap it all after rebooting your system, if this is practical. The government's rules for handling, um, special data say that you either need an officially approved software program, or an Official Big Magnet, or else you need to physically destroy the magnetic media from the disk. I don't like having Big Magnets near my lab, but sandblasting has a real physicality to it, and floppy disks make this satisfying scrunch in a paper-shredder :-) Needless to say, unless you're Ollie North, you shouldn't be shredding your data when the cops are busting you ... Bill Stewart, somewhere in New Jersey

1 0

DES source for the HP48SX calculator.
by Bill Sommerfeld 21 Dec '92

21 Dec '92

I have implemented a version of the core of the DES algorithm for the HP 48SX calculator; I mentioned this in passing on this list a couple of weeks ago. Anyhow, in the general cypherpunks spirit of things, I'm willing to share this code... Note that this only ECB-mode encryption and key schedule computation, and not decryption. Both operations take about 12 seconds.. mostly because they're written in user RPL rather than system RPL or machine code. If the person at Berkeley who maintains the cypherpunks FTP archive wants to get in touch with me, I'd be happy to contribute this file to the archive; also, I'll mail it to anyone with a US or Canadian email return address. - Bill

1 0

Avoiding snags in the Law : Remailers.
by DrZaphod 20 Dec '92

20 Dec '92

In Message 19 Dec 92 19:45:33 EST, Hal <CompuServe.COM!74076.1041(a)netcomsv.netcom.com> writes: >I suspect that instead the approach would be to claim that remailer >operators are responsible for the material their remailers produce, >regardless of its original source. >Such a policy would be a plausible extension of current Internet >policies, IMO. RFC 822, the document which describes the format of >Internet mail message, in session 4.4.2 discusses the "Sender:" field, >and says, "Since the critical function served by the 'Sender' field >is identification of the agent responsible for sending mail and >since computer programs cannot be held accountable for their behavior, >it is strongly recommended that when a computer program generates a >message, the HUMAN who is responsible for that program be referenced >as part of the 'Sender' field mailbox specification." [Capitalization >in the original.] The need for a person to take responsibility for >each piece of mail that is sent would tend to lead to the policy >I mentioned. > Perhaps the solution to this is to run encrypted remailers, anonymously. The remailer could either run on it's own, or under instructions by an anonymous source [i.e PGPed instructions and software updates signed by the owner who has created a second key for his identity of remailer operator [Let's call him Oz]. Example: Joe creates an account on a random system, installing the nessicary software to run a PGP remailer. This software would be modified to accept instructions from a specific anonymous identity, for which Joe creates one, leaving the public key with the remailer. The remailer also has it's own key pair to decrypt and forward messages [of course]. People could now route their messages through Joe's remailer to anywhere they wish. The remailer should be set up to NOT keeps logs, except errors. Now Joe decides he wants to update his remailer with the latest scripts. He mails te scripts [thru various remailers], encrpyted with the remailers key and signed by Oz's key. The remailer decrypts the mail, verifies that it belongs to Oz, and updates itself. In this way no person can be held responsible for mail passing thru it's remailer. The only way to stop such a remailer would be to downright shut it down, or to communicate to Oz via the remailer [the scripts would allow Oz to pick up any mail left directly to the remailer withour a forwarding header -- of course it would reroute the messages, encrypted, thru various other well-known remailers]. TTFN! DrZaphod [AC/DC] / [DnA][HP] [drzaphod(a)ncselxsi.uucp] Technicolorized

1 0

Re: Destroying Data
by bart＠netcom.com 20 Dec '92

20 Dec '92

In audio recording which uses magnetic media similar to disks the only way to thoroughly erase a tape is with a so-called bulk eraser. This applies a very strong a.c. magnetic field and then is gradually withdrawn from the tape to allow the residual magnetism to "follow the hysteresis curve" down to zero. This would be difficult to apply to disks except floppies. Consider also the technique used in the Norton Utilities program "Diskwipe" which takes a /g switch which "Follows certain government rules for wiping". I can't find the manual but I think it specifies how many repetitions are used and different values to write in each.

1 0

Remailers and liability
by miron＠extropia.wimsey.com 20 Dec '92

20 Dec '92

Here is a post which is somewhat relevant: >Newsgroups: alt.censorship,news.admin.policy,comp.org.eff.talk >From: nagle(a)netcom.com (John Nagle) >Subject: Appeals court declares child pornography law unconstitutional >Message-ID: <1992Dec17.232618.19727(a)netcom.com> Summary: New decision by Ninth Circuit may affect BBS operators >Keywords: law pornography >Organization: Netcom - Online Communication Services (408 241-9760 guest) >Date: Thu, 17 Dec 1992 23:26:18 GMT The Ninth U.S. Circuit Court of Appeals ruled, in US vs X-Citement Video Inc., (CA No. 89-50556), that the sections of the Protection of Children Against Sexual Exploitation Act of 1977 that deal with distribution, transportation, and receipt of sexually explicit materials are invalid on First Amendment grounds. The court let stand the prohibition on the production of child pornography. This ruling needs to be looked at more closely, but it may help to remove sysop worries about someone posting such material on their system without their knowledge, or about network nodes being liable for material passing through them. This is a step forward, because it was one of the very few real legal risks a US sysop had to face, and now it appears to be dead. Do the lawyers out there agree with this analysis? Producing child pornography remains illegal, which is reasonable. John Nagle Source: Wall Street Journal, 17DEC92, p. B10 (Western edition)

1 0

Remailers.
by Hal 20 Dec '92

20 Dec '92

-----BEGIN PGP SIGNED MESSAGE----- Responding to Edgar Swank's message: > We've already discussed use of PGP by pedophiles to encrypt > incriminating diaries. It gets better. PGP and remailers can > be used to encrypt and ship "kiddy porn" GIF files. Even private > possession of such material is a serious crime in the USA. A chain > of anonymous and encrypted remailers could be used to drop kiddy porn > into newsgroups like > > alt.sex.pictures > > I'm sure that would create quite a stir! This could easily happen soon, as news of these remailers spreads. There's been talk on the net about a student at an Ivy League college who is being investigated by the FBI for allegedly posting illegal images containing child pornagraphy. Once people find out about anonymous remailers, especially ours with their chaining capabilities and encryption, they will realize that such posts can be made with almost total safety. Presumably this may increase the number of people who would attempt it. > Perhaps Duncan or another attorney would like to comment on legal > liability of remailers in these kinds of situations. I don't think > there's currently any law on what records remailers would have to > keep; if you didn't have them, you couldn't give them up. > > If this becomes a problem, expect legislation regulating or even > outright banning remailers. However, if remailer code has spread > over many national boundaries, such legislation may not be effective. My guess is that it will not be feasible to ban remailers, since it would be hard to draw the line between completely automated remailers, and simple manual forwarding of a message that someone sent you, which happens all the time and can hardly be made illegal. I suspect that instead the approach would be to claim that remailer operators are responsible for the material their remailers produce, regardless of its original source. So if child porn comes out, I am guilty of sending child porn. I can argue that my remailer was automatic and that I shouldn't be held responsible for what comes out of it, but my guess is that this argument will be rejected on the grounds of personal responsibility, and because no one forces me to run a remailer which sends out anything that comes in to it. Such a policy would be a plausible extension of current Internet policies, IMO. RFC 822, the document which describes the format of Internet mail message, in session 4.4.2 discusses the "Sender:" field, and says, "Since the critical function served by the 'Sender' field is identification of the agent responsible for sending mail and since computer programs cannot be held accountable for their behavior, it is strongly recommended that when a computer program generates a message, the HUMAN who is responsible for that program be referenced as part of the 'Sender' field mailbox specification." [Capitalization in the original.] The need for a person to take responsibility for each piece of mail that is sent would tend to lead to the policy I mentioned. With such a policy in place, if enforced by law, I don't think people would run remailers in this country because of the legal risks. There would still be the international remailers, though. > By the way, no-one has yet responded to my request to add features > to Eric's remailer to 1)remove the "sig" after "--" and 2)Anonymously > post to newsgroups available at the remailer site. Both these > features are present in the Australian remailer at Pax. Unfortunately > that remailer seems less secure than Eric's in that it keeps more or > less permanent records of its users at the remailer site and it > doesn't seem to be able to chain to other remailers. > > -- > edgar(a)spectrx.saigon.com (Edgar W. Swank) > SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca It should be possible to chain from Pax to our remailers, getting the best features of both. Pax could be the first remailer in the chain, stripping the sig. The message could then go through our remailers, providing non-traced security, at least if you can find someone who does not keep logs. Anonymous posting can be done already. Anyone can post to most newsgroups by sending mail to certain addresses. One such system is at Berkeley. Send to, e.g., sci-crypt(a)ucbvax.berkeley.edu to post to sci.crypt. There is another such system running in Austin, TX, I believe, but I don't have the corresponding net address handy. So this capability is already provided by our (or anyone's) remailers. One reason I haven't looked at stripping the .sig is due to an email discussion I had about a month ago with Eric Hughes. Eric strongly felt that message bodies should be preserved as much as possible by the remailers, in accordance with the general principle of Internet mail forwarding. Too much mangling is done already by mail gateways, and adding more changes might be harmful. Obviously, the remailers can't avoid doing some processing of the message body, what with the "::" pasting tokens and PGP decryption, but Eric felt that unnecessary changes should be minimized. I know Eric is working on some new remailer concepts so I want to defer to him on this issue for now. Hal Finney 74076.1041(a)compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKzOXf6gTA69YIUw3AQEvQQQArHXSwwrkQ3mSGOD60ZBV/p1R9RONqv2x S64iJjdJB43G2nxLHB2t9xXAKSdCT00shEtil8LWu20XW0rWXqmMXyYudtt3qf3t 2arqlvxdGXlPt3eISFJ97U6jaI1EhswPg29fjuXMMaKv5OO/gBKp1i9Cig7suZDt EkUDJihLQxc= =q6zH -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM

1 0

TEMPEST
by gnu 19 Dec '92

19 Dec '92

> There are plenty of other government conspiracies to focus on ! This one > seems a bit lame. Our government should not be our opponent when we try to find out how to provide high levels of privacy for ourselves, our computers, and our communications. Ignoring that, yes, TEMPEST doesn't look like a deep dark conspiracy. It's legal to shield your equipment and probably legal to export it (if you didn't use the classified TEMPEST specifications in building it, but reverse engineered them yourself). The government is not our enemy here (like it *is* our enemy in the drug war), but it isn't our friend either. John Gilmore

1 0