December 2003 - cypherpunks-legacy

"Regulation of Commerce" and the Crypto Issue
by tcmay＠got.net 17 Dec '03

17 Dec '03

It seems to me that in recent years nearly any type of sweeping legislation is justifed, constitutionally, by the clause in the U.S. Constitution which says Congress shall have the power to regulate commerce. (More precisely, the clause says: "To regulate commerce with foreign nations, and among the several states, and with the Indian tribes;" This is usually interpreted to mean _interstate_ commerce, and not sales/commerce/etc. that do not centrally involved more than one state....obviously nearly all things sold in one state are sold in other states, so there is lattitude for applying the commerce clause, albeit wrongly.) Today's news is the sweeping new restrictions on tobacco and cigarettes, including restriction on advertising and even on the placement of tobacco and cigarette logos and names on sports jerseys and shirts. (The much-publicized press event is not for another hour, as I write, so I don't know all the details. I'll be watching.) Note that similar restrictions on alchohol advertising were recently struck down by the Supreme Court as being unconstitutional infringements on free speech. Many expect the same outcome with these latest proposed restrictions. (The issue of advertisements of hard liquor, cigarettes, condoms, and other "unhealthful" [sic] products on television and radio is of course complicated by the role of the Federal Communications Commission and by "gentlemen's agreements" not to carry advertisements for some products.) Personally, I have never smoked, nor chewed, nor mainlined nicotine. Personally, I dislike cigarette smoke. But this is all _personally_. If a restaurant, bookstore, airline, bar, antique store, gym, or whatever wishes to allow smoking (or not), this is there choice. As many of us see things, it is not for the government to take a kind of "poll" of what people like and dislike and then to impose rules on property owners as to what smoking or nonsmoking policies they may set. Likewise, if I want to silk-screen a "Joe Camel" image, or a "Bud Frogs" image, on a t-shirt, this is between me and the putative owner of these images. Free speech and all. Or, to remove any confusion with the issue of owned logos, to silk-screen a fictitious cigarette brand on a shirt and then wear it, or sell it. It seems likely that individual wearers of such shirts will not be busted (think of how many already exist, and there is no plan for confiscating them), but that the burden will be placed, as it is so often conveniently placed, on the shirt makers. The catch-all for these laws seems to be the "regulate commerce" language in the Constitution. Cigarettes are sold in multiple states, the logic goes, so the commerce clause gives the government the power/authority to regulate it. (Well, Steven King novels are sold in all 50 states, too. Does this "regulate commerce" clause give the government the power/authority to regulate what King puts in his novels? Or to ban advertising for Steven King novels? Or to require that stores only sell such novels to adults?) This language is already being cited for some as a justification for regulating encryption (hey, some businesses use it!), digital signatures (ditto), and other forms of crypto. In fact, since nearly everything involves "commerce" in some way, whether interstate or not, the "regulate commerce" clause can presumably be used as a jusitification for interfering in all sorts of areas. The several legal experts out there on this list can clarify any errors of interpretation I have made. I certainly know that the commerce clause cannot be used to suppress certain kinds of speech, though the boundaries of where it may be applied seem unclear. I do expect it to be used for crypto, though, and this might even be upheld by the Supremes, especially in any areas directly involving "digital commerce." We should watch for this, and think about ways to deflect or derail such interpretations. --Tim May We got computers, we're tapping phone lines, I know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

3 2

The Future Of Cyber Terrorism
by Joseph M. Reagle Jr. 17 Dec '03

17 Dec '03

The Future Of Cyber Terrorism The proceedings or a recent conference on the subject of Cyber Terrorism are now available online. The conference looked at terrorism carried out with the tools of today's information age and against the computer and information systems that the world increasingly depends upon. World Wide Web: http://www.acsp.uic.edu/OICJ/CONFS/terror02.htm _______________________ Regards, I hate quotations. -Ralph Waldo Emerson Joseph Reagle http://rpcp.mit.edu/~reagle/home.html reagle(a)mit.edu E0 D5 B2 05 B6 12 DA 65 BE 4D E3 C1 6A 66 25 4E

1 0

secret message
by JOHN E. HOLT 17 Dec '03

17 Dec '03

Date: 01-Aug-96 14:50 EDT From: JOHN E. HOLT [76473,1732] Subj: puzzle ^%}{{ ZZ VVPAGMIGJEKMCCHIAKKPEHJDDDLOABGAMMJOCDFNOLNOKKKNIADPBGPPOEPIDCEMPGWW VVFCMOPKLKPJOHCNCJBDGOOJKFANCJJBDBMDIFIEKEDPLKDDGMPLHMIIPIJFMKOLENWW VVCAKJGJCKPAEOOMLJPNFJEKEINIHFKHNOLPCAHLEKHHLMHJFCOEKAFAGPHJBCPBHBWW VVOKLAENICAFDHEOEODMHMFGIONMAACAOHEOHDAJDNENGAHABNHGOCCPJNFDMAMKADWW VVMGDHKGPKBEIDBNLOCMLFMEIOKBFBFKJIMIIIFKJDFENCBPAPFBAOFMHEDODBFFPDWW VVOMFFJBNGEJPLGHJLFOBLFOGCBKAACEICLBIKHGILKCLMHPFIAHPDEOOODPPMLGDNWW VVGLDNEBDINMILDJDOJOJNKCLIBBKBCBEJPBJCFHGKMFLLEPGLGOOIIGAKJEGNPFHDWW VVIJBMFLALHPEHHGEGPCLGILBDBMEGMOGOIFBPPONGEDJPNFNMPCJFJPAEMIDOEMBLWW ZZ ZZ Distribution: To: ME > [76473,1732]

1 0

Re: (fwd) ANNOUNCE: Free Little PGP Credit Card App
by Alan Olsen 17 Dec '03

17 Dec '03

At 07:54 PM 8/22/96 -0400, Damaged Justice wrote: >>From: "David j. Sopuch" <djs(a)iwinpak.com> >Newsgroups: comp.infosystems.www.misc >Subject: ANNOUNCE: Free Little PGP Credit Card App >Date: Thu, 22 Aug 1996 12:00:24 -0400 >Organization: Datamax Research corp. >Lines: 10 >Message-ID: <321C8418.2647(a)iwinpak.com> > >v2.08 of the iWinpak Internet Payment System is now available in >both freeware and shareware versions at http://www.iwinpak.com An interesting little piece of CGI code, but the demo leaves a bit to be desired. The demo is for bank checks. The order form has you sending your bank information (including bank number and check info) in the clear. So the hooks into your credit card are not sent in the clear, but the ones to your bank are... Double plus ungood. It is a start... How good of one, I am not certain though... --- Alan Olsen -- alano(a)teleport.com -- Contract Web Design & Instruction `finger -l alano(a)teleport.com` for PGP 2.6.2 key http://www.teleport.com/~alano/ "We had to destroy the Internet in order to save it." - Sen. Exon "Microsoft -- Nothing but NT promises."

1 0

strengthening remailer protocols
by peter.allan＠aeat.co.uk 17 Dec '03

17 Dec '03

This is long enough. I've been brutal and cut sections less likely to promote discussion. (I've also contacted OUP about Ganley's book, and may buy it if I can kid myself I don't need the money.) ============================================================ August 1996 Peter M Allan peter.allan(a)aeat.co.uk Strengthening Remailer Protocols STATUS OF THIS MEMO This memo proposes improvements for the Mixmaster protocol and requests discussion and further suggestions. Distribution of this memo is unlimited. INTRODUCTION Lance Cottrell's documents [1] and [2] describe the current Mixmaster protocol and attacks against it. This memo began as a response to those thoughts, but has developed in discussion with Cottrell. SPAMMING ATTACK [2] describes an active attack where many messages are sent to an honest remailer to separate a message of interest from other traffic. The aim is to clear other messages out of the message pool, wait for the target and finally eject that from the pool. The target message is identified because the attacker can recognise his own messages. Attempts to defeat this attack could well be based on preventing the attacker from recognising his own messages. That is the approach taken here. RE-ENCRYPTION AS A SPAM DEFENCE In this diagram remailer 'A' has received a message addressed to himself. Inside that is one to 'B' - unreadable to A. Further layers are hidden of course. AB????? decrypts to B????? This means that our remailer can only disguise the message by re-encrypting it on the outside. But the message has got to make some net progress toward delivery. The trick is that a remailer can find the outer two headers addressed to him and process both of them. Two headers processed and one rewound is net progress. When the header rewound is addressed to the same recipient as was next on the list anyway the diagram looks like this. Actions at 'A': AB????? decrypts to B????? B????? encrypts to BB????? Actions at 'B': BB????? decrypts to B????? decrypts to C???? encrypts to CC???? The beauty of this is that it is compatible with the existing protocol. If a remailer only knows about removing layers of encryption it still fits into a network where some can do both actions. Whether it sends or receives the message it still works. RE-ENCRYPTION IN THE MIXMASTER ROTATING QUEUE MODEL Instead of layers like an onion, Mixmaster has a queue of headers that get rotated. A used header goes to the back of the queue where it can never again be read. At some point the header at the front of the queue is found to be the last one, and the message is sent on its final hop. For a header queue the above actions look like this: Actions at 'A': AAAB??? -> AAB???a -> AB???aa -> BB???aa In general when the first H headers are addressed to the remailer reading them, (H-1) rotations will be performed, and the top header will be overwritten with another one with a random key and IV to encrypt the rest of the message. The number of headers present remains 20, however many or few of these are still to be read. No valid header block is ever overwritten, only used header blocks that are good for nothing. This is always possible because after a remailer receives a message at least the one header it has just read must be of no further use. This will hide the message content from eavesdroppers, but not from the next remailer in line - 'B'. Assume that remailer B is operated by an attacker, and that he directs spam messages there after host A (which is holding your message in the pool at the time of the attack). B can read all messages sent by the attacker (who knows B's private key). This is also why I think link encryption offers incomplete protection. RE-ENCRYPTION WITH CHEATERS Mixmaster assumes that no particular remailer in the network can be trusted and that the user does not know which remailers cheat. The message passes through a chain of remailers, who aim to hide information from each other so that the compromise of some of them will not disclose the original sender and final destination. Central to the spamming attack is the idea that the attacker can recognise the messages he is trying to trace. This is done by eliminating his own messages. The whole set - not just some of them. It can be arranged that the attacker does not obtain the whole set until it is too late to trace the target message (i.e. after a few hops, when it is likely to have met other legitimate traffic). The partial information the attacker obtains before all the spams are identified will be of some use, but following each of several leads with a new spam attack is unappealing as the number of suspect messages will just grow. The remailer needs the freedom to divert packets to another remailer. This is shown below; where remailer C was chosen at random. Actions at 'A': AAAB??? -> AAB???a -> AB???aa -> CB???aa Each remailer could have three options when sending a packet to its next host. 1) rotate all possible headers, and send the result (current protocol) 2) re-encrypt message with new 3DES key and IV. Do not divert. 3) re-encrypt message with new 3DES key and IV. Divert at random. Good probabilities for these options might be: 1) 20% P(1) = P(3) The number of headers the next host can read should not reveal whether a diversion has just been made. (We care about this because it discourages cheaters deliberately refusing to pass on your mail.) 2) 60% Other outgoing packets are not distinguishable from spams. 3) 20% Should not approach 100%. (To arrive is better than to travel in hope.) A spam attack as described in [2] would use many more packets than those in the message pool (N) on the host under attack. The number of spam packets diverted to honest remailers (a proportion R of the whole) would be about MANY . N . P(3) . R and those diverted twice in succession to honest remailers would be about MANY . N . P(3) . P(3) . R . R and I'd expect a figure above 5 here to thwart the spammer, because of the time taken to collect the 5 spams. This diversion (adding steps to the middle of a chain) seems different from a Middleman scheme [3] where extra hops are added at the end. This scheme does NOT allow a remailer to choose the rest of the chain to be followed. A dishonest remailer cannot bypass any remailer chosen by the original sender (in the hope of following the message to its destination) using only cooperating dishonest remailers) because the message has been encrypted in the public key of each remailer the sender chose before it entered the network. REFERENCES 1 Frequently Asked Questions about Mixmaster Remailers FAQ Version 1.8 July 4 1996 by Lance Cottrell <loki(a)obscura.com.> 2 http://www.obscura.com/~loki/remailer/remailer-essay.html by Lance Cottrell <loki(a)obscura.com.> 3 email "Re: middleman - what is it ?" "John A. Perry" <perry(a)alpha.jpunix.com>

4 3

Re: The Future Of Cyber Terrorism
by jya＠pipeline.com 17 Dec '03

17 Dec '03

http://www.acsp.uic.edu/OICJ/CONFS/terror02.htm This quackery-puffery is truely hilarious. Worth reading for brave attempt to distinguish between our-adorable-intelligent-children qua hackers and terrifying next-door-neighbors so differently-abled-from-us cyber-terrorists. Unsubtly shaded white, off-white, black and blacknet movie-plotting. Thus Sprachen Zarathrustran Klaus: Commerce in ignorant-inner-fear-panderings regulation time.

2 1

Anonymous Remailers
by chris230＠juno.com 17 Dec '03

17 Dec '03

When you mail an item through more than one anonymous remailer, how does that make it anymore anonymous, or doesn't it?

1 0

FW: Cryptography Revisited
by Paul Robichaux 17 Dec '03

17 Dec '03

Anybody want to give this guy The Business? Earlier attempts didn't seem to sink in. -Paul >Path: HiWAAY.net!imci2!imci3!newsfeed.internetmci.com!news.mathworks.com!nntp.primenet.com!news.primenet.com!btcarey >From: btcarey(a)primenet.com (Brent A. Carey) >Newsgroups: comp.sys.mac.programmer.help >Subject: Cryptography Revisited >Date: 23 Aug 1996 01:15:01 -0700 >Organization: Primenet Services for the Internet >Lines: 67 >Message-ID: <btcarey-2308960115290001(a)news.primenet.com> >X-Posted-By: @198.68.41.180 (btcarey) >Mime-Version: 1.0 >Content-Type: text/plain; charset=ISO-8859-1 >Content-transfer-encoding: 8bit >X-Newsreader: Yet Another NewsWatcher 2.2.0 > >I am posting again to hopefully clear up my last post on this topic. I >have received a dozen e-mail replies since I posted less than a day ago. >I believe I poorly represented my request earlier. > >I am retired professional with several years of training and experience in >intelligence analysis and cryptanalysis. The encryption scheme I >developed was employed for 3 years for passing sensitive data over >unsecure channels. Working for the government, the original program was >written for DOS and enjoyed the benefit of physical security. That is to >say, access to the encryption program itself was carefully restricted. > >Where I feel I was unclear is on the key to the scheme's security. Any >encryption scheme can be cracked provided the cryptanalyst has enough of a >sample to work with, enough time, and/or enough processing power. My >encryption scheme relies on data bursts of time-sensitive packets. Each >machine running the program has its own time and packet signature. The >unique signatures make it impossible (nothing is impossible) to decrypt a >complete file without access to both the sender's and receiver's >signatures. Even then it would take an enormous amount of processing >power to crack (more than big business can justify, but not much for major >governments). The only way to obtain a computer's signature (which is >easily changed on a regular basis), is to have physical access to the >computer's encryption application and support files. > >With the help of a more experienced DOS programmer, an application was >built that provided adequate protection that would increase the time >required to extract a computer's signature (even if one knew exactly how >to do it), that it was impractical to attempt. > >I am now porting the application to the Mac with the intent to sell it to >a private contractor that is developing RISC-based computers for >specialized use in the government. I have been assured that a PPC native >application will run on the computers, and was encouraged to develop the >application. Mostly what I need to know is how long it would take a >super-human cracker to obtain a signature and how she would do it. If I >can increase the expected time to 96+ hours, I'm in business (I always >assume half of my best guess - 48 hours is the required specification). > >I am developing the code with the help of an excellent Mac programmer. >The problem is, that neither of us can crack it at all, although we know >that is theoretically possible. He lacks sufficient crypto understanding, >and I lack sufficient computer knowledge. Working together we make little >progress, and truthfully don't have enough time to develop and crack at >the same time. I will not be comfortable with the final product until >someone cracks it and I have a sound understanding of the weaknesses that >I have not considered. > >Finally, MacPGP is a GREAT program. I didn't mean to belittle any of the >PGP programs. PGP carries much more protection than necessary for it's >intended and practical uses. Granted, it could use a new interface, but >it is certainly functional and not lacking in features. Initially, I >considered releasing a public version of my application in response to the >need for a more Mac-like encryption program. There is no reason for the >average Mac user to switch from PGP to my program. It lacks (and will >always lack) the features of MacPGP, and although it is more secure than >PGP the user must accept some increased inconvenience to realize the bulk >of the added security. For most users, this is adding overkill to >overkill. > >I extend my apologies for posting this huge message off topic, but I felt >I had grossly misrepresented my request. I feared the influx of e-mail >tomorrow morning if I didn't clarify. I appreciate all those that >extended advice. I will follow up on much of it, and I thank those who >replied. > > >Brent A. Carey -- Paul Robichaux LJL Enterprises, Inc. paul(a)ljl.com Be a cryptography user. Ask me how.

1 0

Re: Re:phoneco vs X-phone
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

Don't forget opportunity costs. With the money it spent to put in the fiber optics, the phone company could have made some loans and gotten interest back. -Allen

1 0

Intel to rule the basic crypto engine market?
by Bruce M. 17 Dec '03

17 Dec '03

InfoWorld, August 19, 1996, p1 By Luc Hatlestad & Tom Quinlan ------------------------------ Looking to bring a standard infrastructure to hardware- and software-based encryption offerings, Intel Corp. has started developing a Common Data Security Architecture (CDSA) designed to integrate security software, operating systems, and third party applications. [...] ------------------------------ http://www.infoworld.com/cgi-bin/displayArchives.pl?960816.encryption.htm ________________________________ [ Bruce M. - Feist Systems, Inc. ] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "Official estimates show that more than 120 countries have or are developing [information warfare] capabilities." -GAO/AIMD-96-84 So, what is your excuse now?

2 1