December 2003 - cypherpunks-legacy

re: NIST GAK export meeting, sv
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 3:35 AM 12/6/95, Anonymous wrote: >Tim May 12/5/95 6:25 PM: >>One "defensible" (and maybe even good) reason is because someone with >>government clearance can then be prosecuted for leaking what they know, >>whereas ordinary citizens are harder to prosecute for this. I doubt this is >>the main reason, but it makes a certain kind of sense. > > Nice point, though I too doubt that's the reason: if *every* agent >needed to be cleared, then this clearance stipulation would serve nicely, >but if only *one* at every escrow agency needs to be cleared... No, I didn't make that basic a logical blunder. What I was thinking, even if I didn't go into it, is that the "cleared" agent would be the one within the office who would actually handle the surveillance. But I do think the more basic reason is really that the intelligence agencies want a direct channel to "their" guy. I'm really pleased to hear about the 20% attendance. Nothing trivializes a program more than being ignored. --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

Solution for US/Foreign Software?
by jimbell＠pacifier.com 17 Dec '03

17 Dec '03

Manufacturers of handheld ham radios have to make them for at least three markets: Japan, US, and Europe. Since these devices are usually based on the same LSI chip for control, customization is usually done by installing/not installing certain tiny surface-mount devices (diodes?) on the PC board, which tells the "boss MOS" which frequency band edges to work with, etc. Getting these radios to receive or transmit "out of band" is usually a simple matter of modiying these radios by adding/removing/moving these diodes to a different position. The instructions on how to do this custom operation are not included with the radio itself, but the information always seems to get out there, and you can buy books which show the mods for practically every such radio in existence. Okay, the problem as I see it is that USG doesn't want to approve encryption software for export that can use "excessively long" keys, yet Netscape (and others) want to be able to sell outside the country with full-feature encryption. I think I have a solution. 1. Write a program with limited encryption (40 bit?), with the encryption module in a file external to the main program. 2. Get export approval for this program. 3. Write a module which replaces the encryption file, increasing key size to whatever you REALLY wanted in the first place. (128-bit IDEA, 2000-bit PGP, etc.) 4. Ship that new module with the old software to US customers. Naturally, that new module will "leak," so anybody who buys the old program out of the country can convert to a fully-functional version by downloading it from a foreign bbs that just happens to have it. The module can be encrypted/signed by the manufacturer so everyone can be sure of its identity and genuineness. Better than nothing, I suppose.

1 0

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

17 Dec '03

jim bell proposes "crypto hooks": >1. Write a program with limited encryption (40 bit?), with the encryption >module in a file external to the main program. >2. Get export approval for this program. >3. Write a module which replaces the encryption file, increasing key size >to whatever you REALLY wanted in the first place. (128-bit IDEA, 2000-bit >PGP, etc.) >4. Ship that new module with the old software to US customers. >Naturally, that new module will "leak," so anybody who buys the old >program out of the country can convert to a fully-functional version by >downloading it from a foreign bbs that just happens to have it. The >module can be encrypted/signed by the manufacturer so everyone can be sure >of its identity and genuineness. > > >Better than nothing, I suppose. "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 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 gives in to key escrow
by James A. Donald 17 Dec '03

17 Dec '03

At 04:59 PM 12/4/95 -0600, Scott Brickner wrote: >Netscape has pretty clearly said that they don't like the idea of GAK, Actually netscape has not said that: Jeff has said that netscape *will* say that real soon now. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

2 1

Re: The "Future" Fallacy
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 7:24 AM 12/6/95, blancw(a)accessone.com wrote: >From: Duncan Frissell > >Bill Gates (like Mister Newt before him) committed what I call the Future >Fallacy in "The Road Ahead." Page 106. > >"Soon any child old enough to use a computer will be able to transmit coded >messages that no government on earth will find easy to decipher." >................................................... > > >Billg is an optimist. > >What's wrong with this picture, Duncan? I found nothing wrong or incorrect with the quote Duncan attributed to Bill Gates (I haven't read Gates' book). I couldn't understand Duncan's koan, shrugged, and moved on. --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."

6 6

Re: Solution for US/Foreign Software?
by jimbell＠pacifier.com 17 Dec '03

17 Dec '03

>>1. Write a program with limited encryption (40 bit?), with the encryption >>module in a file external to the main program. >>2. Get export approval for this program. >>3. Write a module which replaces the encryption file, increasing key size >>to whatever you REALLY wanted in the first place. (128-bit IDEA, 2000-bit >>PGP, etc.) >>4. Ship that new module with the old software to US customers. >>Naturally, that new module will "leak," so anybody who buys the old >>program out of the country can convert to a fully-functional version by >>downloading it from a foreign bbs that just happens to have it. The >>module can be encrypted/signed by the manufacturer so everyone can be sure >>of its identity and genuineness. >> >> >>Better than nothing, I suppose. > >"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. Then this would be an excellent way to achieve both those goals. (I accept as axiomatic that if the only exportable encryption is GAKked, they're not going to be viewed seriously as a product. A way around GAK would actually increase their profits.) BTW, the fact that they might be "thought of" by the authorities is not going to be enough to stop them. If the USG claims that it WILL approve GAK-ified software, it is unclear how they will decide if a given program qualifies. Since every program of length "N" is only an XOR away from every OTHER program of length "N", modifying or disabling this software is always possible. Remember, the reason (or, at least, one of them!) they put Clipper into a physical chip as opposed to releasing the algorithm was to prevent modifications that would subvert the algorithm. Their decision to allow software key-escrow presumably forces them to accept certain possibilities they otherwise wanted to avoid. 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?

3 2

No Subject
by Bryan Strawser 17 Dec '03

17 Dec '03

Gondolin Technologies is proud to announce a new nymserver for the online community at <alias(a)nym.gondolin.org>. This is the same service that is presently provided to the net at alpha.c2.org, utilizing software written by Matt Ghio <ghio(a)c2.org>. A nymserver allows any person with access to email to anonymous create an alias at <username(a)nym.gondolin.org> through which they may send/receive email. This psuedonym is completely anonymous, and the identity of the user cannot be revealed as it is contained within a PGP encrypted reply block (unlike anon.penet.fi). For more information, send a message to <help(a)nym.gondolin.org> and the help file with directions will be automatically sent to you. The PGP public key for the alias-creation address is below: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzC9I5YAAAEEAOvpLWjR1klfwpoQOtMA/qGsMtVtjtblpvNiMMkTxX3NVzib WnN1ZwhvLY3P/SqduLF2U4yzH6jVKiJJjzQG082K2MuW6wtl1GJYuw1/EPKDrBHj ksmvyXkX+DNOj/3cH6aKSlYALNClVF4yZkr3NTWE6Phr9LEREuSoorTnBJytAAUR tDFHb25kb2xpbiBBbHBoYSBOeW1zZXJ2ZXIgPGFsaWFzQG55bS5nb25kb2xpbi5v cmc+iQCVAwUQML6SAo6H3ZT4asdZAQE3uwP/aazOIAYzUBHs/oLhtCc4auE8jF6k wue/3JJq/ECpGskOYsggQAp98FPmLFzJfxgEREaC5vBt9Rac71IMwJ0r9PUp59bz n85bgem+lVxL0VmMR9sTsW9bYGkMGdSIvN8Q0gJHkCUXCMq2/Vp3dVXP4j2QCOFK RuuhlkCD2nqHCd2JAJUDBRAwvorfF139v5zDbCEBAXMxA/45lRrmTn4BpGt0qbiR Nr3XPh+ftQb3lQ0XDuwTDODgv/FjGiU2dM7v85tZAR8e2p7AeHoKvxFVJivP2/rR GqAHoOh52O4s6Zf1EhqsDAsFYthCjRNK8ASaUWLTljmx7kCQXiTWwPcJHnvHeXe5 nGnoXolVlZk7R5gFTAR7HkrNaIkAlQMFEDC9Jf370BoEO1CTGQEBuj4D/0amfilf Cli23RngrLM8FLYo7HQoL5vG6IO/d6hedeiQG+9KeSTnyeiWHXsAYjZ8TNQ5pPyt IUhsPxO9AkdYqW9oXqwRUfrkhhPS+R8eg1IN2kpdNsKiJvibhnuHZGOhmgc45yin eJ6kD/vuOg5gZXRIOCUd5usz1xyx0J7c50cj =5gm8 -----END PGP PUBLIC KEY BLOCK----- Please direct any complaints, comments, or concerns to <admin(a)nym.gondolin.org>. -Bryan Strawser, System/Network Administrator, Gondolin Technologies

1 0

Untraceability in Mobile Networks
by Loren James Rittle 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- FYI, at MobiCom '95, an ACM sponsored conference, an interesting paper entitled, _Untraceability in Mobile Networks_, was presented. The authors of the paper are Didier Samfat, Refik Molva and N. Asokan. For order info contact: acmhelp(a)acm.org ACM ISBN: 0-89791-814-2 ACM Order Number: 533952 As per the ACM rule, ``Abstracting with credit is permitted,'' I abstract ideas from the paper below. - From the paper's abstract: ``User mobility is a feature that raises many new security-related issues and concerns. One of them is the disclosure of a mobile user's real identity during the authentication process, or other procedures specific to mobile networks. Such disclosure allows an unauthorized third-party to track the mobile user's movements and current whereabouts. Depending on the context, access to any information related to a mobile user's location without his consent can be a serious violation of his privacy.'' The paper, along with other ideas of interest to the Cypherpunk, presents a classification system for arguing about the tradeoff between user authentication, user privacy (with respect to various entities in the network), user billing and user conveniences (such as, ``can others find the mobile user through his home agent?'') in mobile networks. The rest of the paper uses the classification scheme, which really is just a convenience way of mapping all the players in the network to the information they are allowed to ever know about a user that has an expectation of a certain level of privacy. The classification scheme models the following useful information regarding users: the full identity of the user f, the identity of the user's home domain h, and the identity of the user's current remote domain r. The classification scheme has the following players: User U, Home Domain/Authority H, Remote Domain/Authority R, Legitimate Network Entities L, and Eavesdroppers E. They assume U always knows everything about itself, so they ignore it from the discussion. Notice that they model no `GAK (Government Access to Key)' or, in this case, `GAI (Government Access to Identity)' agent. After laying the groundwork, the authors then set about to discuss the matrix of known information, according to their classification system, for various interesting cases: C1: Hiding User Identity from Eavesdroppers; C2: Hiding User Identity from Foreign Authorities; C3: Hiding Relationship Between the User and Authorities; C4: Hiding the Identity of the Home Authority from Foreign Authorities; and C5: Hiding User Behavior from Home Authority. The cases offer more privacy from C1 to C5. See the paper for the exact mapping of C[1-5] to the knowledge matrix involving f, h, r verses H, R, L, E. The authors, quite correctly, label C5 as in direct contrast to the intent of a ``big brother'' principle since ``no entity [other than the user] has any information about the user.'' Attaining C5 in a system would really be the ultimate in user location/action privacy. The authors do not discuss the issue, but it appears to be an open question whether, in light of a conspiracy involving authorities, whether or not C5 could actually be attained for a mobile user in a network. Note: At the other end of the privacy spectrum is the unlist C0 case. This correspond exactly to the classic cellular phone system in that nothing is hidden from eavesdroppers. Every relationship box on the knowledge matrix for case C0 is set to true. Next, the authors address how the levels of privacy affect and are affected by other, non-security related, areas of system requirements. For example, to make the highest levels of privacy work with cross-authority guaranteed billing, some form of anonymous, non-repudiable digital cash might be required. The paper goes on to discuss how GSM, for both voice and packet data users, and CDPD fail to even completely cover the simplist of privacy cases, C1! The authors construct a protocol that provides privacy levels C1 and C2, then enhance the basic algorithm to provide a hybrid privacy level somewhere between C4 and C5 (they do not solve all the privacy problems present when the home and foreign authorities are involved in a conspiracy --- they do, however, worry about foreign authorities involved in a local conspiracy amongst themselves). Finally, the authors give a proof of correctness for the basic algorithm, an evaluation of its performance and compare their design to other possible designs. In sum, this paper is a must read for all Cypherpunk's interested in the topic of untraceability and user identification privacy in mobile networks. To me, the paper appears to extend the state of the art in several directions since it applies Chaum's, and other's, ideas to mobile networks, where some tradeoffs are different from wired, stable networks and some problems are entirely new. As a final aside, none of the authors could be present to give the talk related to the paper, so the advisor of one of the students, Jay Black of the University of Waterloo, gave the talk. He mentioned that he did to not understand why this area of research was important. Apparently, he has never heard the Cypherpunk's privacy message. However, he was quite a good sport about presenting the paper. Later, in the question period --- a guy, later outed as with the U. S. government --- raised the same issue in a more hostile tone. All I can say to the unknown G-Man, ``Are you totally clueless? This is a country that was founded upon the principles of anonymous speech and one's right to privacy. It is about time that the people restore these lost freedoms through technology alone, if possible, or on the political scene, if required.'' Regards, Loren - -- Loren J. Rittle (rittle(a)comm.mot.com) PGP KeyIDs: 1024/B98B3249 2048/ADCE34A5 Systems Technology Research (IL02/2240) FP1024:6810D8AB3029874DD7065BC52067EAFD Motorola, Inc. FP2048:FDC0292446937F2A240BC07D42763672 (708) 576-7794 Call for verification of fingerprints. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMMVZ+/8de8m5izJJAQFL9AQAhwzqlJK4fnsnCs09XO7Mnhfej1z+eHrQ ALhAVNSYphH1qvLAM4veRr+Af+XoP0QO7s6GXu+IHlR5b0r8Qy9qKw5XeIeGra4d wuqrVngKAd6Pm0G2Gdj6+4ERoNJL9xwIvfswUyMNAai8K+rnqBE9F/yTTRn363T+ dT9CkMq+Wqs= =MP9H -----END PGP SIGNATURE-----

2 1

GAK
by SBinkley＠atitech.ca 17 Dec '03

17 Dec '03

I heard a while back about being able to "split" up a PGP key. What about splitting up the key into many parts, and giving them out to multiple INDEPENDANT agencies. ie: One piece goes to the FBI, one to the NSA, one to some other committee, and so on. That way, no goverment body could just tap your conversations without getting approval from others, and gaining the pieces of your key. just a thought

2 1

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

17 Dec '03

At 6:21 PM 12/6/95, jim bell wrote: >NO! You didn't read my commentary carefully enough. These "hooks" (your >words) will, in effect, already be connected to encryption software weak >enough to make NSA happy. You know, 40 bit keys or something like that. >But instead of being in one large file, embedded into a program, it'll be >TWO files. Simple programming change. Everything that >implements/defines/limits the encryption to 40 bits will be in the smaller >file. >This really isn't a "hook," it's an internal connection between two >portions of the same program. (actually, it wouldn't need to be in two >separate files; a file which implements a patch for the first file would >work great.) > >It'll be exportable, because its key size is "acceptable." At the time >the export license is requested, the replacement module to increase key >size probably won't even exist, in order to avoid giving the USG an >excuse to deny the export license. After the license is obtained, the >replacement module is written and shipped to domestic users. > >I fully realize the USG won't "like" this kind of thing. But if they are >trying to take the position that certain kinds of encryption software CAN >be exported, and some can't, they're going to have to approve SOME >programs for export, using criteria which at least pretend to be >objective. Yes, I read your proposal. The "hooks" term is not my coinage, but refers to this general idea. I urge you to read what others, including companies, have had to say on this matter. Much of the debate on "interoperability" revolves around details of entry points to crypto modules and such hooks. No point in arguing with Jim on this anymore, so I won't. Good luck, Jim, in introducing such a product. --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."

2 1

re: Secret Clearance
by Robert A. Rosenberg 17 Dec '03

17 Dec '03

At 21:00 12/5/95, Pete Loshin wrote: >>From working at an organization that did a lot of government work, >my understanding of the process of clearing employees is this: > >-certain tasks require knowledge or access that must be restricted >-you have to have a high degree of trust in the people doing those tasks >-people with money troubles, out-of-control addictions, skeletons in the > closet, and histories of "troubles" are prime targets for subversion >-doing a clearance check (in theory) eliminates the possibility that > these people will be blackmailed/bribed into revealing their secrets The problem is that they are subject to blackmailed/bribed/subversion ONLY because the employer will use the info as an excuse for firing/restricting the employee. If someone has a "skeleton in the closet" such as being gay, so long as the employer does not discrimate against gays who INFORM the employer of their sexual orientation or if the employer does not care about the person being gay (ie: removes it a potential blackmail threat) there is no problem so far as I can see. It is only when there is something that is WORK RELATED which would affect the person's performance if not known that the question of a background check is relevant.

2 1

Re: NIST GAK export meeting, short version
by Pat Farrell 17 Dec '03

17 Dec '03

Just a quick note to explain what the govies claimed was the reason for the SECRET clearence.... They claimed it was needed so that they can serve a court order that is SECRET. Obviously, if the order is classified, then no one without clearence can see it -- the existance of the clearence is classified. The main area that they claimed was for FISA orders. FISA stands for something like Foriegn Intellegence Survellance Act. It is aimed at catching spies. The whole topic raises a ton of questions, such as traffic analysis when your _only_ cleared operator has to process a request. Plus, since you have to be a US citizen to get a clearence, how can there be approved foriegn escrow agents? And the usual, why in hell would a competent spy use crypto escrowed in the US? I'll put more in the long report. 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: The "Future" Fallacy
by Duncan Frissell 17 Dec '03

17 Dec '03

At 01:10 AM 12/6/95 -0800, Timothy C. May wrote: >I found nothing wrong or incorrect with the quote Duncan attributed to Bill >Gates (I haven't read Gates' book). > >I couldn't understand Duncan's koan, shrugged, and moved on. > >--Tim May >From my reply to someone called billg(a)microsoft.com: >>"Soon any child old enough to use a computer will be able to transmit coded >>messages that no government on earth will find easy to decipher." >> >>DCF The two "errors" in the sentence are: 1) The use of the future tense. There are a host of encryption products available today that are very strong. Unless you were talking about ease of use. Newt Gingrich -- in a similar statement -- was speaking generally rather than about children and that's where I noticed the error before. It is a present not a future capability. 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. Both of these are really quibbles rather than substantial criticisms. DCF "Who wonders if this is the real BG or one of the 90% of forged messages mentioned in the National Press Club speech."

1 0

re: Secret Clearance
by Pat Farrell 17 Dec '03

17 Dec '03

In message Wed, 6 Dec 1995 06:57:12 -0500 (EST), Jay Holovacs <holovacs(a)styx.ios.com> writes: > I think it's interesting that police and even FBI that normally operate > "legally authorized" wiretaps do not require SECRET clearance. What > really goes on here? You can't walk the halls of the FBI headquarters without a clearance. The RBOCs do have cleared people that perform the taps. 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

ERA_sur
by John Young 17 Dec '03

17 Dec '03

There's implicit boost for encryption in the controversial "undeleting" of personal files on Jean Lewis's floppy, subpoenaed by Whitewater investigators. Peter Wayner has a thread about it on Cyberia-L. NYT had a brief about it yesterday, WSJ an editorial today. ERA_sur

2 1

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