- cypherpunks-legacy - lists.cpunks.org

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

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

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

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

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

Australian Key Escrow Bill Before Parliament for VPNs
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

------- Forwarded Message Date: Tue, 14 Oct 1997 17:08:36 +1000 From: Paul Montgomery <monty(a)apnpc.com.au> Subject: [Oz-ISP] Interception law IS a threat to ISPs A couple of ISPs in messages under the "Interception" heading have pooh-poohed the new interception law that is going through government processes at the moment. FYI, the following PC Week Australia story shows that it's not something to be sneezed at, if you want to differentiate yourself by offering remote access or VPN services that are secured using encryption. As mentioned in the story, Telstra, OzEmail, Access One, Connect.com.au and Magna Data are only the largest of growing band of ISPs who are already constructing VPNs for business customers. It's going to take more than an a packet sniffer to decrypt secure messages going through your network. If you're preparing a VPN trial with something like Data Fellows' F-Secure VPN software, which doesn't allow for key recovery, then you're up the proverbial creek as regards your obligations under this new law. You'll have to keep an extra key for the Feds, ASIO, NCA etc, and only use cryptography software that includes key recovery. You'll also have to be involved in a lengthy approval process with the Attorney-General's department and the ACA, which is dangerously open-ended. The system will be that you have to submit your plans for new secure network products every year, and the law enforcement agencies have a set amount of time to protest that they can't access it. This process will add three months, at minimum IMHO, to the development of new services. And yes, INTIAA has been keeping an eye on it, but they've been getting the wrong information from the Department of Communication. I wouldn't say they've been lied to, but they've been given the wrong end of the stick. - -- START STORY [from PC Week Australia, October 17, pp 1/38] New Law Hurts Net Security Security forces want access to encrypted ISP traffic By Paul Montgomery [reproduction for commercial purposes not allowed etc etc] The Virtual Private Network (VPN) revolution in Australia is being undermined by new legislation from the Liberal government that would weaken security on communications passing through Internet service providers (ISPs). The Telecommunications Legislation Amendment Bill, which went to a second reading in the Senate last week, is aimed at giving government agencies such as the Federal Police, ASIO and the National Crime Authority access to data and voice trafficand ISPs will have to fund its implementation. The bill threatens ISPs ability to provide secure remote access and VPN services, by compelling them to include an extra cryptographic key for police, in a weakened version of encryption that is called key escrow. Any modifications needed to encryption technology would not only weaken security, but mean extra costs passed on to corporate customers. Senator Richard Alston, the Minister for Communications, the Information Economy and the Arts, said in a speech to the Senate that interception was an essential service and that Attorney-General Daryl Williams would be given the power to determine the specifics of the proposed laws effect. Senator Alston recently took over policy coordination for cryptography (see PC Week, October 3, page 12), but the decision on this bill was made back in March. The introduction of some new telecommunications services have been significantly delayed, with obvious adverse consequences for business and consumers, Alston said, which sources say is a reference to Telstras OnRamp ISDN service. Alston also hinted that the government was lobbying switch vendors, at an international level, to include interception capabilities in their equipment. Chris Cheah, assistant secretary of the networks policy branch at Senator Alstons department and one of the officials involved in drafting the bill, confirmed that the bill applied to ISP-encrypted VPN and remote access services. If [ISPs] are offering VPNs which have built-in encryption, and theyre saying to their customers that they will deliver in a secure form to a person at the other end, then they will have to provide decryption, Cheah said. He stressed, however, that there would be no requirement for an ISP to decrypt an end users own encryption. Telstra, OzEmail, Access One, Connect.com.au and Magna Data are already offering VPNs, expected to be a lucrative market for network outsourcing, but a central part of the technology is the security gained from scrambling messages with strong cryptography, using such products as F-Secure VPN from Data Fellows (see page 16). Danny Ng, business development manager for Internet and intranet at Bay Networks, said that because Internet access is not an inherently high-margin business, many ISPs were looking to differentiate themselves by offering outsourced remote access or VPN services. VPN technology is evolving very quickly, and one of the cornerstones to it is security, which usually means encryption, Ng said. For major carriers such as Telstra, the delivery point could be the local exchange closest to the agency wanting the interception, but it would most likely remain at the premises for smaller ISPs, according to Cheah. If ISPs want to get into serious carriage service provision, they will be subject to the same provisions as telcos. That means being able to provide interception capabilities, Cheah said. The bill also removes the burden of keeping up with Internet technology from police and security agencies by ordering ISPs to prepare annual reports on their plans for new crypto services. Luke Carruthers, secretary of ISP representative body INTIAA (Internet Industry Association of Australia), said that the impression he had from meetings with the government on the bill was that ISPs would not have to decode encrypted transmissions. INTIAA is meeting with the Australian Communications Authority and the government this week to work out the details of the legislation. Carruthers will argue the ISPs case. I would expect this issue to be taken up fairly strenuously by the people who it affects the most, he said. - -- END STORY - -- Paul Montgomery, Net journalist for PC Week, lives like a JavaBean. mailto:monty@apnpc.com.au Tel: +61-2-9936-8793 Fax: +61-2-9955-8871 ------- End of Forwarded Message

1 0

Security flaw in PGPverify of INN
by Lutz Donnerhacke 17 Dec '03

17 Dec '03

Hi, I was urged to send you the following information. I noticed CERT and tale itself. But tale claims that the problem is not a problem of pgpverify, it's a problem of some krauts trying to send checkgroups monthly using a bot. The checkgroups mentioned were send since a year. They do not include Date: and Message-ID: because these values were not predictable by the human signer and the bot does not know the passphrase to work with. In consequence there are checkgroups out there which can be resend at any time causing a lot of trouble, because the signature is still valid even if a new Message-ID: and Date: line are used. The obvious fix is to modify pgpverify to block such control messages. ftp://ftp.iks-jena.de/pub/mitarb/lutz/ contains the necessary fixes. HTH Content-Type: application/pgp-signature

1 0

Re: Security flaw in PGPverify of INN (fwd)
by Ray Arachelian 17 Dec '03

17 Dec '03

=====================================Kaos=Keraunos=Kybernetos============== .+.^.+.| Ray Arachelian |Prying open my 3rd eye. So good to see |./|\. ..\|/..|sunder(a)sundernet.com|you once again. I thought you were |/\|/\ <--*-->| ------------------ |hiding, and you thought that I had run |\/|\/ ../|\..| "A toast to Odin, |away chasing the tail of dogma. I opened|.\|/. .+.v.+.|God of screwdrivers"|my eye and there we were.... |..... ======================= http://www.sundernet.com ========================== ---------- Forwarded message ---------- Date: Tue, 14 Oct 1997 17:34:11 +0200 From: Peter Simons <simons(a)RHEIN.DE> To: BUGTRAQ(a)NETSPACE.ORG Subject: Re: Security flaw in PGPverify of INN -----BEGIN PGP SIGNED MESSAGE----- I am replying to the "security problem" report in pgpverify written by Lutz Donnerhacke, which has been delivered via several mailing lists, including BUGTRAQ and Best-Of-Security. Normally I'd simply ignore this article, but this is so breath-takingly ridiculous that I have to set a few facts straight. Lutz Donnerhacke <lutz(a)IKS-JENA.DE> wrote: > I was urged to send you the following information. I noticed CERT and tale > itself. But tale claims that the problem is not a problem of pgpverify, it's > a problem of some krauts trying to send checkgroups monthly using a bot. > > The checkgroups mentioned were send since a year. They do not include Date: > and Message-ID: because these values were not predictable by the human > signer and the bot does not know the passphrase to work with. > > In consequence there are checkgroups out there which can be resend at any > time causing a lot of trouble, because the signature is still valid even if > a new Message-ID: and Date: line are used. > > The obvious fix is to modify pgpverify to block such control messages. > ftp://ftp.iks-jena.de/pub/mitarb/lutz/ contains the necessary fixes. This is plain bullshit. pgpverify is working just fine and there's no security leak or malfunction in the script. The real story behind this 'report' is as follows: Lutz is the moderator for the german language de.* USENET hierarchy. One of his duties is to send out regular checkgroups and other control messages. What he did is that he didn't include the Message-Id and Date header into the signature of the control messages that he posted. He only signed headers like From and Subject. So he posted control messages with incomplete signatures for maybe a year, until this was first noticed and publicly addressed by Ralph Babel. The problem with these control messages is that anybody is able to re-post them with a new Message-Id and Date. Due to the correct PGP signature, most INNs will simply execute them, thus deleting all changes in the hierarchy since the checkgroups was posted originally. While this is not a major problem, it certainly is a problem, as all groups that have been created past a certain date can easily be removed, etc... When his mistake became public, he didn't stand up for it and created a new key to start posting correct control messages, rendering the old ones useless, he put the blame on Tale and his script instead. So please don't believe this "security flaw". pgpverify is working just fine and if the responsible person will use PGP correctly, there is no problem at all. -peter -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: latin1 iQCVAwUBNEORSw9HL1s0103BAQEgugP9FWJMNivNBqmJElzoQ6pXnwvS6QsbLjQG YrwHzvcYY3CAR7R446gr/WeuxW1JI1t9+yql8TNSvHeEXAX+qgz/ZMCjcjgjg0Pe j0BuVLBBfKuBoxGZDQybRybu3d5Xflqk07W9HjPP0tDtdkUcjndHr2J1Ea/J4zTd QgGNNUoZDFM= =brmw -----END PGP SIGNATURE-----

3 2

Magic money
by Eric Wilhem 17 Dec '03

17 Dec '03

Is the guy still around who wrote " Magic Money" and if so where can I communicate with him? Apparently his name is "Product Cypher". Thanks, Eric Wilhem

1 0