December 2003 - cypherpunks-legacy

NIST GAK export meeting, Long version part 1
by Pat Farrell 17 Dec '03

17 Dec '03

NIST Key Export meeting, December 5, 1995 Long version, Part 1 of N This covers the criteria, except interoperability. (To keep TCMay's prediction from becoming true, I'll put this out in parts) This really needs a hypertext media. I'll build one for html page. Please bear with me on this, pure ASCII mail version. This is a write-up of stuff I left out of the summary. I'll merge them together on my nistpage, probably Friday. You've already seen the short write up. There is a fair amount of information on the NIST web server. Use url: < http://csrc.ncsl.nist.gov/keyescrow/> As David Lesher noted, one of the most significant things was obvious in the parking lot. Unlike September's meeting, this time it was empty. Inside the hall, it was obvious that no one came. It was packed in September, and now, entire rows were empty. I'm bad at guessing numbers, but its easy to guess that only 1/3 as many people showed. Maybe less. >The meeting was hosted by Ed Roback of NIST, The meeting was in general a repeat of September's meeting, and similar meetings that have been going on for years. Both sides talk past each other. I think this has degenerated into a parallel with the abortion debate. There is no common ground. >He said that they have studied the encryption that is supposed to be widely available on the Internet. >He said that viewed by crypto experts, not much is very good. He mentioned "two incidents" where >Netscape had weak implementations. He feels that companies will not trust software over the 'net. that >they "want the US Government to say that 'this is good enough'." I assume that the "two incidents" don't count breaking RC4-40. I can't remember two Netscape security incidents, unless he means to count RJC's buffer overflow, all I can remember is Ian's key generation problem. >Clint Brooks, of NSA, then went over the revised criteria. He claimed that they >were surprised at the industry concern over "one product" for worldwide markets. He stated that they were addressing "not domestic policy, per se, but we keep wrapping around" because of the 'one product' issue. The criteria are on the NIST page, url: <http://csrc.ncsl.nist.gov/keyescrow/criteria.txt> They handed out a guide to the changes in the criteria between September and now. This is available from NIST as url: <http://csrc.ncsl.nist.gov/keyescrow/bground.html> Here is a portion of it: Old Criterion 1. Moved to #7; Old Criterion 2. Moved to #8; Old Criterion 3. Split into #1 and #2 Old Criterion 5. Moved to #10 Old Criterion 6. Moved to #9; Old Criterion 7. Moved to #5; Old Criterion 8. Moved to #6; Old Criterion 9. Deleted. Old Criterion 10. Moved to #3; Only in Washington. Oh yeah, they also clarified a lot of the wording. Ideas that I thought important enough to make notes of concerning the criteria: These criteria do not address either hardware nor non-escrow encryption. Export controls of these are not changed, they can be exported with the current procedures. Brooks said that these rules are not applicable to the protection of internal data for US corporations, even for overseas locations of US firms. He said that getting permission to export for _internal corporate use_ is easy, if it is to protect corporate secrets and for internal communication. I took this to mean that a multi-national, US-based corporatgon can get a permit for ViaCrypt and export it for their own use. [later in the day, some people mentioned that this isn't nearly as easy as Brooks claimed.] He said that the intent in the new wording is flexibility. They don't want to prescribe implementation details, he wants industry to invent what sells. He specifically stated that the meetings were not about setting standards. This caused at least a fair amount of confusion, probably due to the fact that NIST used to be called National Bureau of Standards, and NBS set standards all the time. For example, a couple of folks were interested in interoperability, say between a Netscape encryption system and one made by, say, Microsoft. This meeting did not address this level of interoperability. about #2, "The product's key escrow cryptographic functions shall be inoperable until the key(s) is escrowed in accordance with #3." Brooks said that the intent was to allow vendors to make a single product that doesn't activate the key-escrow function if not needed. The idea was that when the keys are escrowed, the encryption engine would be activated. He also said that "manufacturers may not want to be in the key escrow business" and would therefore want to ship products that could be activated by a third party escrow agent. While talking about #3, "3. The product's key escrow cryptographic functions' key(s) shall be escrowed with escrow agent(s) certified by the U.S. Government, or certified by foreign governments with which the U.S. Government has formal agreements consistent with U.S. law enforcement and national security requirements." He stated that this does not preclude the use of "other agents." This became a major issue throughout the day. Ken Mendelson, staff attorney at TIS, asked (roughly) "Under what authority does the US Government grant certification to agents?" The response was a run around. Another hot issue was whether you can "hold your own keys" rather than using a third party. Seems that the corporate users are arguing that they want to hold their own keys, and the government reacted to that favorably (not unfavorably?). [Later in the day, Geoff Greiveldinger was asked if US citizens have the right to hold their own keys. Geoff was forced to admit that, "yes, you can hold your own keys"] #5, "5. The product's key escrow feature shall allow access to the key(s) needed to decrypt the product's ciphertext regardless of whether the product generated or received the ciphertext." Contains a significant change that was not discussed in September. It means that having the key for either end is sufficient. Brooks conceded that this was a big change, but claimed it was needed. The claim that one-ended surveillance is easier is most likely true. It clearly is easier if one end is US based and using GAK and the other is foreign where there is respect for civil liberties. He even claimed that it made the system less intrusive: His argument was roughly: Lets say they are snooping on me. With one-ended, they can read all of my messages, to and from, without needing the keys of my correspondents. (lets pick Geoff G. as an arbitrary correspondent) With two ended, they'd have to get both my key and Geoff's, and then they could read all of the messages Geoff gets or sends. I said it was _their_ argument. Seems to me to be groundless, unless they got the keys of everyone in the chain, all of the folks that I talk to, all of the folks that everyone I talk to, etc. on "7. The product's key escrow cryptographic functions shall use an unclassified encryption algorithm with a key length not to exceed sixty-four (64) bits." This is really aimed at session keys, or at least non-RSA keys. I suggested that they really needed some wording that make it clear. >He said that the 64-bit key limit is not meant to restrict RSA keys to >64-bits, but rather to restrict the session keys that are encrypted using >RSA. Unspoken was the assumption that the 2000 bit RSA secret key would have to be escrowed. on "8. The product's key escrow cryptographic functions shall not provide the feature of multiple encryption (e.g., triple- DES)." He pointed out that the wording used to say "prevent" and now just says "not provide". He acknowledged that "prevent" was impossible. on "9. The product's key escrow cryptographic functions shall interoperate only with key escrow cryptographic functions in products that meet these criteria, and shall not interoperate with the cryptographic functions of a product whose key escrow encryption function has been altered, bypassed, disabled, or otherwise rendered inoperative." Brooks said that this was intended to allow multiple modes, such as compatibility with other encryption schemes. Of course, he said, the other modes are subject to export restrictions. Somewhere in the discussion, Ed Appel took over for Brooks. Appel is "Director of Counter Intelligence Programs, National Security Council, The White House" He was introduced as FBI. >There were some interesting (and bad IMHO) implications of interoperability. I'll cover them more in the next section Pat Pat Farrell Grad Student http://www.isse.gmu.edu/students/pfarrell Info. Systems & Software Engineering, George Mason University, Fairfax, VA PGP key available on homepage #include <standard.disclaimer>

1 0

re: NIST GAK export meeting, sv
by Peter Trei 17 Dec '03

17 Dec '03

"Hieronymous" says: > (Thanks for the summary, Pat.) > This last bit is really rich. I can't think of a single publically > defensible reason for the stipulation that every escrow agent must employ > someone with SECRET clearance, but I *can* think of a publically > indefensible reason for it -- to facilitate those spooky non-court wiretap > authorizations that've been alluded to in the fine print of the GAK > proposals. This is probably one reason. Another is that they could shut down an escrow agent at a moment's notice by pulling the clearances. We haven't seen the other requirements, but an interesting question is what happens when an escrow agent goes out of business. Speaking for myself.... Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

2 1

Re: No More Netscape Comments from Me
by rah＠shipwright.com 17 Dec '03

17 Dec '03

>So, have fun riding the Great Internet Bubble of 1995! Yeah... I wonder what the price of Netscape puts around, say, March are these days... Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA (617) 958-3971 "Reality is not optional." --Thomas Sowell The NEW(!) e$ Home Page: http://thumper.vmeng.com/pub/rah/ >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

3 2

Re: Geodesic Payment Systems? (was Re: Meeting notes from ANSI X.9 Meeting onElectronic Payment)
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Once again, Hettinga shoots from the hip, and hits an expert instead... ;-) At 9:07 AM 12/5/95, Nathaniel Borenstein wrote: >There are some interesting unspoken assumptions here. To calculate >anyone's "cost" on a transaction requires the complex amortization of >costs over many transactions, with assumptions/projections about the >transaction volume. I have no idea where you came by either of your >numbers, MTB's or FV's, but I can tell you that your guess about FV is >off the mark. And I'm sure that MTB is no more eager than we are to >publicly dissect all the underlying cost structures, so I have no idea >what the 50 cents that you cite really means. The 50 cents actually comes from this week's InfoWorld, Bob Metcalfe's column. I have know idea where he got the 50 cents, but he did say digital cash, so i expect that he means MTB. >To be perfectly clear: our minimum service charge is 30 cents, not 5 >dollars. If we didn't think it was worthwhile to take transactions that >small, we wouldn't do so. Fine. Are we including the cost of the credit card transaction to the consumer? Fees, interest, that stuff? There are lots of hidden costs in a book entry system. With a bearer-certificate system, the price is the spread between the certificate's bid and asked prices for (a traveller's check, for instance, is asked at a primium, and redeemed at face value, for instance. That's all the cost of using them.) >A true geodesic structure is self-supporting and self-structuring. A >cryptographic infrastructure can and should be similar, I agree >completely. However, a *monetary* infrastructure needs convertability, >and the points of conversion are always the best targets of attack for >criminals. (I've been casting about for an analogy to physical >geodesics, and it's hard to find one. The best I can come up with is to >imagine that in order to convert a carbon buckyball to a more >conventional set of carbon molecules, you had to do it through a service >bureau that was capable of error, fraud, or subversion by outside >criminals. This would ONLY matter if you ever wanted to do such >conversions, but it would matter a lot then, especially if you had to >suffer a serious financial loss if you got the wrong carbon molecules at >the end of the process.) Sometimes I feel like I'm beating this geodesic metaphor like a dead horse sometimes... ;-). > >IF you wanted to settle for a totally non-convertible economy (like >rubles in the old Soviet Union, or like the LETS system on the net >today, as I understand it) then you could build it geodesically. Really? > But if >you want to be able to convert back and forth between Internet payment >systems and non-Internet payment systems, it can never be truly >geodesic. It will always be attackable at the points of conversion. >(You may "trade digital certificates", but how do you know the ones >you're receiving were obtained for legitimate real-world value?) >Because of this, the underwriting financial institutions, who have a >very reasonable desire to limit their own risk, will inevitably seek the >protection-by-traceability offered by something less than perfect >anonymity. We may not like it, but it's a very natural position to be >taken by those who are actually bearing the financial risks at the point >of conversion. That may be true, Nathaniel, but just because the people who bring the money off the net need to be identified to the digital cash underwriter's (actually the underwriter's bank's) satisfaction, doesn't mean that the trades on the net can't be totally anonymous. We've gone over this before. Let's build a model to talk about this, and then you'll see what I mean. Suppose I open an anonymous bank account with ATM card. Then, on the net, I buy digital cash from a digital cash underwriter. The web-page reads my ATM swipe and PIN, and then pumps it (without the underwriter being able to read it) through to my bank, who says to the underwriter, "Yup, there's money here, send it to him, and I'll wire it you (now/overnight/whatever)." The digital cash underwriter then issues me my digital cash, and I put it on my hard drive. I buy stuff on the net. I sell stuff on the net. Sometimes I go online with the trade to check my buyers' cash, sometimes I don't. Element of risk there, but this risk can be made accountable. It's probably always going to be cheaper to do offline transactions, but there's the possibility that when I cash in that money, it has been spent already. Fair trade. It's probably quantifiable and thus can be dealt with. We won't know till we have data. Being an astute businessman (you can tell this is a model, right?), I end up with positive cashflow. So, that money I don't invest with a portfolio manager on the net by buying anonymous bearer certificates for his mutual fund, ;-), I decide to take off of the net and buy Netscape puts, March 1996, $10. So, I go to the underwriter's page (maybe I go to multiple underwriters' pages, or maybe there's an enterprising third-party money changer who honors all comers for a cut), and I cash out. I swipe my ATM and punch my PIN, and my bank says to the underwriter "OK, I know that account, how much are you sending me?", and the underwriter says how much, and how and when the money would arrive (wire? Rollerblade messenger? bunch of militia types in a purple Hummer?, anyway...). And there's money back off of the net. In this model, there's no reason why I can't send an anonymous software agent to buy stuff for me, why I can't buy anonymously or sell anonymously. So, given that model, what's the problem? Now, I've also been thinking about something else. Wei Dai has been talking about how anonymity will always cost more, and certainly, in the model above, there's a certain risk with doing off-line transactions. You don't know if the cash in the transaction is double-spent, like I said above, but that "special stuff" has to be done to accomodate anonymity, which will always cost more. I'll come back with a whole blather on this next week when I get back from the CyberDog Kitchen (I'm here, and Gromit says "hi"), but I think it comes from what the default mechanism for commerce is going to be, threaded, audit-trailed x.blabla or anarchic, geodesic, bearer-certificates. I bet you can guess where I'm going to come down on this... Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA (617) 958-3971 "Reality is not optional." --Thomas Sowell The NEW(!) e$ Home Page: http://thumper.vmeng.com/pub/rah/ >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

3 2

Re: The "Future" Fallacy
by blancw＠accessone.com 17 Dec '03

17 Dec '03

From: Duncan Frissell 2) And no government on earth will find easy to decipher is an understatement. As I'm sure you know, properly deployed modern cryptography (or even the 100-year-old technology of one-time-pads) is mathematically infeasible to break. Though of course attacks other decryption remain possible. .................................................. I see what you mean. When I read his statement, I focused on the "will be able to transmit coded messages". I was thinking about the efforts of the govmt to prevent it, and about how nevertheless even a 10-year old will be able to accomplish it in spite of the efforts against it (GAK). .. Blanc

1 0

Re: Why Netscape employees should not leave
by Adam Shostack 17 Dec '03

17 Dec '03

I think that this logic (below) is off. GAK is evil. Pure and simple. If the market wants CKE/optional escrow for business thats one thing. The recent NIST meeting has shown that any system promulgated by the government will force on us a system with excessive kowtowing to the 'interests of law enforcement.' If people want CKE, and I think they do, then the government will get 90% of what it gets with GAK, with none of the fight. Most companies will happily turn over keys at the flash of a badge, never mind a warrant. (Was it Doug Barnes who pointed out that spying is more exciting than banking?) If it was easy, I'd probably have backup escrowed copies of my secret keyring. In Lichtenstien. This leaves us to ask, why GAK is such a big deal at NIST, if CKE will get them most of what they want? First, they haven't realized that CKE is most of what they want. Second, they're worried about the extra 10%. Drug dealers and terrorists not using it. (This points towords an eventual mandate for GAK, even if it starts out voluntary. Many have noted this.) Third, they've invested so much energy in the fight for GAK that they're emotionally tied to the idea, and they can't say 'well this would be almost as good.' Adam | The last sentence seems backwards to me - mandatory GAK is the real evil, not | non-mandatory GAK. (non-mandatory GAK is just a special case of voluntary | key escrow, where some of us might choose to escrow to /dev/null, some to | their attorney, some to a friend, and some to freeh(a)fbi.gov.) Non-mandatory | GAK makes me nervous, because it seems susceptible to back-door coercion | ("Dear Citizen: We notice that you've turned off GAK. Don't you trust us? | Please write back and tell us why you're no longer letting us have access | to your net traffic. Do you have something to hide?") but mandatory GAK | is the worst-case scenario being implemented immediately. | -- "It is seldom that liberty of any kind is lost all at once." -Hume

1 0

Re: Solution for US/Foreign Software?
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 8:06 AM 12/6/95, jim bell wrote: >>"Crypto hooks," basically the scheme you are proposing, were thought of by >>the authorities and are not a bypass of the crypto export laws. >>--Tim May > > >I'm not saying they are a "bypass" of the laws. Rather, I'm saying that >if the goal is to: > >1. Let companies like Netscape make foreign sales. > >2. Still comply with the letter of the law. > And I'm saying that your proposal does NOT comply with the letter of the law. There's no point in arguing this, as the facts are clear. Consult the ITARs and the previous discussions here and elsewhere on the practice of leaving "hooks" that crypto modules can later be attached to. >If the USG tries to take the position that "any program which can be >modified into another program that gets around GAK is prohibited from >export," then they're going to have to stop allowing the export of >pre-formatted floppy disks because they're likewise an XOR away from PGP. > >So we're back to square one: Does the USG intend to allow ANY programs to >be exported? No, the USG has not (yet at least) prohibited export of blank programs or disks. The "no hooks" rule has some ambiguities, but is by no means quite this dumb. All I'm saying is that you need to look at what the laws are, and how they have affected existing products and companies, before announcing a "solution." --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

Compliance Audits
by tcmay＠got.net 17 Dec '03

17 Dec '03

(This is just a tangential thought, inspired by someone's commentary. Not a substitute for first principles argument.) At 3:53 PM 12/6/95, Brad Dolan wrote: >Firearms dealers are requred to keep records of purchases. In theory >(and by law) they don't pass these records along to the authorities >except in response to specific inquiries. > >However, in the last couple of years there have been numerous reports of >mass copying of records by BATF or surrogates (specifics on request). > >And when a firearms dealer goes out of business, all records go to the BATF. > >So there is something of a precedent. One FFL holder reported someplace (?) that when he drops out of the business--soon, as the licensing and reporting requirements, plus the fees, have risen a lot--he expects to have an accidental "office fire" to destroy the boxes of records he's kept for the last 20 years. I think BATF is currently too preoccupied with other more pressing matters to go around and conduct "compliance audits," but such audits are likely to increase in the future. (Especially as the new FFL licensing rules and fees squeeze the number of FFL holders down to a "manageable" level, which was one of the stated reasons for cranking up the fees and tightening the reporting requirements a while back.) The connection with crypto and key escrow is that licensed escrow agents (Big Brother Inside) will likely face compliance audits. Some random amount of traffic may even be opened to ensure compliance. (More speculatively, the rules may be written so that compliance audits are done on the traffic of end-users, with some fraction opened and the contents measured to ensure they are readable. The old "Use a random number, go to jail" scenario.) --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

Re: Netscape Bug Bounty...
by an116512＠anon.penet.fi 17 Dec '03

17 Dec '03

In .cypherpunks, Jeff Weinstein <jsw(a)netscape.com> writes: > FYI, since both the bounty and the particular bug have been discussed >here... > free advert. > We are awarding Scott Weston $1000 for reporting the LiveScript history >problem. The announcement should show up on our Bug Bounty winner's >page by tomorrow. > hey, that'll make a real dent in the stock price (hint: three letters, 1st is s, 2nd is e, 3rd is c). > --Jeff > >Jeff Weinstein - Electronic Munitions Specialist why don't you at least try to be original, asshole? >Netscape Communication Corporation >jsw(a)netscape.com - http://home.netscape.com/people/jsw >Any opinions expressed above are mine. mostly yours, at least (except for the original parts). thief. > > --****ATTENTION****--****ATTENTION****--****ATTENTION****--***ATTENTION*** Your e-mail reply to this message WILL be *automatically* ANONYMIZED. Please, report inappropriate use to abuse(a)anon.penet.fi For information (incl. non-anon reply) write to help(a)anon.penet.fi If you have any problems, address them to admin(a)anon.penet.fi

1 0

News on Congressional Debate on Exon
by tcmay＠got.net 17 Dec '03

17 Dec '03

I just heard (12:15 EST) that the House has adopted language similar to the original Exon-Coates language in the Senate (as opposed to the White language, which was less restrictive in that it dealt with material that was "harmful" to children, interpreted to mean child porn). It looks like Internet Service Providers will soon be held liable for "indecent material" passed by their systems. I would expect most ISPs will drop the alt.binaries.* newsgroups as a first step, and maybe other groups as well. (Controlling Web page accesses is a much tougher problem, of course. so I wouldn't expect much action on this at first.) By the way, I recently discovered a new twist on "age credentials": the use of credit cards to prove age. One image site is asking for a "valid credit card number" to be given...not to use for charges, but just to do a quick verification (they claim a few minutes or less) that the card is valid and in the name of the person accessing their site. Some obvious security issue. An interesting twist, though. If the Exon Bill really does go into effect, and age limits on access are imposed, I'll be looking for what we've always joked about: the "Information Superhighway Driver's License." --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

3 2