December 2003 - cypherpunks-legacy

Re: FW: FYI-WARNING (fwd) Zip300 Trojan Horse?
by Otto Matic 17 Dec '03

17 Dec '03

Is this for real? If not, forgive me for posting this to your list. >From:Matthew Hayton <mhayton(a)vt.edu> >Subject: FW: FYI-WARNING (fwd) >Sender: owner-sfraves(a)hyperreal.com >Precedence: bulk >>From: "Bayless, Marilyn J. Capt" <BAYLESMJ(a)CISF.AF.MIL> >>To: "hayton, todd" <mhayton> >>Subject: FW: FYI-WARNING (fwd) >>Date: Wed, 02 Oct 96 11:40:00 MDT >>Encoding: 63 TEXT >> >> >> >> ---------- >>From: Bailey, Craig E. Mr. >>To: Bosse, Roger H., Civ; Ferribee, George, Civ; Caracillo, Mike R. Mr.; >>Fleming, Kirk Mr.; Guthrie, Michael P. Mr.; Kounter, Mike J. Mr.; Allen, >>Scott C., Capt\DET1; Thomas, Christopher 2Lt; 'Kelch, William Mr.'; Einmo, >>Kent Maj; Myers, Gale Maj; 'Gribble, TSgt (SEIT)'; 'Manas, Capt (SEIT)'; >>SSSGp (All CISF Bldg Pers) >>Subject: FW: FYI-WARNING (fwd) >>Date: Wednesday, October 02, 1996 11:33AM >> >> >> >> ---------- >>From: Sanders, Timothy SrA >>Sent: Wednesday, October 02, 1996 9:00 AM >>To: Gebhardt, Dean MSgt; Potter, Rodney MSgt; Bailey, Craig E. Mr.; >>Guthrie, Michael P. Mr.; Armstrong, Harry SSgt; Drent, Shirley Ms DoD; >>McFadden-Garnier, Jacquelin MS; Slomski, John MSgt; Burgtorf, Christina >> SSgt; Brown, James TSgt; Malloy, Archie Mr DoD; Nelson, Andrew A1C; >>Lewis Benjamin SSgt; Scheer, Brian TSgt; Bundrick, Christopher SSgt; >>Mullens, Carolyn Ms. DoD; Wohr, Charles TSgt; Hohle, Duane Sgt; Mizell, >>David SrA; Morgan, Dwayne SSgt; Holland, Gregory SSgt; Deeney, James >> TSgt; Garn, John MSgt; Hilyard, John SrA; Sumner, Jennifer Amn; Dean, >>Laura TSgt.; Dozier, Larry SSgt; Estensen, Michael SSgt; Heckle, Megan >> Ms.; Imel, Michael SrA; Michniewicz, Mark MSgt; Schueckler, Michael J. >>A1C; Mantell, Patrick SrA; Beckwith, Ralph Mr DoD; Daniel, Shirley SSgt; >>Lopez, Steven MSgt; Dinsmore, Tina SrA; Sanders, Timothy SrA; Thompson, >>William TSgt; Burkett, Brian SrA; Richardson, Jackie MSgt; Shelton, Jay >> MSgt; Martinez, Jessie SrA; Ooley, Matt TSgt; Godfroy, Rainette Ms DoD; >>Herndon, Richard Mr. DoD; Timm, Roseangeli TSgt; Abernathy, Samuel MSgt; >>Greenwood, James SSgt; Young, Malcolm MSgt; Bookout, Bruce Capt; Stith, >>Carolyn SSgt; Feller, Dean SMSgt; Lemoine, David TSgt; Johnson, Fred >> SrA; Wilkinson, Heather Capt; Dias, John SSgt; Hewitt, James SrA; >>Bianchi, Kevin SrA; McDowell, Michael TSgt; Wilson, Steven Capt; >>Armstrong, Connie Ms DoD; Akin, Henry TSgt.; Murray, Mark SMSgt; Parsons, >>Vicki Capt; Brown, Johnnie TSgt; Floyd Gregory SSgt >>Subject: FW: FYI-WARNING (fwd) >> >>Received this on a courtesy copy this morning, once again some of you may >>get duplicates, but this needs to go far and wide. >> >>SrA Sanders >>21 Unit Security >> ---------- >>> DO NOT DOWNLOAD ANY FILE NAMED PKZIP300 REGARDLESS OF EXTENSION. >>> >>> A NEW Trojan Horse Virus has emerged on the internet with the name >>> PKZIP300.ZIP, so named as to give the impression that this file is >>a >>> new version of the PKZIP software used to "zip" compressed files. >>> >>> DO NOT DOWNLOAD THIS FILE UNDER ANY CIRCUMSTANCES!! >>> if you install or expand the file, the virus will wipe your hard >>disk >>> >>> clean and affect modems at 14.4 and higher. This is an extremely >>> destructive virus and there is NOT yet a way of cleaning this one >>> up. >>> >>> PLEASE PASS THIS ON TO ANYONE YOU KNOW. >> >> > > otto =-=-=-=-=- Otto Matic "Fuckin' A, Miller!" Bud, Repo Man --------------------------------------------------------- Get Your *Web-Based* Free Email at http://www.hotmail.com ---------------------------------------------------------

1 0

Re: How might new GAK be enforced?
by Ryan Russell/SYBASE 17 Dec '03

17 Dec '03

One way to handle the problem mentioned below is this: Using your GAK-approved encryption, send a note that contains a PGP encrypted body (or insert your crypto of choice here.) What this does is makes it look like you're sending a proper GAK only note to folks who are checking headers and such. If they actually decrypt it (with the proper court order), they will see that you've got more encryption inside, and drag your butt off to court and try to make you give up your key etc... If they decrypt it (and they have no proper court order) they either go away because they can't call you on it, or they throw you on the bad-guy list, or drag you off to area 51 and beat you with rubber hoses and some such. Point being, You wouldn't look like you were doing anything wrong unless they got as far as decrypting your messages. If you're legally busted, your messages are secure. If they illegally decrypt your messages, your messages are secure, and you may have some recourse for suing the feds. Ryan ---------- Previous Message ---------- To: tcmay cc: smith, cypherpunks From: smith @ SCTC.COM (Rick Smith) @ smtp Date: 10/01/96 04:03:10 PM Subject: Re: How might new GAK be enforced? 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.

2 1

Re: ITAR satellite provision
by jim bell 17 Dec '03

17 Dec '03

At 12:40 AM 10/2/96 -0700, Greg Broiles wrote: >At 09:31 PM 10/1/96 -0700, Steve Schear wrote: > >>Does anyone on the list have the exact ITAR reg. text relating to the >>exemption for space-launched crypto? > >I think you're talking about the definition of "export", located at 22 CFR >120.10: > > "Export means, for purposes of this subchapter: [snip] >* A launch vehicle or payload shall not, by reason of the launching >* of such vehicle, be considered an export for purposes of this >* subchapter. Most of the requirements of this subchapter relate > only to exports, as defined above. However, for certain limited > purposes, the controls of this subchapter apply to sales and other > transfers of defense articles and defense services (see, e.g., Sec. > 126.1) of this subchapter." Okay, everybody, call Estes! We've got some crypto to export...er...launch! Jim Bell jimbell(a)pacifier.com

1 0

Re: How might new GAK be enforced?
by azur＠netcom.com 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. Another possible monkey wrench is to send non-GAK messages containg random data. Since the entropy of encrypted and RNG data should be identical you can always maintain the messages contain nothing at all and cannot produce a decrypt key since none exists. > >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. See above comment. > >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. Another casuality could be anonymity. Once GAK is in place, look for a requirement for Clipper cards in order to access ISPs. -- Steve PGP Fingerprint: FE 90 1A 95 9D EA 8D 61 81 2E CC A9 A4 4A FB A9 --------------------------------------------------------------------- Snoop Daty Data | Internet: azur(a)netcom.com Grinder | Voice: 1-702-655-2877 Sacred Cow Meat Co. | Fax: 1-702-658-2673 7075 W. Gowan Road, #2148 | Las Vegas, NV 89129 | --------------------------------------------------------------------- Just say NO to prescription DRUGS. "Of all tyrannies, a tyranny sincerely exercised for the good of its victims may be the most oppressive." -- C.S. Lewis "Surveillence is ultimately just another form of media, and thus, potential entertainment." -- G. Beato

2 1

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

17 Dec '03

[But how does one undo the dangerous criminals without violating the privacy rights of everyone else? --Declan] ---------- Forwarded message ---------- Date: Wed, 2 Oct 1996 10:30:43 -0700 (PDT) From: Joe Shea <joeshea(a)netcom.com> To: Declan McCullagh <declan(a)well.com> Subject: Re: White House crypto proposal -- too little, too late If you become a dangerous criminal, Declan, I think law enforcement does have the right to use key escrow to undo you. That has nothing to do with spying. You need to be a little more selective about your language, and to make distinctions a little more rationally than you do. Best, Joe Shea Editor-in-Chief The American Reporter joeshea(a)netcom.com http://www.newshare.com:9999 On Wed, 2 Oct 1996, Declan McCullagh wrote: > BTW, Joe, I'm still waiting for your response to my comments on why > your endorsement of key escrow (GAK) is braindead. Or do you still > think that the Feds should have the right to spy on my conversations, > just like you thought that "porn isn't speech?" > > -Declan > > > On Wed, 2 Oct 1996, Joe Shea wrote: > > > Date: Wed, 2 Oct 1996 09:47:59 -0700 (PDT) > > From: Joe Shea <joeshea(a)netcom.com> > > To: Declan McCullagh <declan(a)well.com> > > Cc: cypherpunks(a)toad.com > > Subject: Re: White House crypto proposal -- too little, too late > > > > > > > > Declan, how does your list work? Do you only publish comments > > that agree with you? I didn't see my first two, and this one only came > > with your response. Is this your version of freedom of the press, or what? > > > > Joe Shea > > Editor-in-Chief > > The American Reporter > > joeshea(a)netcom.com > > http://www.newshare.com:9999 > > > > > > On Wed, 2 Oct 1996, Declan McCullagh wrote: > > > > > > > > > > > ---------- Forwarded message ---------- > > > Date: Tue, 1 Oct 1996 20:19:16 -0700 (PDT) > > > From: Declan McCullagh <declan(a)well.com> > > > To: fight-censorship(a)vorlon.mit.edu > > > Cc: joeshea(a)netcom.com > > > Subject: Re: White House crypto proposal -- too little, too late > > > > > > [Joe, this may be yet another area where we disagree. It represents a > > > power grab by law enforcement; the infrastructure is prone to failure > > > and can be compromised; it's more government meddling and coercion and > > > more restrictions on free speech; the Fed bureaucrats controlling this > > > are vulnerable to special-interest lobbying; the Constitution gives > > > the Federal government no right to impose such restrictions; the FBI > > > has demonstrated that we can't trust the Feds with our most personal > > > information; it violates an absolute right to privacy; and it's > > > technically impractical for a good number of applications. --Declan] > > > > > > > > > ---------- Forwarded message ---------- > > > Date: Tue, 1 Oct 1996 15:57:51 -0700 (PDT) > > > From: Joe Shea <joeshea(a)netcom.com> > > > To: Declan McCullagh <declan(a)well.com> > > > Cc: fight-censorship > > > Subject: Re: FC: White House crypto proposal -- too little, too late > > > > > > > > > Declan's most recent piece makes much more sense than the earlier > > > one. He is quite correct in emphasizing the future vulnerability of the > > > encryption logarithms rather than centering on whether or not terrorists > > > might use them. By making them impossible to crack without the key, and > > > permitting the key to be available to appropriate law enforcement > > > authorities when absolutely necessary, everyone's real needs are > > > satisfied, I think. I enjoyed this report a lot. > > > > > > Best, > > > > > > Joe Shea > > > Editor-in-Chief > > > The American Reporter > > > joeshea(a)netcom.com > > > http://www.newshare.com:9999 > > > > > > > > > > > > > > > > > > >

1 0

Re: ITAR satellite provision
by Greg Broiles 17 Dec '03

17 Dec '03

At 12:40 AM 10/2/96 -0700, I wrote: >I think you're talking about the definition of "export", located at 22 CFR >120.10: ^^^^^^ but upon closer inspection it looks like the House of Representatives' WWW-accessible version that I looked it up in is out of date. (geez.) The more current version is located at 22 CFR 120.17; there are some wording changes in the definition of export but the exemption for launch vehicles and payloads is unchanged. ("(6) A launch vehicle or payload shall not, by reason of the launching of such vehicle, be considered an export for purposes of this subchapter.") -- Greg Broiles | "We pretend to be their friends, gbroiles(a)netbox.com | but they fuck with our heads." http://www.io.com/~gbroiles | |

1 0

[SPAM] More "fuckhead" e-mail from Timmy May and his young friends
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

Timmy May posts inane rants with no crypto-relevance to this mailing list and attributes nonsense to people who never said it. Therefore he fully deserves every virtual fart being emitted in his general direction. >Date: Wed, 2 Oct 1996 12:16:17 -0700 (PDT) >From: "Z.B." <zachb(a)netcom.com> >Sender: "Z.B." <zachb(a)netcom.com> >Reply-To: "Z.B." <zachb(a)netcom.com> >Subject: Fuckhead ranting >To: "Dr.Dimitri Vulis KOTM" <dlv(a)bwalk.dm.com> >In-Reply-To: <B1k6uD3w165w(a)bwalk.dm.com> >Message-Id: <Pine.3.89.9610021109.A23982-0100000@netcom> >Mime-Version: 1.0 >Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > >On Wed, 2 Oct 1996, Dr.Dimitri Vulis KOTM wrote: > >> Timmy May lies, rants, posts off-topic, and pollutes the cypherpunks >> list... >etc, etc, ad nauseum, ad infinitum. > > >Boy, you just don't know when to shut the fuck up! You are *THE* single >problem with this list today. Probably the reason why "most of the good >people left the list" (so you claim) is because of *YOUR* stupid ranting >about Tim May, which is largely undeserved. Do the list a favor and get >the hell off it. > >All further messages from you will be killfiled. > > >Zach Babayco > >zachb(a)netcom.com <-------finger for PGP public key >http://www.geocities.com/SiliconValley/Park/4127 >----- >If you need to know how to set up a mail filter or defend against >emailbombs, send me a message with the phrase "get helpfile" in the >SUBJECT header. I have several useful FAQ's and documents available. > >

1 0

INFO: White House Clipper 3.1.1 plan unveiled; continues to ignore privacy concerns
by Voters Telecommunications Watch 17 Dec '03

17 Dec '03

============================================================================= ____ _ _ _ / ___|_ __ _ _ _ __ | |_ ___ | \ | | _____ _____ | | | '__| | | | '_ \| __/ _ \ _____| \| |/ _ \ \ /\ / / __| | |___| | | |_| | |_) | || (_) |_____| |\ | __/\ V V /\__ \ \____|_| \__, | .__/ \__\___/ |_| \_|\___| \_/\_/ |___/ |___/|_| WHITE HOUSE RELEASES CLIPPER 3.1.1 PLAN; SAME OLD STORY EXCLUDES CONGRESS; PROPOSAL DRIVEN BY LAW ENFORCEMENT NO CONCERNS FOR PRIVACY OF INTERNET USERS http://www.crypto.com/ Date: October 2, 1996 URL:http://www.crypto.com/ crypto-news(a)panix.com If you redistribute this, please do so in its entirety, with the banner intact. ----------------------------------------------------------------------------- Table of Contents Introduction White House announces new encryption proposal Text of White House announcement Response from Senator Patrick Leahy (D-VT) Response from Senator Conrad Burns (R-MT) How to receive crypto-news Press contacts ----------------------------------------------------------------------------- INTRODUCTION Interested in spreading the word in Congress about privacy rights and encryption? Want to help Congress fight the White House's poorly crafted, dictatorial, encryption policies? WWW.Crypto.Com has opened up a new service, "Adopt Your Legislator", which allows you to add your name to a targeted list for contacting your legislators. Whenever your legislator is teetering on an issue related to privacy or encryption, we'll notify you directly for a focused call-in/write-in campaign. It's fast, it's easy, it's like having your own personal activist. Sign up at http://www.crypto.com/ or through one of the many fine organizations below that have links to the adoption pages: Electronic Frontier Foundation (http://www.eff.org/) Center for Democracy and Technology (http://www.cdt.org/) Voters Telecommunications Watch (http://www.vtw.org/) Look for the "My Lock, My Key" icon and follow it to help fight the new Clipper 3.1.1 proposal and fight for your privacy! ----------------------------------------------------------------------------- WHITE HOUSE ANNOUNCES NEW ENCRYPTION PROPOSAL The White House announced their new encryption proposal yesterday. There are several main points that have come out now, or will appear soon: -jurisdictional move from State to Commerce for export applications with a Department of Justice role -temporary increase of key lengths to 56 bits, provided future key escrow functionality is promised, -joint effort with companies such as IBM to produce key escrow products, -increased purchasing of key recovery products by Federal agencies to stimulate the creation of a key escrow industry, and -legislation to legitimize the key escrow recovery market. There are absolutely no plans to permanently increase the key length of unescrowed encryption products. Companies who do not have an escrow plan in place by the end of the two year temporary increase will lose their export status. This proposal has a number of significant problems, including: DOMINATED AND DRIVEN BY LAW ENFORCEMENT INTERESTS This Clipper proposal, like the three previous ones, has been driven entirely by the concerns of law enforcement. This should come as no surprise to even the most optimistic industry or public interest advocates. As Senator Leahy (D-VT) says in his statement below: Internet users themselves -- not the FBI, not the NSA, not any government regulator -- should decide what encryption method best serves their needs. JUSTICE ROLE IN EXPORT APPLICATIONS A BLATANT ATTEMPT AT DOMESTIC CONTROL OF CRYPTOGRAPHY By allowing Justice a seat at the table in approving export applications, the Clinton Administration has clearly demonstrated that they wish to control the domestic cryptography market. Justice will certainly veto the export applications of any products which they are not able to break either by brute force or without key escrow. This will probably end up being an even worse route for companies wishing to export products. TEMPORARY INCREASE IN KEY LENGTH IS NOT SUFFICIENT The original Clipper proposal would have allowed encryption with 80 bits keys. Clipper II bandied about the number 64 as the acceptable level of encryption. With Clipper 3.1.1, that amount has been reduced to 56 bits for the next two years. This is clearly too little too late. CONGRESS WAS NOT CONSULTED Congress has clearly stated their intentions with regards to the White House policy, and this year will certainly not be the end of their involvement in the issue. Senator Burns (R-MT) summarizes it well: This debate is not over by any stretch of the imagination. The administration has prevented Congress from weighing in on this issue just as support was building for a legislative solution. I intend to move forward with pro-encryption legislation in the next Congress. You can continue to follow this issue at http://www.crypto.com/ ! ----------------------------------------------------------------------------- TEXT OF WHITE HOUSE ANNOUNCEMENT 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. ----------------------------------------------------------------------------- RESPONSE FROM SENATOR PATRICK LEAHY (D-VT) 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. ----------------------------------------------------------------------------- RESPONSE FROM SENATOR CONRAD BURNS (R-MT) For immediate release: Contact: Matt Raymond Tuesday, October 1, 1996 (202) 224-8150 Randall Popelka (202) 224-6137 Burns Cautious on Encryption Plan Oversight Vowed for Plan That "Raises More Questions Than It Answers" WASHINGTON, D.C. _ Montana Senator Conrad Burns today reacted cautiously to plans by the Clinton administration to loosen restrictions on exports of stronger encryption for computer software and hardware. He also criticized the White House for its failure to negotiate on the cornerstone of its proposals: that companies must agree to "escrow" their decryption keys. "I have no doubt that it was the pressure of Congress, high-tech companies and privacy advocates that dragged the White House kicking and screaming into agreeing that export restrictions should be eased," said Burns, chief sponsor of the Pro-CODE bill, which would loosen restrictions on encryption exports and prohibit government-mandated key escrow. "However, I can't say I'm pleased with a process that has all but excluded Congress and the public from the discussion. "The administration's insistence on key escrow as a condition of lifting these restrictions has never been negotiable. Meanwhile, what choice do these companies have but to yield as their global competitiveness withers on the vine? "This plan raises even more questions than it answers, such as, what about the widespread availability of much stronger encryption than that which is allowed by the White House? How do we deal with rapid changes in technology that will inevitably render the 56-bit limit obsolete? The devil is definitely in the details. "This debate is not over by any stretch of the imagination. The administration has prevented Congress from weighing in on this issue just as support was building for a legislative solution. I intend to move forward with pro-encryption legislation in the next Congress. "I will also push for vigorous oversight of the administration's plan in the Commerce Committee." The Senate Commerce Committee, of which Burns is a member, has jurisdiction over the Commerce Department. The administration has stated its intent to transfer export licensing authority over encryption from the State Department to the Commerce Department. ----------------------------------------------------------------------------- HOW TO RECEIVE CRYPTO-NEWS To subscribe to crypto-news, sign up from our WWW page (http://www.crypto.com) or send mail to majordomo(a)panix.com with "subscribe crypto-news" in the body of the message. To unsubscribe, send a letter to majordomo(a)panix.com with "unsubscribe crypto-news" in the body. ----------------------------------------------------------------------------- PRESS CONTACT INFORMATION Press inquiries on Crypto-News should be directed to Shabbir J. Safdar (VTW) at +1.718.596.2851 or shabbir(a)vtw.org Jonah Seiger (CDT) at +1.202.637.9800 or jseiger(a)cdt.org ----------------------------------------------------------------------------- End crypto-news =============================================================================

1 0

Re: Hey, there's a camera in that palm tree!
by Ryan Russell/SYBASE 17 Dec '03

17 Dec '03

But would they be able to image identify my butt when I moon 'em? (And I'll have none of those "If it could image your face, what would be the difference in imaging your butt?" jokes!) Ryan ---------- Previous Message ---------- To: cypherpunks cc: From: mix @ anon.lcs.mit.edu (lcs Mixmaster Remailer) @ smtp Date: 10/01/96 05:00:01 PM Subject: Hey, there's a camera in that palm tree! LANGHORNE, Penn., Sept 30 (Reuter) - Digital Descriptor Systems Inc said on Monday that it had received the first $140,000 phase of a proposed $1.4 million contract from IBM. The money is to be used by the Bahamas for the installation of imaging identification systems. The first segment of the imaging program will be installed in the Bahamas by the end of this year. Digital Descriptor, in a three-year partnership with IBM to create a program needed on a country-wide basis by the government of the Bahamas, manufactures and markets imaging systems for municipal and private criminal enforcement markets.

1 0

Re: REM_ail
by jim bell 17 Dec '03

17 Dec '03

At 01:43 PM 10/2/96 GMT, John Young wrote: > 10-8-96. VV: > > "The Remailer Is Dead, Long Live the Remailer. Life After > Penet." By Dave Mandl (Excellent, Dave, yes!) > > By the strict standards of the cypherpunks, a loosely > knit affinity group of the Net's most radical and > technoliterate privacy advocates, Penet's security was > actually on the flimsy side. Its Achilles' heel was the > file -- just begging to be subpoenaed -- that linked > users' real names to their Penet pseudonyms. > Cypherpunk-run remailers, on the other hand, generally > leave no trace of the sender's true identity. In > addition, cypherpunk remailers can be "chained" -- > messages can be routed through several far-flung > remailers before reaching their final destination, making > message tracing all but impossible, even for the remailer > operators. > http://jya.com/remail.txt > ftp://jya.com/pub/incoming/remail.txt REM_ail Now that Helsingius has shut down Penet, what's to stop him from simply LYING about the source of the messages in question, maybe claiming that they came from the output of a cypherpunks remailer and are thus permanently untraceable? (one feature it might have been useful for him to have included in Penet is the ability of the user to re-address a return address, which would presumably erase the original address in the records. Just sending email and some particular password would do it...) Jim Bell jimbell(a)pacifier.com

2 1