December 2003 - cypherpunks-legacy

None
by Anonymous 17 Dec '03

17 Dec '03

On terrorists, one of the Four Horsemen. IS THE ASSAULT ON NATIVE INTELLIGENCE & GOOD WILL WE CALL THE EVENING NEWS ANYTHING OTHER THAN AN ACT OF TERRIORISM? What was the Gulf War but terrorism wearing the death mask of order?-- One big car bomb it was the guys who drove it are dying now one by one--ignored! Is acid rain a form of terriorism? (Think for yourself.) Is GATT or NAFTA anything but a pact among brigands--the World Bank, the IMP their backup men? How long before they fight over the spoils? Who'll do the fighting for them?"

1 0

Canadian crypto export/re-export rules
by Steve Schear 17 Dec '03

17 Dec '03

Can anyone point me to a site with accurate and complete information? --Steve

1 0

Statists trying to outlaw anonymity and privacy
by ichudov＠Algebra.COM 17 Dec '03

17 Dec '03

Dear Friends, As many of you no doubt know, a new moderated group, comp.org.cauce, has been proposed. One of the main goals of moderators is to prevent users of one-way anonymous remailers and those who munge (alter) their addresses to avoid being spammed, from posting to the group. Their proposal would force users to reveal their Internet identities and expose them to spam. The proponents hope, apparently, that the more spam people get, the more will they support CAUCE's statist lobbying for more government regulations. During the discussion they have shown complete disregard and ignored all requests from users who attempted to help them accommodate anonymous posting. To get more YES votes, they removed the most controversial provisions from the charter, while IN THE SAME DAY promising that these provisions will still be enforced. As someone who defends privacy and anonymity on the Internet, I ask you to vote on this important matter. I will vote NO on this newsgroup. Feel free to repost this message to any fora you deem appropriate. To find the Call For Votes, go to news.groups newsgroup, and find article titled "CFV: comp.org.cauce moderated". You will find the charter and the instructions on how to vote. Thank you for your attention. - Igor.

3 2

RSADSI open RC2 encryption algorithm
by Nobuki Nakatuji 17 Dec '03

17 Dec '03

RSADSI open RC2 encryption algorithm. http://www.imc.org/draft-rivest-rc2desc ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

proposal: commercial data recovery
by Adam Back 17 Dec '03

17 Dec '03

If we take the design goal of designing a commercial data recovery system which is not GAK compliant, we can most succinctly state this design goal as the task of ensuring that: - at no point will any data transferred over communications links be accessible to anyone other than the sender and recipient with out also obtaining data on the recipient and/or senders disks I think we can distill the design principles required to meet the design goal of a non-GAK compliant Corporate Data Recovery (CDR) down to ensuring that: 1. no keys used to secure communications in any part of the system are a-priori escrowed with third parties 2. second crypto recipients on encrypted communications are not used to allow access to third parties who are not messaging recipients manually selected by the sender 3. communications should be encrypted to the minimum number of recipients (typically one), and those keys should have as short a life time as is practically possible Included in 2) is the principle of not re-transmitting over communication channels keys or data re-encrypted to third parties after receipt -- that is just structuring -- and violates design principle 2. With these three principles you still have lots of flexibility because you can escrow storage keys, do secret splitting of storage keys, and store keys encrypted to second storage accessors on the local disk for stored data recovery purposes. As an additional bonus, principle 3 adds extra security against attackers gaining access to encrypted traffic after the fact -- the recipient no longer has the key -- this is a form of forward secrecy. Systems designed to the CDR design principles are of significantly less use to GAKkers than PGP Inc's GAK compliant Commercial Message Recovery (CMR) design. The CDR design significantly hinders the take up of GAK if widely deployed. Design principle 3 -- forward secrecy -- is inherently hostile to GAKkers, and is the strongest statement you can make against GAK: you are purposelly _destroying_ communications keys at the earliest possible moment to ensure that GAKkers can not obtain the keys by legal and extra-legal coercion, black mail, and rubber hose cryptanalysis. The whole system translates into the Feds having to come and physically take your disk to obtain information about you, which is much better than GACK, and not what the GAKkers are interested in at this point. The GAKkers would like to install themselves, and coerce companies into installing for them (via GAKker/USG/NSA/NIST organised efforts such as the 56 bit export permit for companies installing key escrow; and efforts such as the Key Recovery Parners Alliance (KRAP)). I fear that PGP Inc's CMR proposal inadvertently meets most of the NIST/NSA specified KRAP requirements. What the GACKers want is systems where they can perform routine key word scanning and fishing expeditions into your communications from the comfort of their offices, without your knowledge. This is push button Orwellian government snooping. Within the constraints imposed by the CDR design principles, there is plenty enough flexibility to acheive the commercial data recovery functionality to similarly weak levels of enforcability as achieved by the CMR design. Weak levels of enforceability are appropriate because there are other exceedingly easy bypass routes: super-encryption, and walking out of the office with a DAT tape. I would like to organise a collaborative effort to write a white paper discussing how to implement various functionalities using the CDR design principle. Then I would like to see discussion of which set of these functionalities which best acheive the user requirement for company data recovery. Lastly I would like to see a collaborative development effort to provide a example implementation of a CDR system which can be used as a discussion point for the OpenPGP standardisation process. I suppose the best place to discuss this process is the IETF forum for discussion of the OpenPGP standard, the OpenPGP mailing list (subscribe by sending message body "subscribe ietf-open-pgp" to "majordomo(a)imc.org"). I have already had people express in email to me their interest in doing this. Those people can speak up if they want to. Technical input is sought from people opposed to GAK compliant software, and from PGP Inc, and others defending PGP's GAK compliant CMR proposal. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

12 23

One Nation on-line working group
by Global Web Builders 17 Dec '03

17 Dec '03

If you did not request to be put on the One Nation mailing list please respond with "REMOVE" in the Subject line while leaving the message (below) intact. No email is sent without a request having first been received. GWB, Scott Balson, One Nation web site operator. ____________________________________________________________________________ __________ Dear One Nation supporters in NSW, Pauline Hanson's One Nation is now establishing an on-line working group of One Nation members. Conditions of involvement in this working group are: - being a bona-fide paid up member of One Nation. - the desire to be proactive in undertaking tasks and assisting One Nation where you can. This working group will play a very important support role for the party as we approach the next federal election. We do not want to say too much more until working group members have been selected. If you would like to enquire about joining this group please complete the information below: ______________________________________________________ Your Full Names: Your Full Address: Your Contact Phone no: Your Fax no: Your One Nation Membership number: One Nation branch (at which you are a member): _____________________________________________________ Thank you in anticipation of your valued support in this important area. Pauline Hanson

1 0

commercial data recovery
by Zooko Journeyman 17 Dec '03

17 Dec '03

[Note-- I am not subscribed to ietf-open-pgp at this time. My apologies if this submission from a non-subscriber is unwanted. I will be brief. --Zooko] Adam, I applaud your effort to steer discourse toward productive work re: GAK, CMR, CDR. I haven't thought about your idea enough to have a definite opinion, but at first blush it seems a promising strategy to design high-security and forward-secrecy for communication but recovery/sharing features for stored data. I wonder if it is too much early-days to start talking about advanced protocols e.g. secret-splitting in IETF-Open-PGP? Probably so. Better just punch out a standard with current tech... Hm. What about the idea of storing your data remotely (for cost-efficiency, safety, etc.) using encryption to maintain your privacy? In that case, the distinction between comms and storage keys is blurred. A company may choose to e.g. store all long-term data at Zooko's Backup Server, encrypted in such a way that some combination of corporate keys (controlled by individual employees and/or departments) is necessary to decrypt each package of data. This would open the door, as you fear, for a government to mandate that _its_ key be added to each set, with authority to open any package even without the cooperation of any corporate keys. I'm not sure how to weigh the relative risks and benefits. I (ever so humbly) think that Zooko's Backup Server would be a great value for businesses, and that part of that value would be the ability to make data unlockable by various keys, both for administrative/internal security purposes and for robustness against accidents and saboteurs. Zooko's Backup Server can be physically located in a country free of such intrusive organizations, but of course it is the intrusive organizations of the _client's_ country that become important with that kind of protocol... Regards, Zooko P.S. There is already a company whose name I have forgotten that offers hard-drive backups over TCP/IP. They use some encryption but I don't know how strong.

10 18

ipnat problems continued
by Matthew Patton 17 Dec '03

17 Dec '03

I've tried varios purmutations of the map rules to no positive effect. map ppp0 192.168.1.0/24 -> 206.142.xx.yy/32 portmap tcp/udp 10000:20000 repeat except substitute ^^^^^^^^^^^^^ with 0.0.0.0 or ppp0. Neither works. I ran tcpdump on ppp0 on the gateway and sure enough, the box is sending down the modem link 192.168.1.10 (the particular LAN host trying to initiate an outside connection) as the source IP. Now if everything were correct shouldn't it be the IP addr of the local end of the PPP link as hosted on the gateway box? (ie 206.142.xx.yy) ipnat -l has never once shown any indication of active connections. Either nat is seriosly not working under stock v2.1 (anyone prove it does work?) or there are some undocumented and not exactly obvios dependencies with regard to kernel options. Can someone please mail me a kernel config that is guarenteed to work on a stock v2.1 box for i386 architecture? BTW, how come kernal option IPNAT isn't documented ANYWHERE? It's not even in the ALL file. -------- Windows95: noun. 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand 1 bit of competition. (author unknown)

2 1

Why CMR is bad civic hygene;the short version
by Bruce Schneier 17 Dec '03

17 Dec '03

The FBI has publically stated that they want to ban unescrowed encryption. A couple of years ago, people like Brock Meeks and EPIC predicted this; they were universially regarded as alarmists. The problem with corporate key escrow is that it puts an infrastructure in place that can very easily, with a simple switch of public policy, turn into GAK. Diffie has said that the FBS's position is a strawman, and that some kind of voluntary system will be put in place as a compromise. Then, in a few years, eliminating the voluntary nature will be seen as "closing a loophole." Technological infrastructure moves very slowly. Political moods can move very quickly. If companies (like PGP) install a key escrow infrastructure, it will take one well-timed disaster to convince Congress to pass a law putting the whole thing under government control. As Phil Zimmermann said many years ago (I have no idea where he stole it from): "It's poor civic hygene to install technologies that may someday facilitate a police state." Data recovery is essential for stored corporate data. This is a seperate problem than corporate key escrow. Communications keys (used for email) are fundamentally different than storage keys (used for files). Someone sent me email recently and told me that those keys are treated the same in PGP; I have trouble believing that this is true. And if everyone is bashing PGP Inc badly over this, it's because people expected more out of them. A company like TIS, who gets significant (I originally wrote "most of its," but I don't know if that's true anymore) funding from the NSA anyway, is expected to roll over for the Feds. PGP Inc was not. Bruce ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis,MN 55419 Fax: 612-823-1590 http://www.counterpane.com

1 0

PGP Key Escrow and Congress
by Bruce Schneier 17 Dec '03

17 Dec '03

The attached is from Barbara Simons of the U.S. ACM. Note item 4, where Congressional staffers point to PGP as an example of key escrow software being possible. To those of us fighing the government control of cryptography, this is not helpful. Bruce -------------------------------------------------------------------------- Date: Mon, 13 Oct 1997 13:27:03 PDT Reply-To: "Barbara Simons" <simons(a)VNET.IBM.COM> Sender: ACM US Public Policy Committee <USACM(a)ACM.ORG> From: "Barbara Simons" <simons(a)VNET.IBM.COM> Subject: Hill ... Blues To: USACM(a)ACM.ORG On Thursday and Friday of last week I met with Hill staffers of the following Congresspeople: Sen. Feinstein, Sen. Boxer, Rep. Eshoo, Rep. Campbell, and Sen. Kerrey. As you may have noticed, there was a Ca. theme to the group, with the exception of Nebraska's Kerrey, of S909 fame. Both Feinstein's and Boxer's staffer suggested that I speak with Kerrey's staff, which is how I ended up meeting with Christopher McLean, Kerrey's Legislative Counsel, and Lorenzo Goco, who is Special Assistant to the Vice Chairman of the Senate Select Committee on Intelligence. My discussion with them was very interesting and somewhat lively. I don't know whether or not they had noticed our letter in opposition to S909, but they at least appeared to be surprised when I said that we had written such a letter, a copy of which was given to each at the meeting. I had the strong impression that McLean and Goco had had a hand in the writing of S909. They certainly were well versed in the arguments. Here is some of what they said: 1. S909 impacts only the government, NOT universities that receive government funding for networks. This is not our interpretation of the bill, and I'd be interested in hearing from some of the lawyers who are on USACM as to whether or not they agree with McLean and Goco. 2. If we are concerned about the well being of the computer industry in the U.S., we should be supporting S909, since the alternatives are either a more draconian bill or no bill at all, with the maintenance of the status quo export restrictions. They claim that Clinton will veto any bill that does not contain provisions that address some of law enforcement's concerns. 3. If we are concerned about inappropriate behavior vis-a-vis key escrow or recovery, we should be supporting S909, since it includes strong penalties for unlawfully revealing or obtaining others' keys. 4. The NSA states that key recovery is doable and will not jeopardize national security. And there is an existence proof for key recovery software in the new PGP release. 5. Yes, they would like to see widespread use of key recovery, but their idea is to encourage the development of encryption with key recovery by using the buying power of the government to cause widespread and inexpensive key recovery encryption to come into being. 6. They are simply doing what the NRC report recommended, namely "testing" key recovery on the government without imposing it on the citizenry. 7. Key recovery or key escrow are simply attempts at maintaining the status quo for law enforcement, who are now able to wiretap at will. Some of these are old arguments that we've been hearing for a while, but some are newer. In particular, points 4 and 6 are difficult to refute without getting into some technical details. Both points also undercut the argument that a key recovery infrastructure potentially weakens security. After all, the NSA thinks it's secure enough that it can be used by the government. Barbara

1 0