December 2003 - cypherpunks-legacy

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