- cypherpunks-legacy - lists.cpunks.org

Son of Clipper (commentary)
by Jim Gillogly 17 Dec '03

17 Dec '03

I didn't want to mix my comments with the recent discussion paper I sent along, so here they are separately. Please refer back to my last msg to see the points I'm bitching about. It's a depressingly restrictive list of things to require for software escrow encryption. I can only conclude that they're not serious. Clipper itself fails to meet many of them, including (I think) #1, #2, #5, and #6. Rumor has it that Clipper does not meet #9 either -- at Crypto '95 somebody in the Key Escrow session said many government Clipper keys are not escrowed, and somebody in the back spoke up and said he owned such a chip. By the way, Moti Yung (noted crypto guy at IBM Yorktown Heights) presented more breaks in Clipper's protocols like those Matt Blaze found, and pointed out some aspects of Matt's break that he thinks make it more important than previously thought. Other things that bother me about the list: #1: If it's escrowed, there should be no need to limit the key length unless somebody's planning to cheat. #3: This rules out the possibility of escrowing individual session keys to limit the access of LE to sessions they are entitled by law to intercept. #5: Care to tell us how to create software that can't be patched? This is one that's been played in the marketplace and has lost. The battle between copy protectors and crackers has been decided in favor of the crackers: legitimate users largely refuse to buy packages that are too messy to deal with (e.g. they leave hidden files all over the disk, which may interfere with backups or other programs) or that use special purpose hardware (e.g. dongles that eat up a printer port). This one's a loser, I think. #6: This is clearly a research issue. Several speakers (even pro-GAK) at Crypto '95 said the policy decisions are being made before the research has been done. The protocols and system specifications are key here, and it's not obvious how this criterion can be met. It's not obviously impossible, but it certainly hasn't been solved in Clipper. #7: One of the Crypto '95 attacks on the Clipper protocol makes use of this misfeature of Clipper. It allows a broadening of the net of captured keys so that many more unauthorized messages may be read. #8: See #3 above -- let's wait on the policy decision until we have a policy debate. A mandated compromise is an oxymoron. I (for one) would prefer to see much more limited keys (like session keys) if Congress decides that the right to privacy is not infringed by these technologies. There's nothing in here that specifically excludes dividing your keys among multiple escrow agents; I assume this is still an open issue still, or that it goes without saying (one way or the other). #3 and #6 make it impossible to prevent LE from reading messages from before or after their legally authorized window. This is clearly broken. Again, this appears to be trying to put all the power in the hands of LE to the detriment of the people. It's advertized as a compromise, but I see nothing gained over Clipper I. The only differences appear to be that the escrow agent(s) may be private instead of government, and the algorithms may be something other than SKIPJACK as long as they are at least 16 bits weaker as well as being known algorithms. It also doesn't address the main problem with Clipper I: that it wouldn't work, since (like Clipper I) it will catch only crooks who are smart enough to encrypt but stupid enough to encrypt with a system they (should) know LE can read -- probably a null set. If, on the other hand, this is made mandatory for encrypted transmissions, it will create a new and unnecessary class of criminals, probably including myself (though I won't promise to break any laws at this point). This really burns me up. What do they think they're doing here? Am I missing a big piece of it? Jim Gillogly Hevensday, 14 Halimath S.R. 1995, 22:02

1 0

RE: VCRPLUS Huffman code
by James A. Tunnicliffe 17 Dec '03

17 Dec '03

>On Tue, 5 Sep 1995, Peter Trei wrote: > >> >> > Has anyone worked out the VCRPLUS code? >> > > <chomp> > >> Code which implemented this partial crack was published on the net, >> and the VCR+ people got very upset about it - apparently they make > > I believe the code is in the cookbook archive at ftp.ee.ualberta.ca, >but when I just tried to confirm I got timeouts. > > Brian Among many other places, you can get this off my Web page, in: http://www.inference.com/~tunny/crypto/primer.html - Tunny ______________________________________________________________________ James A. Tunnicliffe | WWWeb: http://www.inference.com/~tunny Inference Corporation | PGP Fingerprint: CA 23 E2 F3 AC 2D 0C 77 tunny(a)Inference.com | <--finger for key 36 07 D9 33 3D 32 53 9C ======================================================================

1 0

Re: Emergency File Wipe Algorithim
by Andrew Loewenstern 17 Dec '03

17 Dec '03

Lucky Green writes: > Didn't I just read a day ago that Robert Morris (ex-NSA) cautioned > that one should never underestimate the time and effort an opponent > is willing to put into recovering your data? > > May I also point out that the rules of economics do not apply to > the federal government, since it insits - quite successfully - on > having a monoploy on using lethal force to extract arbitraily large > amounts from hundreds of millions of working Americans? As always, Rubber Hose Cryptanalysis(*tm, patent pending) is usually the cheapest way to go...if you're a federal government. But not all threats are that serious. For instance, I have no fears that the admins here would grovel over the oxides on RAM cells in order to determine the pass-phrase of my PGP key if they suspected me of doing something naughty (even if they knew this was possible, which is unlikely). You can get really paranoid about security and rightly so if your opponent is a federal government. However, pushing key-material bits around RAM in order to prevent them from being burned into the chips is probably going to do you little good if, for instance, a hardware keystroke monitor is surreptitiously installed in your keyboard (which is likely far cheaper and easier than analysing RAM chips and maybe even disk platters). BTW, this is not a troll and I know that the possible constitutionality of court-ordered disclosure of passphrases or key-material has been hashed over many times in the past here, but have any cases with this particular attribute gone through court yet? There were reports even years ago of pedophiles and other agents of the Four Horsemen using PGP to encrypt diaries and such, have any of these cases gone to court yet and did the prosecution attempt to force the defendant to reveal a passphrase?? andrew (wonders how many readers will take their keyboards apart to look for radio transmitters)

2 1

Another Son of Clipper discussion paper
by Jim Gillogly 17 Dec '03

17 Dec '03

I sent along two discussion papers for tomorrow's NIST session on the revised plans for GAK last week. Here's the third. Jim Gillogly Hevensday, 14 Halimath S.R. 1995, 20:49 ----------------------------------------------------------------------------- Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #3 Export Criteria Discussion Draft -- 64-bit Software Key Escrow Encryption As discussed at the SPA/AEA meeting on August 17, 1995, the Administration is willing to allow the export of software encryption provided that the products use algorithms with key space that does not exceed 64 bits and the key(s) required to decrypt messages/files are escrowed with approved escrow agents. On the same date, the September 6-7 key escrow issues meeting at NIST was also announced. The two principal topics at the meeting will be: discussion of issues of exportability of 64-bit software key escrow encryption and 2) desirable characteristics for key escrow agents. In order to help make most productive use of the limited time available at the upcoming meeting and to better focus deliberation, the following criteria are being distributed for discussion purposes. Since it is important that final criteria be clear, straightforward, consistent, and implementable, please review these draft criteria and be prepared to discuss how they may be refined and made more specific. --- Draft Export Criteria --- for Software Key Escrow Encryption Software key escrow encryption products meeting the following criteria will be granted special export licensing treatment similar to that afforded other mass-market software products with encryption. 1. The product will use an unclassified encryption algorithm (e.g., DES, RC4) with a key length not to exceed 64 bits. 2. The product shall be designed to prevent multiple encryption (e.g., triple-DES). 3. The key required to decrypt each message or file shall be accessible through a key escrow mechanism in the product, and such keys will be escrowed during manufacture in accordance with #10. If such keys are not escrowed during manufacture, the product shall be inoperable until the key is escrowed in accordance with #10. 4. The key escrow mechanism shall be designed to include with each encrypted message or file, in a format accessible by authorized entities, the identity of the key escrow agent(s), and information sufficient for the escrow agent(s) to identify the key or key components required to decrypt that message. 5. The product shall be resistant to any alteration that would disable or circumvent the key escrow mechanism, to include being designed so that the key escrow mechanism cannot be disabled by a static patch, (i.e., the replacement of a block of code by a modified block). 6. The product shall not decrypt messages or files encrypted by non-escrowed products, including products whose key escrow mechanisms have been altered or disabled. 7. The key escrow mechanism allows access to a user's encrypted information regardless of whether that user is the sender or the intended recipient of the encrypted information. 8. The key escrow mechanism shall not require repeated involvement by the escrow agents for the recovery of multiple decryption keys during the period of authorized access. 9. In the event any such product is or may be available in the United States, each production copy of the software shall either have a unique key required for decrypting messages or files that is escrowed in accordance with #10, or have the capability for its escrow mechanism to be rekeyed and any new key to be escrowed in accordance with #10. 10. The product shall accept escrow of its key(s) only with escrow agents certified by the U.S. Government or by foreign governments with which the U.S. Government has formal agreements consistent with U.S. law enforcement and national security requirements. Note: Software products incorporating additional encryption methods other than key escrow encryption methods will be evaluated for export on the basis of each encryption method included, as is already the case with existing products. Accordingly, these criteria apply only to the key escrow encryption method incorporated by a software product, and not to other non-escrowed encryption methods it may incorporate. For instance, non-escrowed encryption using a key length of 40 bits or less will continue to be exportable under existing export regulations. - - - Please also review discussion paper #1 (distributed earlier), which raises a number of issues involving exportability criteria and how exportable products could be designed. Discussion paper #2 (also previously distributed) presents questions involving key escrow agents. Note: These issues will be discussed at the Key Escrow Issues Meeting to be held September 6-7, 1995 (9:00 a.m. - 5:00 p.m.) at the National Institute of Standards and Technology (Gaithersburg, Maryland). The meeting will be open to the public, although seating is limited. Advance registration is requested, please contact Arlene Carlton on 301/975-3240, fax: 301/948-1784 or e- mail: carlton(a)micf.nist.gov. 9/1/95 -----------------------------------------------------------------------------

4 3

Re: NSA says Joe Sixpack won't buy crypto
by Pat Farrell 17 Dec '03

17 Dec '03

Black Unicorn <unicorn(a)access.digex.net> writes: > On Tue, 5 Sep 1995, Jeff Simmons wrote: >> So what form of GAK or trap-doorodoes lotus notes contain? > No, it's just been so weak before the current implementation of RC4 (and > note the export version still has 40 bits) that it might as well be > nothing. Uni is right. Notes used RSA, which starts out fine. but it has nothing like PGP's passphrase to protect the private key. You can simply copy the "username.ID" file, and you can sign and encrypt messages with "username"'s nym. Of course, Corporate america loves Notes, which is why IBM bought it. Weak encryption for weak minds. Pat Pat Farrell Grad Student http://www.isse.gmu.edu/students/pfarrell Info. Systems & Software Engineering, George Mason University, Fairfax, VA PGP key available on homepage #include <standard.disclaimer>

1 0

Re: Another Son of Clipper discussion paper
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

At 16:36 9/5/95, Mike McNally wrote: >If the algorithm is public (and to stretch a point, if the executable >makes it onto somebody's hard disk, it's effectively public), I don't >really understand how the above can be made a realistic goal. Windows 95 is on a lot of people's hard drives. It is therefore public and available for every one's inspection. How many people do you know that have reverse engineered Windows 95. How many of those use a reverse engineered version. I'd venture it is zero out of zero. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred.

3 2

Re: Forgery, bills, and the Four Horsemen (Articles and Comment)
by Hal 17 Dec '03

17 Dec '03

From: shamrock(a)netcom.com (Lucky Green) > So it is harder to compile dosiers on people. Big deal. The recipient can > still determine who gets the goods paied for by the "anonymous" ecash by > conventional means (hint: shipping address), so the payee anonymity is of > little value as far as protecting the privacy of the payer (most likely > the recipient of the goods) is concerened. This would be true for physical goods in any payment system, no matter how anonymous, unless physical remailers are used (and they have their limitations). However software (including music, video, etc.) would be easier to deliver anonymously. It is generally agreed that more of our economy is moving towards information exchanges and so ecash-like systems can play an increasingly larger part in protecting privacy. To me, this is indeed a big deal. Even for physical goods, the use of ecash is better than credit cards because the information about purchases is distributed rather than centralized. Every time I look at my credit card bill I feel dismayed at what the company is finding out about my family. Ecash could also be used as a cash replacement in smartcards. Consider as an alternative a fully traceable payment system, where you use your debit card at the supermarket, the bus station, the snack bar, the drug store. I suspect that if we don't get something like ecash then this system will be the alternative. It opens up possibilities for dossiers that will fulfill Big Brother's dreams. Virtually every move of every citizen will be recorded in just a few centralized places. IMO the protection of payor privacy that even Chaum's limited ecash provides is very important. > Ecash of course is of *no* value for the various assasination markets, > drug dealing, money laundring, etc that routinely get mentioned in the > same paragraph as Ecash. The reason is the *full traceability* of the > payee that has been deliberately built into the current version of Ecash. > A "feature" that you may rest assured will be part of all future versions > backed by anyone with even marginal reputation in the financial markets. Well, I have never fully accepted the notion that crypto was going to usher in an age of anarchy. As long as we deal with physical goods in the physical world it seems to me that anonymity will be difficult. On the net it is easier but man does not live by bits alone. For me, protecting privacy is a difficult enough problem. Transforming the world into a libertarian/anarchist utopia is somebody else's job. Hal P.S. Without seeing the technical specs it is hard to describe in detail, but generally Chaumian ecash allows fully anonymous coerced transfers. The payee/coercer supplies the blinded coins and forces the payor to use them to make withdrawals from his account. The resulting signed tokens are passed to the coercer who unblinds them and now has fully anonymous, untraceable cash tokens which he can spend.

1 0

Re: Forgery, bills, and the Four Horsemen (Articles and Comment)
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

At 19:32 9/5/95, Bryce Wilcox wrote: >I hope I'm not missing anything here. Only that Ecash has no benefits for transactions that are of an illegal nature. The meaning of "illegal" is of course increasing as new laws are passed every session of the legislature. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred.

2 1

Re: Are booby-trapped computers legal?
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 4:19 AM 9/6/95, Jim Choate wrote: >> Thus, I suspect it is fully legal to build an electrified fence around >> one's PC, providing suitable warnings are included. >> > >As far as I know the owner of property has no legal right to kill a person >either traspassing or stealing it in any of the 50 states. There was a >recent federal ruling that basicly says that if you meet a burglar in your >home at nite you can not kill or otherwise harm them unless you're life is >directly threatened. In short, you MUST give up the ground if at all >possible. Federal and all 50 states (as far as I have been able to >determine) rule human life to have a inherantly higher value than property >of any type (this does not apply to government institutions). Well, I wasn't saying one had a legal right to kill a person either trespassing or stealing, I was saying that electrified fences carrying lethal voltages are extant. How they got that way, and what licenses are involved, is unknown to me. But they do exist. >In Texas and all other cattle states that I am aware of, there are specific >laws that limit how much voltage and current capacity an electrified fence >can have. These laws specificaly prohibit any form of lethal installation. >There is no license required nor do you have to mark the fences as electrified. Cattle fences are not what I was talking about. I have an electrified fence on one side of my property, to keep the deer away. Lethal voltage fences, to keep humans out, are another matter. .... >I don't know what you call it but if nothing else it is ethicaly and moraly >reprehinsible. Different strokes for different folks. Anyone entering my house unannounced faces lethal response. I think of it as evolution in action, and doubt I would lose any sleep over this. It has nothing to do with equating human life over property, it has to do with defending one's property and (maybe) one's life. Here in California, it is becoming more and more common for "home invasions" to be followed by execution of all of the witnesses. (Read "The San Jose Mercury News" for accounts of gang invasions in which all the residents in a home are lined up and shot, excecution-style.) I won't get into a discussion of which states permit lethal force responses, as this is a topic which even I think belongs in talk.politics.guns or similar fora. Suffice it to say that most states allow lethal response under threatening circumstances. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

2 1

Are booby-trapped computers legal?
by tcmay＠got.net 17 Dec '03

17 Dec '03

(I've changed the name of this thread.) At 2:30 AM 9/6/95, Lucky Green wrote: >I am wondering about the legalities of booby trapped computer equipment. >Would it be legal if a clear warning to the fact was posted on the >hardware? There are two types of "booby traps" to consider: * Type 1 Booby Trap: a shotgun is placed inside a home, set to fire if and when a burglar enters. Or an electrified region of a room is set to "get energized" when an intruder enters. These are "surprises" and are canonical booby traps. These have been found to be illegal in several court cases. (I'm not a lawyer, but I've been reading about them for 20 years. Famous cases where a burglar sued, and won, because he was injured when breaking into a house.) * Type 2 Booby Trap: electrified perimeter fences. So long as these are adequately marked ("If you touch this fence, you will probably die"), and are not public nuisances where children and pets will inadvertently validate Darwin's theory, these are--I think--legal. There may be license fees required, to build an electrified fence, but I think it is possible to build a lethal voltage electrified fence on one's property. Thus, I suspect it is fully legal to build an electrified fence around one's PC, providing suitable warnings are included. I would not call the second type a real booby trap, though some courts might, depending. A properly labelled electrified fence seems legal, on one's own property, but may not be. And certainly I think any explosive-rigged system is illegal, for explosives reasons if not for booby trap reasons. I know of no case law on this, and suspect that if an FBI agent were to be electrocuted or blown up upon trying to open/use/disconnect the PC, even with clear warnings, that a prosecution would happen. Results are unclear (to me). (I think that if an FBI agent were to be electrocuted while climbing on a clearly labelled electrified fence, no prosecution would result.) Of course, if a PC were to be clearly labelled as being rigged, then steps could presumably be taken to defuse the arrangement. >Interesting side note: a few months ago, several hundred 5 gallon >containers of insecticide were stolen from the lot of an agricultural >supply dealer here in California. The incident made a small note in the SF >Chronicle. It was mentioned that the FBI is taking part in the >investigation. > >What wasn't mentioned was that this insecticide is an ideal precursor to >various forms of neuro toxins, namely Tabun and Soman, two types of nerve >gas so vicious and toxic that even Hitler refused to approve their use. I >predict that eventful times are just around the corner. As Lucky knows, I live out in the country. I agree that some "muckers" (R.I.P. John Brunner) are likely to mount assaults on urban centers. Bad news for some. But then the good news is that the threat of nuclear annihilation has all but gone away completely, and that cancels out an awful lot of the minor bad news items the scribblers keep telling us are so awful. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

12 11