December 2003 - cypherpunks-legacy

This list is a joke
by Dave Temple 17 Dec '03

17 Dec '03

When I subscribed to this list, I thought it would have decent communication on worthwhile topics. I've come to realize though that 75% of the messages I receive are from people whining like 4 year olds. I am making a huge assumption in saying that most of the people on this list are adults. It is time to start acting like it. Please take my name off of this list.

6 5

The Impact of Cybercommunications on Traditional Financial Services
by Joseph M. Reagle Jr. 17 Dec '03

17 Dec '03

http://www.ctr.columbia.edu/citi/cybercom.html http://www.ctr.columbia.edu/citi/cybcompap/ravi.htm Abstract: This paper presents a framework that provides a conceptual understanding of electronic commerce-based financial services. The paper then discusses some of the research issues that need to be addressed in this emerging area. Systematic research o n online financial services is virtually non-existent. Most of the early work consists of anecdotal evidence from individual companies, usually in the form of trade journal articles which have no empirical basis. Clearly there is a need for industry-acade mia collaboration to understand the online financial services area better. There is also a need to develop methods and tools for measuring the effectiveness of these services. Traditional effectiveness measuring methods will be of limited use in cyberspac e as banks enter an era in which financial products are treated as information commodities and banks are in competition with non-banks to serve customers with the best bundle of information _______________________ Regards, An oral contract isn't worth the paper it's written on. -? 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

Sen. Leahy's Statement on Clipper 3.1.1
by jseiger＠cdt.org 17 Dec '03

17 Dec '03

STATEMENT OF SENATOR LEAHY ON THE ADMINISTRATION'S NEW ENCRYPTION INITIATIVE October 1, 1996 The timing of the Administration's announcement on encryption, within hours of the Congress' likely adjournment, is unfortunate. The Administration needs to work with Congress to develop a consensus on a national encryption policy that takes account of the privacy, law enforcement and competitiveness concerns of our Nation's citizens and businesses. Taking unilateral steps will not resolve this issue, but instead could delay building the consensus we so urgently need. This issue simply cannot by resolved by Executive fiat. While technology should not dictate policy, particularly when our public safety and national security interests are at issue, any policy we adopt must protect our privacy. As the Administration and industry rush to find an alternative to unbreakable encryption, they should take heed that any solution which fails to protect the Fourth Amendment and privacy rights of our citizens will be unacceptable. That is why, with bipartisan support, Senator Burns and I introduced legislation in March that set out privacy safeguards to protect the decoding keys to encrypted communications and stringent legal procedures for law enforcement agencies to get access to those keys. In this plan, the Administration is directing the resources of our high-tech industry to develop breakable, rather than unbreakable, encryption. But no one is yet clear about who will be legally allowed to break into encrypted messages, and under what circumstances. These are questions that have to be answered not only with our own government but also with foreign governments. The weakest link in a key recovery system may be the country with the weakest privacy protections. Internet users, who can send messages around the globe seamlessly, do not want the privacy of their encrypted communications to be at the mercy of a country that ignores the Fourth Amendment principles we enjoy here. These are significant privacy and security concerns not answered by the Administration's plan. Even without reading the fine print, the general outline of the Administration's plan smacks of the government trying to control the marketplace for high-tech products. Only those companies that agree to turn over their business plans to the government and show that they are developing key recovery systems, will be rewarded with permission to sell abroad products with DES encryption, which is the global encryption standard. Conditioning foreign sales of products with DES on development of key recovery systems puts enormous pressure on our computer industry to move forward with key recovery, whether their customers want it or not. Internet users themselves -- not the FBI, not the NSA, not any government regulator -- should decide what encryption method best serves their needs. Then the marketplace will be able to respond. The Administration is putting the proverbial cart before the horse, by putting law enforcement interests ahead of every one elses. But that is not the only catch in the Administration's plan. Permission to export DES will end in two years. Allowing American companies to sell DES overseas is a step long overdue. Given the fact that a Japanese company is already selling "triple DES", one might say this step is too little, too late. Threatening to pull the plug on DES in two years, when this genie is already out of the bottle, does not promote our high-tech industries overseas. Does this mean that U.S. companies selling sophisticated computer systems with DES encryption overseas must warn their customers that the supply may end in two years? Customers both here and abroad want stable suppliers, not those jerked around by their government. The most effective way to protect the privacy and security of our on-line communications is to use encryption technology. Every American should be concerned about our country's policy on encryption since the resolution of this debate will affect privacy, jobs and the competitiveness of our high-tech industries.

1 0

White House Statement on Clipper 3.11
by abd＠cdt.org 17 Dec '03

17 Dec '03

Included below for your viewing pleasure is the Administration's latest encryption proposal, released at a White House briefing this afternoon. This statement, and more information including CDT's forthcoming analysis of the proposal, are available at: http://www.cdt.org/crypto http://www.crypto.com Alan Davidson, Staff Counsel 202.637.9800 (v) Center for Democracy and Technology 202.637.0968 (f) 1634 Eye St. NW, Suite 1100 <abd(a)cdt.org> Washington, DC 20006 PGP key via finger ---------------- THE WHITE HOUSE Office of the Vice President FOR IMMEDIATE RELEASE CONTACT: 456-7035 TUESDAY, October 1, 1996 STATEMENT OF THE VICE PRESIDENT President Clinton and I are committed to promoting the growth of electronic commerce and robust, secure communications worldwide while protecting the public safety and national security. To that end, this Administration is consulting with Congress, the information technology industry, state and local law enforcement officials, and foreign governments on a major initiative to liberalize export controls for commercial encryption products. The Administration's initiative will make it easier for Americans to use stronger encryption products -- whether at home or abroad -- to protect their privacy, intellectual property and other valuable information. It will support the growth of electronic commerce, increase the security of the global information, and sustain the economic competitiveness of U.S. encryption product manufacturers during the transition to a key management infrastructure. Under this initiative, the export of 56-bit key length encryption products will be permitted under a general license after one-time review, and contingent upon industry commitments to build and market future products that support key recovery. This policy will apply to hardware and software products. The relaxation of controls will last up to two years. The Administration's initiative recognizes that an industry-led technology strategy will expedite market acceptance of key recovery, and that the ultimate solution must be market-driven. Exporters of 56-bit DES or equivalent encryption products would make commitments to develop and sell products that support the key recovery system that I announced in July. That vision presumes that a trusted party (in some cases internal to the user's organization) would recover the user's confidentiality key for the user or for law enforcement officials acting under proper authority. Access to keys would be provided in accordance with destination country policies and bilateral understandings. No key length limits or algorithm restrictions will apply to exported key recovery products. Domestic use of key recovery will be voluntary, and any American will remain free to use any encryption system domestically. The temporary relaxation of controls is one part of a broader encryption policy initiative designed to promote electronic information security and public safety. For export control purposes, commercial encryption products will no longer be treated as munitions. After consultation with Congress, jurisdiction for commercial encryption controls will be transferred from the State Department to the Commerce Department. The Administration also will seek legislation to facilitate commercial key recovery, including providing penalties for improper release of keys, and protecting key recovery agents against liability when they properly release a key. As I announced in July, the Administration will continue to expand the purchase of key recovery products for U.S. government use, promote key recovery arrangements in bilateral and multilateral discussions, develop federal cryptographic and key recovery standards, and stimulate the development of innovative key recovery products and services. Under the relaxation, six-month general export licenses will be issued after one-time review, contingent on commitments from exporters to explicit benchmarks and milestones for developing and incorporating key recovery features into their products and services, and for building the supporting infrastructure internationally. Initial approval will be contingent on firms providing a plan for implementing key recovery. The plan will explain in detail the steps the applicant will take to develop, produce, distribute, and/or market encryption products with key recovery features. The specific commitments will depend on the applicant's line of business. The government will renew the licenses for additional six-month periods if milestones are met. Two years from now, the export of 56-bit products that do not support key recovery will no longer be permitted. Currently exportable 40-bit mass market software products will continue to be exportable. We will continue to support financial institutions in their efforts to assure the recovery of encrypted financial information. Longer key lengths will continue to be approved for products dedicated to the support of financial applications. The Administration will use a formal mechanism to provide industry, users, state and local law enforcement, and other private sector representatives with the opportunity to advise on the future of key recovery. Topics will include: evaluating the developing global key recovery architecture assessing lessons-learned from key recovery implementation advising on technical confidence issues vis-a-vis access to and release of keys addressing interoperability and standards issues identifying other technical, policy, and program issues for governmental action. The Administration's initiative is broadly consistent with the recent recommendations of the National Research Council. It also addresses many of the objectives of pending Congressional legislation.

1 0

Re: How might new GAK be enforced?
by Rick Smith 17 Dec '03

17 Dec '03

Tim May asks: : Any other ideas on how the government plans to enforce GAK, to make GAK the : overwhelmingly-preferred solution? The problem seems somewhat analogous to the software copy protection problem and maybe the enfocement will be similar: make "examples" of a few high profile offenders who are exchanging blatantly un-GAKed traffic with foreigners. This assumes they fine tune the law to make such behavior illegal without having to prove you yourself exported the stuff to them. Wonder what the Supremes will say to that. But that's not the end of the story. If there is lots of GAK encrypted traffic flowing about, then encrypted traffic in general is no longer noteworthy. So as long as your traffic looks like GAK, you won't be hassled until they try to read your traffic. So it's possible that products will appear that use pseudo-GAK protocols -- they look just like their GAKed cousins but the GAK fields contain plausiable garbage instead of keys. It could even turn out to be a vendor "quality control" thing -- oops, the GAK was supposed to work but... You couldn't do that with Clipper (except via Matt Blaze's brute forcing of the LEAF checksum) because the crypto wouldn't decrypt a packet with an invalid LEAF checksum. Since it was a sealed hardware module, implementers had no choice but to play by those rules. There's no such enforcable limitation on commercial software implementations. Rick.

1 0

new mailing list: solving spam problem
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

a new list dedicated to trying to solve the problem of spam just popped up, and may be of interest to some here-- ------- Forwarded Message Date: Mon, 30 Sep 1996 16:01:08 -0400 (EDT) From: Chris Rapier <rapier(a)psc.edu> To: ietf(a)IETF.CNRI.Reston.VA.US Subject: Anti-Spam BOF Mail List I've decided to take some initiative and set up a real mailing list for the discussion on spamming. I would like to see us take some sort of action at the next IETF and maybe get some rough ideas about what is and/or isn't possible in dealing with this problem. If you would like to join the mailing list send mail to majordomo(a)psc.edu with subscribe spam-list [prefered address] in the body. If you have any problems subscribing let me know. Also, this mailing list superceeds the one I set up and announced around an hour ago. Anyone who has alrteady sent requests to that mailing list will be added to this new one. Chris Rapier Senior Sysadmin/Cabin Boy 2nd Class Pittsburgh Supercomputing Center MI 230B ------- End of Forwarded Message

2 2

White House crypto proposal -- too little, too late
by Declan McCullagh 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Tue, 1 Oct 1996 14:56:21 -0700 (PDT) From: Declan McCullagh <declan(a)well.com> To: fight-censorship(a)vorlon.mit.edu Subject: White House crypto proposal -- too little, too late I just got back from the White House, where Gore's office held a roundtable plugging the administration's long-awaited and already widely-derided Return of Clipper proposal. Gore announced that jurisdiction over crypto exports would move to the Commerce Dept; that the export embargo on 56-bit DES would be lifted in part for two years only; that to be approved for export firms must submit a detailed proposal describing how they will move towards key escrow; that the new regulations would go into effect on January 1. The true problem with this plan is that 56-bit DES is woefully inadequate. But much of the media coverage I've read of the plan doesn't even mention that. Take Elizabeth Corcoran's article, which ran above the fold on the front page in today's Washington Post. (It's what almost certainly prompted Gore's office to move the announcement to today rather than hold it later this week.) The thrust of the article is that the administration's new proposal balances the needs of privacy, business, and law enforcement. But it doesn't. The Feds, foreign governments, and determined attackers can crack anything encrypted with 56-bit DES -- the strongest crypto that can be exported under the plan. This vital fact appears nowhere in the Post article. That's why Bruce Schneier, author of Applied Cryptography, recommends against using DES in favor of a more secure algorithm. According to Schneier: "A brute-force DES-cracking machine [designed by Michael Wiener] that can find a key in an average of 3.5 hours cost only $1 million in 1993." More recently, in January 1996 an ad hoc group of renowned cryptographers including Matt Blaze, Whitfield Diffie, Ronald Rivest and Schneier, released a report going even further. They said: "To provide adequate protection against the most serious threats - well-funded commercial enterprises or government intelligence agencies - keys used to protect data today should be at least 75 bits long. To protect information adequately for the next 20 years in the face of expected advances in computing power, keys in newly-deployed systems should be at least 90 bits long." What's even more disturbing is what the administration might do next. After the roundtable broke up, I chatted with Michael Vadis, one of the assistant deputy attorneys general who oversees national security issues. He said an international consensus is forming that terrorists can use crypto; therefore crypto must be controlled. The U.S. is certainly pushing this line at the OECD talks. "But it just takes one country to decide to export strong crypto," I said. "You're missing something," said Vadis. "What?" I asked. "Unless you're talking about import restrictions." "Exactly," he said. -Declan ******* Some background: Linkname: Brock Meeks on White House plan -- 6 Sep 96 Filename: http://www.muckraker.com/muckraker/96/36/index4a.html ******** http://www.washingtonpost.com/wp-srv/WPlate/1996-10/01/041L-100196-idx.html U.S. TO EASE ENCRYPTION RESTRICTIONS Privacy Advocates Wary of Proposal For Software Exports By Elizabeth Corcoran Washington Post Staff Writer Tuesday, October 1 1996; Page A01 The Washington Post The Clinton administration is cutting off an emotional four-year-old debate with the computer industry over the export of information-scrambling technology with a plan that it says will help U.S. companies boost sales overseas and still allow law enforcement agencies to unscramble messages, officials said yesterday. President Clinton has decided to sign an executive order that changes the rules restricting the overseas sale of the technology, the officials said. Although the full details of the plan had yet to be revealed, privacy advocates and some industry executives contended that it would be difficult to put into practice. Under current rules, companies can sell only relatively easy-to-crack scrambling technology. Under the plan, they would get permission to export somewhat more sophisticated versions of the software and hardware, which prevents eavesdroppers from looking at information. The issue has caused enormous friction between the government and computer industry and privacy groups, which contend that keeping any restrictions in place will harm the protection of personal information everywhere and slow the development of on-line commerce, which relies on keeping credit card numbers and other sensitive information secure. The administration counters that it has come a long way in meeting such objections. However, last night some companies and privacy advocates were still worried that the constraints will leave U.S. companies at a disadvantage abroad and will not ensure that individuals will be able to protect their communications. The government's plan preserves what has been its unnegotiable cornerstone since the debate began in the early day of the Clinton administration -- that law enforcement officials must have the means for peeking at encrypted information when they are properly equipped with court authorization. Earlier versions of the plan tightly limited what kinds of technology could be sold abroad. They also called for makers of encryption technology to deposit "keys" with approved third parties so that law enforcement authorities could decode material. The new plan doesn't specify who would have the keys. Last night, several companies, led by International Business Machines Corp., said they have a technical plan that they believe could comply with the new rules on keys. [...] Industry officials say they ultimately want to be able to use the most sophisticated encryption technology available. "It's really critical to doing business around the world," said an IBM source. "But governments exist. It's a balancing act . . . to satisfy the needs of the governments and make sure that markets and individuals trust the integrity of what's being sent over the networks." [...]

8 7

Re: Export laws don't just affect crypto
by jim bell 17 Dec '03

17 Dec '03

At 12:32 PM 10/1/96 -0400, Perry E. Metzger wrote: > >Lucky Green writes: >> > Umm, so are you violating ITAR if you *use* these GPS-guided missiles >> >> No you aren't. A little known provision in the ITAR excempts exports >> by missile. Seriously. > >Well, not quite -- it exempts exports by space launch, but I think >thats intended for things like satelite launchings and not for things >like missile attacks against other countries... If ITAR exempts exports by missile, does that mean that we merely have to make a model rocket, put a floppy containing PGP in the payload compartment, and shoot the thing over the wall into Mexico, or into Canada? Jim Bell jimbell(a)pacifier.com

1 0

[SPAM] Timmy May has no life
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

I suppose one of the reasons why Americans are so stupid is that so many of them are of English origin. How does one donate to the IRA anyway? >Comments: Authenticated sender is <paul(a)fatmans.demon.co.uk> >From: paul(a)fatmans.demon.co.uk >To: "Dr.Dimitri Vulis KOTM" <dlv(a)bwalk.dm.com> >Date: Mon, 30 Sep 1996 17:40:49 +0000 >Mime-Version: 1.0 >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: 7BIT >Subject: Re: [SPAM] More "fuckhead" fan mail from Timmy "peteur" May >Priority: normal >X-Mailer: Pegasus Mail for Windows (v2.31) >Message-Id: <844193577.12916.0(a)fatmans.demon.co.uk> > > >> berserk >> Timmy May has gone . Has he been eating speed? >> bananas > >What? speak English motherfucker. > >> >> What has Timmy been smoking? > >I assume you are referring to me here, my name is Paul Bradley and >you can go fuck a kokonut dude. > >> >> ]From paul(a)fatmans.demon.co.uk Sun Sep 29 19:03:40 1996 >> >> ]Received: by bwalk.dm.com (1.65/waf) >> >> ] via UUCP; Sun, 29 Sep 96 19:14:06 EDT >> >> ] for dlv >> >> ]Received: from disperse.demon.co.uk by uu.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; >> >> ] id AA25790 for dlv(a)bwalk.dm.com; Sun, 29 Sep 96 19:03:40 -0400 >> >> ]Received: from post.demon.co.uk ([(null)]) by relay-2.mail.demon.net id ac16129; >> >> ] 29 Sep 96 15:59 BST >> >> ]Received: from fatmans.demon.co.uk ([158.152.120.223]) by relay-3.mail.demon.net >> >> ] id aa09441; 29 Sep 96 15:54 BST >> >> ]Received: from fatmans.demon.co.uk by fatmans.demon.co.uk with SMTP >> >> ] id AA843903697 ; Sat, 28 Sep 96 09:41:37 +0000 >> >> ]Comments: Authenticated sender is <paul(a)fatmans.demon.co.uk> >> >> ]From: paul(a)fatmans.demon.co.uk > >As you can see my sending is authenticated and the reply path is to >my host (fatmans.demon.co.uk) the message has passed through >post.demon.co.uk/disperse.demon.co.uk and on to psi.net, Tim May is >at got.net. > >> >> ]I am not Tim May, Check out the return path if you don`t believe me, >> >> ]if you still don`t here`s my PGP public key signed by the EFF, they >> >> ]don`t sign keys here and there without checking ID`s... > >>Fuckhead. > >Fraid not dude, this thread is getting distinctly boring, cut the >shit, if you have something to say say it, don`t keep spewing shit >without warning, but really it`s only to be expected from you. > > > > Datacomms Technologies web authoring and data security > Paul Bradley, Paul(a)fatmans.demon.co.uk > Paul(a)crypto.uk.eu.org, Paul(a)cryptography.uk.eu.org > Http://www.cryptography.home.ml.org/ > Email for PGP public key, ID: 5BBFAEB1 > "Don`t forget to mount a scratch monkey"

1 0

Can we kill single DES?
by Peter Trei 17 Dec '03

17 Dec '03

Since it looks like the US government will be allowing the export of 56 bit espionage-enabled software, it's time to kill single DES. As some of you will recall, a while back I wondered aloud about the feasibility of brute-forcing DES on general purpose machines, ala the RC4-40 crack last year. Unlike many cypherpunks, I actually write code (:-). I took Phil Karn's DES386 as a starting point, and modified it to run effiiciently on the Pentium. The code I've written will run 14 round DES (all that is required for a key test app) at 254,000 crypts/sec on a 90 MHz Pentium. Allow about 10% overhead for key scheduling (there are some tricks to speed this up), and we're still at about 250,000 keys/sec on a 100MHz Pentium (I'm using a nominal 100 MHz Pentium as my 'unit' of cpu power). On a Pentium, it runs entirely in the L1 cache. The code will also run on a 486, but at less than half the number of crypts/sec for the same clock speed. On this type of processor, it would still take 9133 years to exhaust a 56 bit key space. On the other hand, on 20,000 processors of this power it would take less than 6 months. If the target is encrypted in a chaining mode with an unknown 8 byte IV, the time more than doubles. Clearly, this goes far beyond the number of cpus available to the members of this list (though well within the power of most governments and many corporations) The best idea I've heard for recruiting this many cpu cycles is to create a screen saver which does DES-cracking while machines are idle. Another incentive is to offer a cash prize to the person(s) who find the key. Yes, I KNOW that a hardware based cracker is a LOT more efficient, but between the up-front cost and the difficulty of design and production, it's less likely to get done. (Still if someone wants to buy me a nice FPGA board, I'll see what I can do). If you're interested in volunteering machines to do a key search, please read to the end. Questions for general discussion: 1. Is this a good idea? What will happen if DES becomes perceived as insecure? 2. What is the probability of success required to make it worth doing? 3. What would be the consequences of failure? 4. What other platforms than NT/Win95/Pentium should be considered? I could write a Unix demon version, but unless it's tailored for the cpu, a lot of efficency is lost (The aggregate number of idle cycles available for testing is the crucial number). 5. What's a good target? Ideally, we need a plaintext/ciphertext pair, encrypted in Single DES ECB mode. Preferably from a commercially available program, in which a single key is used for a great deal of traffic over a long period. I would strongly prefer, however, that the target key be a *test* key - I don't want to compromise anyone's actual security. We need a target which is both convincing and realistic. 6. What other incentives can be used to recruit machines? ------------------------------ If you're interested in volunteering cycles: RESPOND ONLY TO ME (trei(a)process.com) NOT TO THE LIST. The last thing we need is a hundred 'I'll help' messages on the list. Assume that the program will be a Win95/NT screen saver or Unix deamon. Think about how many machines you could get it to run on (maybe you can talk other people into installing it as a screen saver or background task) I have not written the screen saver yet. I will not do so unless it looks like we'lll get enough machines, so nothing is likely to happen for a couple of months at least. I need to estimate how many cpu cycles will be available: Calculate: Number of Pentiums * Hours available/week * MHz + (Number of 486's * Hours available/week * MHz * 0.30) For, Alphas, MIPS, Motorola, PowerPC etc, running UN*X, MAC, etc, just report how many cpus, their speed, and OS - I'll need help to get versions for other platfoms. 64 bit processors like the Alpha can run this stuff *fast*. Send the aggregate numbers to me. I'll also need to know how many machines are directly on the Internet and could thus query a key-space server, and how many would need some other mechanism to get keyspace and report results. If you're volunteering machines which are outside of the US/Canada, please note the fact: ITAR may be an issue here. I'll summarize to the list. Peter Trei trei(a)process.com

4 5