December 2003 - cypherpunks-legacy

Re: Security Spectra
by williams＠va.arca.com 17 Dec '03

17 Dec '03

P.J. Ponder writes: > In your recent post to the cypherpunks mailing list you proposed a > taxonomy of security weaknesses and vulnerabilities, adding that these Please watch your attribution. Vlad Nuri proposed this rating scheme. > The whole idea of categorizing or ranking holes and vulnerabilities ab > intitio, outside of their contextual application to a real system is not > very helpful. Systems vary so widely in their criticalities, > sensitivities, costs, etc., that each of your pre-defined categorized > weaknesses would have to be rejudged - in the context of the system being > analyzed - to determine how, and to what extent it could effect the system. I absolutely agree with you on this point. I'll point out again that this is the same problem as creating a rating scheme for the security of *products*. > The standard approach as I understand it is to analyze the system against > all the known vulnerabilities and attempt to measure (maybe only > qualitatively) the risks associated with the vulnerabilities. It is popular these days to jump on the risk assessment bandwagon and forget about assurance. This occurs because people think risk assessment is a quick fix that you can do after the system is built and configured. Some holes cannot be patched. --Jeff Williams <mailto:williams@arca.com>

1 0

San Diego Cypherpunks Physical Meeting
by Chris Claborne 17 Dec '03

17 Dec '03

San Diego Area CPUNKS symposium Thursday, Oct 26, 1995 Invitation to all Cypherpunks to join the San Diego crowd at "The Mission Cafe & Coffee Shop" were I hope to get an update of Lance Cottrell's new anonymous e-mail server, "mixmaster", exchange keys, and discuss other topical subjects. Don't forget to bring your public key fingerprint. If you can figure out how to get it on the back of a business card, that would be cool. Place: The Mission Cafe & Coffee Shop 3795 Mission Bl in Mission Beach. 488-9060 Time:1800 Their Directions: 8 west to Mission Beach Ingram Exit Take west mission bay drive Go right on Mission Blvd. On the corner of San Jose and mission blvd. It is located between roller coaster and garnett. It's kind of 40s looking building... funky looking (their description, not mine) They serve stuff to eat, coffee stuff, and beer. See you there! New guy, bring your fingerprint. Drop me a note if you plan to attend. 2 -- C -- ... __o .. -\<, Chris.Claborne(a)SanDiegoCA.ATTGIS.Com ...(*)/(*). CI$: 76340.2422 http://bordeaux.sandiegoca.attgis.com/ PGP Pub Key fingerprint = A8 FA 55 92 23 20 72 69 52 AB 64 CC C7 D9 4F CA Avail on Pub Key server.

3 2

Re: My chat with Goeff Greiveldinger
by Michael Froomkin 17 Dec '03

17 Dec '03

Here is my first cut at what I plan to say. Not real exciting, but I don't know how much knowledge to assume in the audience. I would be grateful for a pointer to any commercial key escrow services that are actually in operation today. And doubly grateful for a pointer to one that does not rely on a proprietary encryption scheme and/or one that allows/requires key splitting for extra security. Key Escrow in Secure Electronic Commerce October 19, 1995 4:30 pm - 5:50 pm Outline Intro: In this talk I will... * Begin with why business wants/needs *data* CKE * Turn then to law enforcement focus on communications KE * Explain how govt hardball on export control in pursuit of Comm KE threatens needed CKE -- or at least US companies' share of that market... * Discuss pending issues I. Commercial key escrow, the WHAT, WHY, WHO and HOW A. WHAT Give someone (internal/external) copies of keys (private/ symmetric) used in the course of business 1. Essential (from corporate perspective) for a. all encrypted, stored corporate data b. keys with power (1) to sign things in corporate name e.g. buy/sell (2) to issue certificates 2. Less essential (from corporate perspective) a. for email keys but still pretty important if you might have to reconstruct exchanges of messages at a later date. b. for telephone keys although useful if you think there will be need for you and/or police to spy on your employees, eg. investigate fraud/theft. B. WHY 1. Irresponsible for corporation not to encrypt data and some communications if these are of commercial value to competitors/otherwise sensitive 2. Irresponsible to encrypt data (and maybe also communications) and not have fail-safe means of access a. employees lose their keys b. employees die c. employees quit (and vanish or do some vandalism) d. employees are suspected of engaging in hanky- panky C. WHO Escrow agent could be 1. internal a. only viable solution right now unless you are satisfied with, e.g., RSA non-interoperable crypto system b. but are you hacker-proof? 2. external, e.g. a. TIS licensed "Data Recovery Center" (but there are none in existence today) b. bankerstrust c. govt agency (someday? but not today) d. can use split key systems for increased security. [but is anyone actually offering such a service?] One problem with external is that NONE of the liability issues are resolved. E.G. Suppose private escrow agent complies in good faith with facially valid warrant, but warrant is l D. HOW Here we have more doubts than knowledge Not clear yet what security precautions commercial escrow agents will offer. Can assume: 1. Secure systems 2. Contract-driven mechanism for verifying IDs/bona fides of persons attempting to take out data 3. Contract-driven assurances of speed of response 4. split key systems with different escrow agents? II. Legal implications of commercial key escrow Three families of issues: 1. data owner liability for not escrowing 2. escrow agent liability for errors 3. Government access to keys A. It is irresponsible NOT to escrow keys if you encrypt data. And it is increasingly irresponsible not to encrypt. Hence some form of escrow will become practically mandatory. 1. Query: won't this make it easier for the government to get access to my data? Answer: must distinguish between stored data and communications. You are escrowing the keys not the data itself. The data remains secure in your own machine/tape/safe/whatever. There it's subject to subpoena just like paper records. So encryption + escrow is no substitute for destroying the smoking gun, but it's also no more danger than ordinary records. Escrowing keys used for communication makes those communications more vulnerable to government interceptions. Strong, unescrowed, keys may defeat even a lawful subpoena for a wiretap. Escrowed keys are vulnerable to legal (at least) wiretaps. 2. More on "practically mandatory": The government may make it a condition of doing certain kinds of business, e.g. govt contracting, that only escrowed encryption be used. Similarly, the government may be willing to engage in secure communications with the public, but only via system that are limited to escrowed keys. 3. Still more on "practically mandatory": carrot & stick of export controls (see below). B. Escrow agent liability for errors Currently, rights and resp of customer vs. escrow agents depend on whether escrow agent is public or private 1. Public escrow agent -- low accountability? In the "Clipper 1" proposals, the escrow system lacked any legal guarantees for the people whose keys are generated by the government and held by the escrow agents. Indeed, the Attorney General's escrow procedures stated that they þdo not create, and are not intended to create, any substantive rights for individuals intercepted through electronic surveillance.þ In short, the government disclaimed in advance any reliance interest that a user of an EES-equipped device might have in the government's promise to keep the key secret. A victim of an illegal wiretap would have a cause of action under Title III against the wiretapper, but, it appears, no remedy against the escrow agents, even if the escrow agents acted negligently or failed to follow their own procedures. The Attorney General's procedures themselves are merely directives. They are not even legislative rules, which might be subject to notice and comment restrictions before being rescinded. A future administration could, if it wanted, secretly instruct the escrow agents to deliver copies of the keys to an intelligence or law enforcement agency, or even White House þplumbers,þ thereby violating no law or regulation (the plumbers, though, would violate Title III when they used the information). Because the chip-unique keys were voluntarily disclosed to the government, the chip's owner might lack a þlegitimateþ (that is, enforceable) expectation of privacy in the information. If the intercepted communication were an e-mail or a file transfer, rather than a telephone call, the chip owner subject to an illegal or inadvertent disclosure by the escrow agents may be in a particularly weak position if the information ever makes its way to court: many Title III protections granted to voice communications do not apply to transfers of digitized data. Shortly before the 103d Congress adjourned, Congressman George Brown introduced the Encryption Standards and Procedures Act of 1994, which would have waived the sovereign immunity of the United States for þwillfulþ but unauthorized disclosures of key fragments by its officialsþand excluded liability in all other circumstances. In the absence of similar legislation, however, there may currently be no monetary remedy even for a þwillfulþ disclosure. 2. Private escrow agent -- contract accountability, tort, maybe bailee/trustee (dubious) If you want software key escrow today, you have to be your own escrow agent, or go to a private escrow agent because there is no government agency ready and able to act in this capacity (and few private bodies!) Given current liability rules, you would be better off with a private body than the government anyway (tradeoff: maybe more security in government agency (?) vs. more recourse against private party). The "son of clipper" trial balloon floated this fall suggested that export permission would be given to (relatively) strong (ie. 64 bit max) software cryptosystems, if those systems were designed to ensure that the keys were escrowed with an "approved escrow agent". NIST solicited comments in Sept. '95 as to a. what sort of bodies would be suitable, and b. what terms and conditions should govern the escrow agents. c. What procedures need to be developed for the storage and safeguarding of keys? d. Performance criteria (e.g., around-the-clock availability, accessibility, reliability, etc.) for approved key escrow agents? e. Under what circumstances will key escrow agents in foreign countries be approved? f. Should approval of key escrow agents be tied to a public key infrastructure (for digital signatures and other purposes)? [The last point is potentially ominous...if access to digital signature infrastructure is conditions on using KE, then this makes export control hardball look like small beer] To date there has been no public feedback from NIST subsequent to the meeting except that they are revising the criteria in light of what they heard. [Can GG tell us more?] C. Government access to keys NB that government seems primarily interested in communications; business main focus is/should be DATA. Now with "Son of Clipper" (software KE), the government has relaxed the suggestion that keys be generated and escrowed via hardware (e.g. Fortezza), but has substituted onerous criteria it hopes it can persuade (threaten?) industry to apply to software, including: III. (Mostly specious) Arguments Against Commercial Key Escrow [with apologies to Marc Rotenberg, Electronic Privacy Information Center, who posted the quoted material to USENET several months ago] A. Bad for business 1. "Increased network vulnerability. The key escrow configuration necessarily increases the likelihood of communications compromise and improper interception by third parties. Computer crime will skyrocket." Very unrealistic and alarmist. While as a theoretical matter it is clearly true that the sharing the keys with the escrow agent must create an avenue of attack that did not exist before, the risk can be very greatly reduced by a. key splitting (never send the whole key to anyone at any time) b. secure communications with very secure algorithms between escrow agent and customer [NB that US government export policy implicates this to the extent it makes strong crypto non-exportable] 2. "Policy incoherence. The key management needs of business differ sharply from the real-time intercept plans of law enforcement. The latter has little to do with the former." Probably true, but irrelevant to the matter at hand: business needs escrowing for its own disaster recovery needs. 3. "Complexity. Has anyone really given thought to how many communications will be encrypted in 20 years and what the key management requirements will be to develop a unitary key escrow system to satisfy the government's concerns?" Maybe, maybe not. But businesses need CKE now. Keys don't live for ever, and a sound security plan will include provisions for retiring keys as they age. Age makes keys vulnerable a. technological change makes bruting longer keys possible b. the longer the key is out there the more time attackers have to brute (or otherwise compromise) the key B. Bad for civil liberties 1. "Emergency circumstances taps. The current wiretap law permits the initiation of a wiretap *without court order* upon a certification that emergency circumstances exist. If this procedure is built into the CKE procedure, then there will be *no judicial review* prior to the disclosure of keys." True. But these taps are currently rare, and limited to cases like kidnapping where lives are at stake. It's fairly unlikely that a business will ever encounter one of these. 2. "The future of PGP. Will PGP and other non-escrow schemes be permitted if CKE is adopted? What will be the implications for developers and companies in the communications industry?" Voluntary CKE in and of itself is not going to affect the legality of alternative un-escrowed crypto. The politics are hard to predict: one can imagine arguments that mandatory escrow is not needed because it's being done voluntarily; and also arguments that the increasing voluntary CKE means that there's less reason not to make it mandatory. My guess: no great effect one way or the other. The issue will be settled by larger things e.g. what's more scary -- Oklahoma City or Ruby Ridge? IV. Recent Developments in key escrow A. NIST initiatives NIST is currently putting "final touches" on draft export criteria, under auspices of inter-agency working group. NIST hopes to "notice" revised draft criteria in fed register, perhaps within the next month; then a 60day comment period, with a 1-day live meeting in DC sometime during the comment period. When NIST has final version of inter-agency recommendations set, they will be turned over to the state dept to implement; state can do what it likes. One possible model for State Dept. action is a change to the ITAR. V. Outstanding Issues A. Why would any foreign company use US govt approved crypto in light of new focus on economic intelligence, e.g. Japan spy case? Possible govt responses: 1. foreign govt might have copy of key? share key? 2. foreign-based, but US-approved, escrow agent might hold/share key B. MANDATORY CKE? 1. Legislation? 2. "milder variants" a. export control club (is 64 bits enough?) b. data vs. communications issue c. Digital signature infrastructure access club (informal talks suggest this is not likely, but not formally ruled out....) C. Enabling ("technical") legislation 1. Title III exemption for escrow agent 2. Authority to "certify" escrow agents 3. liability rules for escrow agents D. Enabling regulations 1. Care & feeding of escrow agents, a. eg. sample criteria for being approved and/or sample contract between government and escrow agent b. performance criteria for escrow agents e.g. response time E. Liability in the absence of legislation 1. First, find someone actually selling escrow services with an interoperable product. 2. Or, resign yourself to eg RSA keys. A. Michael Froomkin | +1 (305) 284-4285; +1 (305) 284-6506 (fax) Associate Professor of Law | U. Miami School of Law | froomkin(a)law.miami.edu P.O. Box 248087 | http://www.law.miami.edu/~froomkin Coral Gables, FL 33124 USA | It's hot here. And humid.

1 0

NOT_100
by John Young 17 Dec '03

17 Dec '03

The New Yorker of October 23 reports on the "Supernote," a perfect counterfeit $100-bill allegedly being used for economic terrorism. The Supernote had surfaced around 1990 and originated in the Middle East. It was no ordinary counterfeit. The workmanship was extraordinary. When a sample first arrived at the Secret Service's laboratory, a top technical analyst "examined it the way he has every other counterfeit note in the world, and called it genuine." Most alarming of all, the Supernote was so well engineered that it could fool currency scanners at the nation's twelve Federal Reserve banks. Today, the Supernote remains one of the longest unsolved counterfeiting cases in the modern history of the Secret Service, and it has begun to undermine international confidence in United States currency. The Treasury, taking its cue from the Federal Reserve, has a difficult time regarding counterfeiting, even on a very large scale, as a macroeconomic problem, because cash is a relatively small percentage of the total money supply. Wire transfers, checks, and credit-card transactions, after all, run into the trillions. Counterfeiting becomes significant to the Fed only if it undermines confidence in the dollar. Dozens of interviews with high-level insiders left the impression that the Federal Reserve and the Treasury don't fear the Supernote itself as much as they fear a confidence problem that might result if they publicly acknowledge it and countenance a large-scale investigation. (As one expert on international terrorism who has looked into the Supernote puts it, "If the note is that nearly perfect, it doesn't exist.") NOT_100 (30 kb in 2 parts)

1 0

Re: Using deterministic programs to select private RSA keys.
by Martin Diehl 17 Dec '03

17 Dec '03

norm(a)netcom.com(Norman Hardy) writes: Much has been said recently here about how to produce truly random primes. [snip] The protocol is to accept a sequence of key strokes for printable ASCII characters. [snip] I suggest that if you capture the time in microseconds between keystrokes and insert the least significant 8 bits between the corresponding characters (i. e. <letter1> <time2 - time1> <letter2> <time3 - time2> <letter3> ... <letter nnn> <time until double CR - time nnn>) and MD5 the set of values, the resulting "random" value will be different for both people who type different input texts as well as those people who type the same input text. It is important to be sure that you are accessing a true microsecond clock (or other high resolution clock). For example, in the IBM PC architecture, the clock tic (basic time interrupt) is one per 18.2 milliseconds or 55 interrupts per second. If you were using the clock tic rate and a highly trained typist with a regular typing rate, the interspersed time values might show a consistent set of values. On the other hand, use of a microsecond clock eliminates this problem. As regards the observation that MD5 produces only a 128 bit result, you could call MD5 after each nn values (at least 16) have been entered. In that way a few lines of input and associated timing values could easily generate a value of the same order of magnitude as the number of 1K primes. Martin G. Diehl

1 0

Re: Netscape rewards are an insult
by Westcan1＠softnc1.softnc.com 17 Dec '03

17 Dec '03

:: Request-Remailing-To: cypherpunks(a)toad.com Subject: Re: Netscape rewards are an insult > > Promoting the notion that hackers are earnestly attacking > > Netscape and reporting its bugs increases its credibility to > > the stock market porkers. Is that not why dear > > all-too-attentive Jeff has been assigned duty on this list, > > feeding peanuts to chimp hackers and champ newshacks? Whoa!! > I'm afraid you're a little out of line here. > I've worked with Jeff at a couple different companies > over the last 6 years. Besides being a very good programmer > he's also one of the people I consider the most resistant > to corportate bullstuff (beleive me, we both got a lot of it at MicroUnity). > I'm sure he's on this list because he thinks it's a good > idea to pay attention to it. Maybe he is, but I'd rather hear everyone speak for themself. You can speak for you. And you can let Jeff speak for himself. And I'd rather that Netscape speak for itself, too. Is Jeff or any of the other netscape posters here officially?? Or are they here, just out of personal curiosity (without their employers knowledge, I mean ...) cause they have a whole lot of spare time on their hands to learn about cryptography and security. I wish one of them (or Netscape) would make an official comment to make sure that the record is straight, and that there is no mis-reporting. > What the hell is wrong with you people? Up 'til a few months > ago, the oft-heard refrain on cipherpunks was "why won't the > software vendors listen to us?"... now they're listening, Yep, they seem to be listening. They just don't seem to be talking. Can someone say something, please?? Is it true that: - Netscape has known about this problem since last week's scathing public attack and demonstration of the problem which included sample code posted to the Internet?? - If you run and use a Netscape client, that any machine anywhere in the world if it's on the Net could retrieve all of the files off of your hard drive or LAN?? Or even worse ... erase files on your Hard drive and wipe you out?? - Even if your machine is behind a firewall or proxy server, that there is no protection?? That you can't do anything?? Can someone comment, please?? (Carbon copy sent to: postmaster(a)netscape.com, cypherpunks(a)toad.com, cert(a)cert.org)

11 22

Re: 90%
by Robin Felix 17 Dec '03

17 Dec '03

At 11:01 PM 10/12/95 -0400, zoetrope(a)infinet.com wrote: >Can I ask a question....are you guys into cryptology for the interesting >facts and knowledge or fer cracking unix codes and raising havoc? Do you drive a car to go to work, go to school, or go to the beach? Or just, perhaps, because you enjoy tinkering with it? -- Robin Felix; felix(a)delfin.com; felix(a)nosc.mil 619-291-2194(work), 619-291-5852(fax), 619-991-5081(alt) http://www.delfinsd.delfin.com/

1 0

BeBox Security Hole?
by rah＠shipwright.com 17 Dec '03

17 Dec '03

This looks like fun... Cheers, Bob Hettinga >Date: Mon, 16 Oct 1995 23:07:58 -0700 >From: crawford(a)scruznet.com (Michael D. Crawford) >To: semper.fi(a)abs.apple.com, dev(a)be.com >Subject: Re: BeBox development questions and answers >Message-ID: <199510170607.XAA06319(a)scruz.net> > >Jonah Benton asked Melissa Rogers about security: > >>>>are there ways of excluding certain users from certain parts of the file >>>>system? >>>No >>>> >>>>i believe you support telnet- can multiple users telnet in at once? >>>> >>>Yes > >The answers to these two questions suggests the existence of the following >serious security problem, which can cause breaches on any other machine on >the network. This is a time-honored way for hackers to bust into machines >on the Internet. > >do{ > telnet to an Internet host that does not have adequate security > > Patch the telnet client on the Be box to save keystrokes into a file > > Log out > > Wait a couple weeks > > Telnet back in, retrieve the file. > > Now you have the host names, account names, and passwords for several other > machines >}while ( Internet != destroyed ); > >Would someone from Be care to clarify? > >This isn't exactly on-topic for this list, but it is a serious problem. >It's been going on for years on other OS's. > >Mike > >Michael D. Crawford | I use anonymous digital cash from DigiCash. >crawford(a)scruznet.com | Join the e-Cash trial at: >http://www.scruz.net/~crawford/ | http://www.digicash.com > ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

re: e$: Reuters Smells the Coffee
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Sorry, folks. Eudora got the best of me there... Sorry for the bandwidth... Cheers, Bob ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

Yardley's 1st ed. "Black Chamber" $25+
by baum＠apple.com 17 Dec '03

17 Dec '03

I found one in a bookstore. I didn't buy it, but I'll go back and get it & ship it if someone is interested. ************************************************** * Allen J. Baum tel. (408)974-3385 * * Apple Computer, MS/305-3B fax (408)974-0907 * * 1 Infinite Loop * * Cupertino, CA 95014 baum(a)apple.com * **************************************************

2 1