December 2003 - cypherpunks-legacy

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

Re: Kerberos v5's experience with ASN.1
by Theodore Ts'o 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- To: Cypherpunks Lite <cp-lite(a)comsec.com> Date: Sat, 2 Sep 1995 13:55:38 -0400 From: jis(a)mit.edu (Jeffrey I. Schiller) However, the problem with ASN.1 isn't its waste of space (which actually isn't that bad for a mechanism for encoding arbitrary objects). While I won't argue about the rest of Jeff's note about the use of ASN.1 being a mistake, I do want to point out that certain ASN.1 types are in fact very wasteful of space. Most notable of these is the ASN.1 Generalized Time --- which encodes the a timestamp in ASCII. ASN.1 GeneralizedTime therefore requires 17 bytes to encode, an over four-fold increase in the amount of space needed to store a time, compared with a 4 byte representation of "number of seconds since 1970". This is deadly in a protocol which has to store lots of timestamps, which is the case in Kerberos V5. We could have gotten around this problem by merely storing an integer whenever we needed to store a timestamp, instead of using the ASN.1 abstract type. Then it would have only taken 6 bytes (ASN.1 adds a 2-byte overhead for each object which you store). - Ted -----BEGIN PGP SIGNATURE----- Version: 2.6.1 Comment: Processed by Mailcrypt 3.2, an Emacs/PGP interface iQCVAwUBME9xO0QVcM1Ga0KJAQGiQwQAhSu4WpeVZ+hsN+o+NvWMwP8JK0GojhuI vWE1M3iIZttz4iMEbsziZ1KzWlkFTL8AKVWkzDAZ8t5lNMis9qObCfaQPQkKTLwJ UV20GjebckOzFx7Rp9OPDDI536cepvcjFN0cQkWtmiW2KP04TU9zr4caD4cfozDJ XYGZavYmpBQ= =9YUm -----END PGP SIGNATURE-----

1 0

Re: GAK
by terrell＠sam.neosoft.com 17 Dec '03

17 Dec '03

>Date: Sun, 3 Sep 1995 21:25:26 -0400 (EDT) >From: Brian Davis <bdavis(a)thepoint.net> >Subject: Re: GAK >On Fri, 1 Sep 1995, Timothy C. May wrote: > >> At 10:56 PM 9/1/95, Buford Terrell wrote: >> >> >If you've ever watched Not_at_all_Funny Home Videos or any of the >> >American Urinal school of tabloid television, you soon start feeling >> >that the real threat to privacy is not the guvmint, but all of >> >the yoyos with their little cam corders running around pointing them >> >at people. >> > >> >Security cameras in ATMS and at airline ticket counters do more >> >to threaten you privacy than do FIBBIE wiretaps, and PGP won't >> >protect you from them. (and usually neither will the courts). >> >> I absolutely agree with this, though this doesn't mean I'll stop worrying >> about the government's plans for key escrow (GAK), about limits on key >> lengths, or about other efforts to thwart strong security. > >I, of course, know of the "dislike" of GAK here. I am curious to know, >however, if the "dislike" is because government would have access under >any circumstances or if the primary worry is that government will cheat >and get access when most would agree that they shouldn't (either by the >judge "cheating" or a TLA stealing it). > >In other words ... if it took agreement by a review board composed of >non-LEA members of this list, would the escrow be acceptable?? > >EBD > In my case, it's simply a matter of principle: the government has no right to know what I'm saying. Search warrants may allow them to get to "things" that I have, but the First and Fifth amendments make words sacred. If the government can eavesdrop on my conversation, then my speech is no longer free. A review board consisting of cypherpunks has no more right to listen to my private conversations than does the FBI, so I would not agree to that proposal either. --buford

1 0

Re: ASN.1 and Kerberos version 5
by Carl Ellison 17 Dec '03

17 Dec '03

>Date: Sat, 2 Sep 1995 13:55:38 -0400 >From: jis(a)mit.edu (Jeffrey I. Schiller) >I'll say it. I was the person who pushed for the use of ASN.1 in Kerberos >version 5. I had this disease at the time that made me think that ASN.1 was >a good idea. I got better, unfortunately we have been living with the >results of my braino for quite some time now... poor Ted. Jeff, I'm collecting lists of ASN.1 problems as well as better solutions. If you'd care to contribute.... Otherwise, I'll post the results when they're firmed up. I got some *great* material from Burt Kaliski at the P1363 meeting and that needs to be folded in, so I know it's not soup yet. - Carl

1 0

Re: GAK Hacks
by aba＠dcs.exeter.ac.uk 17 Dec '03

17 Dec '03

Tim May <tcmay(a)got.net> writes on cpunks: > We did it for SSL, let's do it for GAK. > > Demonstrate that superencryption (encrypting within a GAK wrapper) defeats > GAK. And other kinds of hacks, including releasing "damaged" (inoperative) > versions of the proposed code (when it becomes available). I was just drooling over the fun to be had if and when this crap goes through. Surely a very fun thing to do. A new legit hobby for all those games crackers out there. (Hmm maybe not so legit, micro$oft has non- reverse engineering clauses on their stuff, but that doesn't stop anyone, and there's always remailers). One of their requirements was resistance to static patches, as someone else pointed out that is just not possible in software, if some gets really bored they can at worst disassemble the entire thing, and re-write it from scratch without any silly GAK stuff, or with a row of 00s where the escrowed key goes. > Or releasing "work-alikes." Etc. > > Granted, the demonstrations will be less clear than breaking the 40-bit key > was, partly because there is no clear-cut standard out there, and many > aspects of GAK are still in flux. > > But it could still be a powerful example, an example "by direct > demonstration," that government-mandated key escrow is problematic. > > (Of course, a sufficiently powerful or clear demonstration, picked up by > the popular press the way the SSL challenge was, could also cause the > government to tighten up the rules on GAK, such > as--speculatively!!!!--adding "compliance audits" to the GAK laws.) So the question is what do you prefer: 40 bits only or 64 bits which can be broken? Is it worth sabotaging what is essentially an impossible task open to having the GAK element hacked out? It would be much more fun if they'd agree to no limits on key sizes, and GAK. What happens if the result of the talks which Pat Farrell kindly described is that it is impossible? What is their next move? We've had "voluntary" hard-ware key-escrow, and it got chucked out by widespread derision of the idea, now the same in software. Which direction does the next phased attack come from? > But GAK Hacking could be an interesting project. indeed. Adam

2 1

Re: Collection of personal info
by dr261＠cleveland.Freenet.Edu 17 Dec '03

17 Dec '03

>letting it happen, and using cash instead of credit, is the smart answer I'm somewhat surprized at how much of an issue this is. The federal government prints up nice green paper for us to pay for things with. It's annonymous (to a large extent), univerally accepted (most of the time), fairly untracably (unless you really want to), easily available, doesn't collect interest, free to use, etc. No one is forcing anyone to use credit cards, etc.. Then again, being a kid, I have never bought anything with anything other than cash on the spot... -- Tobin Fricke (aka LightRay) The Digital Forest BBS (714)586-6142 dr261(a)kanga.ins.cwru.edu KE6WHF Amateur Radio, 1:103/925 fido

1 0

fast modular reduction
by Wei Dai 17 Dec '03

17 Dec '03

During the Crypto' 95 Rump Session, Josh Benaloh of Microsoft Corp. presented a new modular reduction algorithm that he and I developed. It is faster than the Montgomery method by about 10 to 15%, and is more general and easier to understand. The central idea is that it is easy to reduce a number to an equivalent one that's just one "block" (machine word) longer than the modulus, by repeatedly subtracting off the highest block, and adding back something that's equivalent, but smaller. In the following pseudocode, B is the radix in which the numbers are represented (2^32 for a 32-bit machine), n is the length of modulus in blocks, U is B^(n+1) mod the modulus, X is the number to be reduced, k+1 is the length of X, and Y is the result. 1. Y = X 2. For i from k down to n+1, repeat steps 3 and 4 3. Y = Y - Y[i] * B^i + Y[i] * U * B^(i-n-1) 4. If Y >= B^i, then Y = Y - B^i + U * B^(i-n-1) Tricks can be used to eliminate step 4, and to reduce Y to n blocks using one single precision division, and n more single precision multiplications. The algorithm will hopefully be written up more completely soon. Wei Dai

2 4

Fade to Black... / Re: Socio-Economic Cults (Re: Cypherpunk Cults)
by Anonymous 17 Dec '03

17 Dec '03

John Smith wrote: > A Japanese man holes up in his house and shoots at those who try to > take him away. A Caucasian man outside shoots back, fearing that the > Japanese is a spy, whose information will lead to Japanese victory in > the war. Both men are shooting, both fear for their lives. And in > each case, the fear could arguably be justified, based on the > information available to each man at the time. A black man holes up in his car, shooting at a white cop wearing the same uniform as the guy who shoved a toilet plunger up his ass the day before. The cop shoots back, fearing that the black man is a drug dealer who will molest his children, plant a bomb on an airplane, and evade taxes. Both men are shooting, both fear for their lives, and both hate what the other man represents in their mind and life experience and would like to see him dead. The Jap picks them both off, from a rooftop, and lives happily ever after. ILoveAHappyEndingMongel

1 0

Re: Notes from NIS&T Key Escrow Export conference.
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 7:59 PM 9/7/95, Pat Farrell wrote: >>"If keys are escrowed, what purpose does a 64 bit limit serve?" > >This question was asked, it seems like a zillion times, but >probably no more than four or five times. > >It is a bit of a belt and suspenders idea. But it also shows how >scared they are about real encryption. > >It is clear that this meeting is a shame. Everyone in industry ^^^^^ Sham? Or shame? Or, likely, both? Your account of the meeting merely confirms my worst fears. But don't they say the Chinese character for "crisis" also means "opportunity"? (Sort of the way the English word "oversight" has two very different and opposite meanings.) --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."

1 0

Key Escrow Papers
by John Young 17 Dec '03

17 Dec '03

We have scanned several of the handouts at the NIST Key Escrow Issues Meeting of September 6 (not present Sept 7). Perhaps someone, Pat Farrell or another, would be willing to make them available on a homepage or ftp site. If so we will send them over. If nobody volunteers we will send them by our puny e-mail contraption. Here's what we have ready to send: 1. The outlines of meeting topics of Raymond Kammer of NIST and Michael Nelson of the White House. (7kb) 2. Discussion Paper No. 4, "Example Potential Solutions for the Draft Export Criteria for Software Key Escrow Encryption," which offers example solutions for each of the ten criteria. (7kb) 3. The Business Software Alliance's dissenting blast at the government's key escrow proposal and export limit. This paper was loudly applauded. (19kb) 4. Trusted Informations Systems's "Thoughts on the NIST Escrow Issues Meeting Discussion Papers." (27kb in 2 parts) 5. TECSEC Incorporated's "Private Escrow Key Management: A Method and its Issues." (13kb) 6. Dorothy Denning's "Comments on Draft Criteria for Software Key Escrow Exportability" and "Comments on Issues for Key Escrow Agents." (8kb) Two other papers will be scanned later: 7. National Semiconductor's "Commercial Cryptography Ideas for Success" (9 pp. of large type) This contains graphics of the CAKE program and a "Proposed NIST Escrow Certificate Heirarchy" which cannot be easily distributed by us, so we offer this by fax. 8. TECSEC's "The Merger of Technology and Cryptographic Key Management" (6 pp.). Note 1: It was Michael Nelson of the White House who said that the reason to maintain the 64-bit limit for export was because the key escrow methodology had not yet been proven reliable and that the security agencies insisted on the relatively weak system in case key escrow failed. Note 2: At the B-2 breakout session there was strong debate on a proposal for a "Criteria Zero": Before addressing any of the details of Criteria 3, 4 and 9 as presented to us, Group B-2 registers its view that export under general license of strong encryption should not require key escrow. A vote on the proposal was 7 yes, 7 no and 13 absentions. It was not reported to the plenary session.

1 0