December 2003 - cypherpunks-legacy

No. 8 / Re: Top 10 Ways to Make a Grouchy Old CypherPunk Smile
by bureau42 Anonymous Remailer 17 Dec '03

17 Dec '03

Top 10 Ways to Make a Grouchy Old CypherPunk Smile -------------------------------------------------- #10) Find his shoes for him. #9) Buy Kent Crispin a Dr. Kevorkian gift-certificate. #8) Lock. #7) #6) #5) #4) #3) #2) #1) [This space reserved for T.C. May]

1 0

Govt seeking emergency stay in Bernstein case
by John Gilmore 17 Dec '03

17 Dec '03

Date: Wed, 27 Aug 1997 13:43:36 -0700 From: Cindy Cohn <Cindy(a)mcglashan.com> Hi all, Just talked to Mr. Coppolino at the Justice Department. They are filing ex parte emergency stay papers tonight or tomorrow morning to try to stay the impact of Judge Patel's ruling pending appeal. He'll be faxing me the documents when they are ready. He said yesterday that they would seek to stay the "export" of crypto source code, although not the teaching or discussion (whatever that means). Cindy ************************ Cindy A. Cohn McGlashan & Sarrail, P. C. 177 Bovet Road, 6th Floor San Mateo, CA 94402 (415) 341-2585 (tel) (415)341-1395 (fax) Cindy(a)McGlashan.com http://www.McGlashan.com

1 0

subscripe
by Saitmacher, Klaus, Dr., DyStar 17 Dec '03

17 Dec '03

subscripe

1 0

Re: University logging mail to anon.penet
by Greg Broiles 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Jeff Simmons writes: > This just came up locally, and I'd like to have some comments on it, > especially from people who understand the law a lot better than I do: > > Our local University apparently has been logging ALL mail to anon.penet, > including faculty, students, and off-campus users. With respect to logging of student traffic, I'd look at the Family Education Rights Privacy Act ("Buckley Amendment", 20 USC 1232g) and the California analog to it (assuming one exists; Oregon's is located at OAR 571-20-005, et seq.). The release of information about individual students beyond "directory information" (e.g., name, dates of attendance, degrees granted, etc) is sharply limited without the consent of the student. Information about mail traffic sent and received is, IMHO, arguably (but not clearly) within "educational records" for FERPA purposes. To establish a Buckley Amendment violation (and I'm not saying there was one here) you'll still need to find a University employee to pin the disclosure on. If it's a University employee who posted them to the newsgroup, it's easy. If the University employee merely maintained those records in a place where an outsider was able to easily gain access to them, it seems like a bigger stretch. I had occasion to talk with a relatively high-level administrator in the University of Oregon's computer center some time ago and he explained that they've had to go to some trouble to make sure that gopher/WWW directories and other contemporary university computing practices don't fall afoul of the Buckley Amendment. Perhaps the powers that be at other places aren't quite so forward-thinking (or don't have the questionable benefit of being next door to a building full of law students with time on their hands). Perhaps an even longer stretch would be an argument that the practice of logging (and of keeping those logs in an insecure place) violates students (and others') right to privacy. Federal protection for a "right of privacy" is fickle, but California protects its citizens' right to privacy in its constitution. (I'm not an attorney (yet), don't live in California (right now) and consequently don't know much about CA law. So please think about this message as maybe a hint in (I hope) a useful direction, not necessarily the right answer. Feh.) This concrete issue seems like a good reminder of the implications of the way that we think about "cyberspace" and the things that happen when we use computers. If one thinks about a machine or a network as "public space", logging or reporting activities which happen there (e.g., Alice walks over to visit Bob, leaving footprints everyone can see in /var/adm/syslog) seems reasonable or at least not offensive, and it seems silly to talk about being angry because someone wrote down what everyone could see. But if we think about machines and networks as being private space, reporting on what Alice and Bob do seems tacky and rude at best, and horrifying (and likely to create liability) at the other end of the spectrum. As much as I dislike the "cyberspace" metaphor, its use or misuse has serious consequences. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBME6qJH3YhjZY3fMNAQHiQgP9HjqkwOzMabzXXbUKp0W7c2MAn4na5X1X UPVY8p70abNVpPoVFGQTUpgBnv3hBy40n5RFD9pNM7c2UPwq0C8Tcir9TBr+xEH7 L7iQCjsqIK5F1lv66C5yMFu8wfiRF10hMhTJYthOa04dyP10HovT2QameGw+DZHJ og1t7owgcco= =D5PV -----END PGP SIGNATURE-----

1 0

Le Monde: "Militant Cypherpunks liberate crypto software"
by Lucky Green 17 Dec '03

17 Dec '03

I am not making this up. Le Monde, a major French newspaper, discovered that "militant" Cypherpunks aid in the spread of crypto :-) In all fairness, the article is rather favorable. [Available in French only]. http://www.lemonde.fr/multimedia/sem3397/textes/act33971.html --Lucky Green <shamrock(a)netcom.com> PGP encrypted mail preferred. DES is dead! Please join in breaking RC5-56. http://rc5.distributed.net/

2 1

Collection of personal info
by David Neal 17 Dec '03

17 Dec '03

I sent this to the risks moderator some time back, but I guess he didn't like it. For those of you who think that perhaps people advocating cybercash are just a bunch of paranoid lunatics. -------------- As advertised in the trade magazine "DM News" (Direct Marketing News), Apr. 24, 1997, V. 17 N. 16. I've typed the entire text of the advertisement, any typos are mine. >From the huge number of people in the database, it would seem that TRW is now marketing a subset of their credit records they keep on everyone. Does anyone else remember the flap over Lotus' product (Magellan) that was going to allow something similar? The risks? This is the perfect database if you want to red-line your offerings. I'm sure others will have more creative answers. -------------- TRW DISCOVERED Some very smart people are uncovering exciting ways to increase response rates, find profitable customers, and develop new market niches. It's been a well kept secret. Now it's out. It's TRW. It all started with the search for more creative information solutions. Solutions that help you discover hidden markets and unique ways of using ordinary data to target qualified prospects. The result: a proven and massive database in the hands of people with real data management know-how. So far the findings have revealed: o A database of 170+ million consumers o 100+ demographic, psychographic and geographic selects o A full range of computer services. o Comprehensive motor vehicle data >From this comes an array of products and services to intrigue even the most seasoned direct marketer. One of these is called the TRW Smart Targeting Tools (SM). It links 98 million households with the goods and services they are most likely to buy. Choose consumer names by 50 neighborhood or 3600 household level clusters, by 56 broad product categories or by 516 specific product or brand preferences. Looking at all the advantages, TRW may be the direct marketer's find of this century. And the next. Energize your marketing. Contact your TRW representative or call 800.527.3933 Ext 640. You have a great find ahead of you. TRW Target Marketing Services Your one source for reaching all the right people. 701 TRW Parkway Allen, TX 75002-3717 800.527.3933 David Neal <dneal(a)usis.com> - GNU Planet Aerospace 1-800-PLN-8-GNU Unix, Sybase and Networking consultant. "...you have a personal responsibility to be pro-active in the defense of your own civil liberties." - S. McCandlish

5 5

Cypherpunks party videos
by Lucky Green 17 Dec '03

17 Dec '03

Good stuff from HIP keeps trickling in. See Brian the HIP brain. Witness Cypherpunks dancing. Watch your's truly as a DJ. http://www.ito.com/mpeg/hip/ --Lucky Green <shamrock(a)netcom.com> PGP encrypted mail preferred. DES is dead! Please join in breaking RC5-56. http://rc5.distributed.net/

1 0

Notes from NIS&T Key Escrow Export conference.
by Pat Farrell 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Here are my noted and remembered impressions from Wedensday's NIS&T conference on key escrow (aka GAK) export. Please note that there is a separate conference next week on creating a FIPS PUB standard for key escrow. That standard will be promulgated, just as GOSIP, POSIX and Clipper/Skipjack were promulgated. This export conference was separate from that FIPS standardization process. I got stuck in a construction traffic jam, and missed the introductory speaches. Perhaps one of the other c'punks can fill us all in on what I missed. The first item is that the export criteria will be changed. A small number of bits will be added to unescrowed crypto, and 64-bit escrow'd (GAK'd) systems will be allowed. They don't care which algorithm is used, DES, RC4, blowfish, etc. They care about key length. If it is short enough, it is exportable. The conference seemed to be an attempt to co-opt industry into agreeing that 64-bit GAK is much better than the current situation. After all, it would be too strong for a "hacker in France" to break it. When they opened the floor, there were a few comments/questions that indicated that not everyone was convinced that this was a good thing. I pointed out some graduate students don't consider "hacker" a compliment, and that I thought Damian did a great job breaking RC4-40. I also pointed out that it was broken again in 31 hours with a "bunch of commercial systems, Sun and Pentiums" with no need for suaercomputers. I then asked if the criteria were fixed, as setting criteria controls the result. The NIS&T approved board said that changes to the criteria was part of why the conference was being held. The next hour and a half was presentation from "industry." Essentially comments on the proposal. Nearly all of the spokesmen said that the criteria were flawed. Some said that they already had commercial products that met most of the real needs of the industry (key recovery) but they didn't meet the NIS&T/NSA "criteria." Probably the strongest was the condamnation by Robert Holleyman of the Business Software Alliance. Hollyman said that BSA represents firms such as Microsoft, Novell, Lotus, Sybase, SCO, Autodesk, and Intergraph. He said that current policy "directly threatens" the industry because of "The US Government's continuing refusal to adopt realistic export control policies." He went on and on. It was clear that his position is that the proposed policy is a mistake. After the presentations, there were more questions. I proposed one additional criteria (based on email that I received from the c'punks): How do we expire court approved access to encrypted data, so that once the court orders are over, the LEAs no longer have the ability to decrypt. The answer was that with clipper, special hardware is needed, and it goes away when the court order does. I asked how that model worked in a software only world. There were mumbled statements about adding it as a criteria. The conference then broke for lunch and breakout groups. The one I was in discussed criterias 5 and 6 of Topic 3, published in my URL http://www.isse.gmu.edu/~pfarrell/nistmeeting.html They are short enought to reproduce here. 5. The product shall be resistant to any alteration that would disable or circumvent the key escrow mechanism, to include being designed so that the key escrow mechanism cannot be disabled by a static patch, (i.e., the replacement of a block of code by a modified block). 6. The product shall not decrypt messages or files encrypted by non-escrowed products, including products whose key escrow mechanisms have been altered or disabled. After I commented that the person writing the notes has the ability to detirmine what was said, the folks from NSA and NIS&T asked me to take the notes. I love it; but I did try to be objective. In the middle of this discussion, a government-generated, but anonymnous paper was distributed. It had "Example Suggested Solutions." It suggeeted that source code not be available for products suitable for export. It also suggested other ideas, such as storing a checksum/hash and having the system "check the cryptographic code several times during its use." There was a strong reaction against these suggestions, not because they were bad ideas, but because the paper was delivered with no prior publication. This precluded any planned response to its ideas. We reworded #5 to say "want to Trust the Product." This means that it is untampered, works as expected, etc. We then hashed out ways to know this. The list ended up looking like: 1. is available only as object code 2. contains some "hash" function to check for modifications 3. contains some unique hash, with uniqueness based upon something like "site," "per copy" or "per release" 4. Contains policies against modification, such as liscense language against decompilation. 5. OS-related security, such as runs "protected mode" instead of as a wild DOS program. Of course, the software vendors went wild against "per copy" identifiers, saying it would add two orders of magnitude worth of problems to manufacturing. The items on the list were not "must have all of these" rather it was a pick-and-chose menu. We also required that the standard allow for technical innovation to keep up with the evolving state of the art. The discussion of #6 was more lively. We took a long time figuring out what it said. For instance, could ViaCrypt sell a product that was compatible with PGP 2.6.2 (non-escrowed) that also worked with the new escrowed ciphers? It seems to me, and a lot of other folks there, that such a product would be non-exportable. We simplified the criteria to: "right products won't talk to wrong products." with "right products" meaning those that are exportable, and wrong products being those that aren't, or are hacked, or ... We then developed "goals" including: 1. One version for sale worldwide 2. Allow development in the US 3. Domestic Law Enforcement Agencies want Escrowed (I almost wrote GAK :-) 4. Must interoperate with everything 5. Receiver can only decrypt if escrow agencies can decrypt. This leads to a bunch of issues and observations, including: a. Can goals 1, 2, and 4 be met simultaneously? There was a suggestion of a "friendly man-in-the-middle" who would receive a GAK'd conversation, and strip off the GAK parts, and reencrypt it, and retransmit it to a non-GAK user. Which leads to: b. Can we prohibit a friendly MITM? The big issue was: c. Startup compatibility. No one will buy products unless they have sales attractiveness. This means compatibility with existing systems. Yet the criteria #6 seems to say that approved products must refuse backwards compatibility. This was labeled a "non starter" by the group. The consensus was that companies can develop a substantial competitive advantage by developing off-shore and offering both escrowed encryption and compatibility with existing systems. There was a discussion of grandfathering in some technologies. This was to help interoperability. The conversation became fuzzy, Grandfather technologies included DES, 3-DES, IDEA, and long key RC4. One key idea was that it may make sense to allow software that encrypts with escrowed keys, but can also decrypt with any algorithm. This allows the LEA's to access outgoing messages, while allowing interoperability. The discussions frequently wandered to discuss the language of the criteria. The wording was considered simultaneously too subjective and impractical. For example, we considered the phrase "tamper resistant" to be preferable to the original "prevent tampering," because it is impossible to absolutly prevent modification to software. The issue of interoperability was raised repeatedly. It is critical that exportable products interoperate with other, existing export products. The last issue in the session was that the length of the key, 64-bits, was defined in criteria #1. There was no discussion at the conference on this criteria. It seems that the NIS&T and NSA folks believe that this is a closed topic. The folks in the session did not agree. They felt that 64-bits was not enough. Once the breakout session was over, the entire conference met together, and the "reporter" from each session reported their comments and findings. All breakout sessions had suggested changes. The group that discussed criteria #9 recommended removing it. The group that discussed criteria #2 (no multiple encryption) reported that industry was working on a general solution to the problem of key recovery, and that their solution would probably appear as quickly without the government's "help." Several groups identified that there are at least two separate problem domains: communications and data storage. Communications typically is short term, and has unique keys for each session. Data storage has far fewer keys that are used for long periods. Several speakers suggested that while communications keys were not suited to be escrowed, there was a large need for key recovery for data storage. There was no response from the government representatives to any of these points. One government speaker did say that there would be a Federal key escrow standard, period. After the combined session, there were more break-out sessions. In the one that I attended, the folks from National Semiconductor described their CAKE system. This is a smartcard/PCMCIA device that uses 2000+ bit public/private key encryption and signatures. They are hoping for export approval; it is necessary for the project to be viable. The system looks pretty interesting, but it too complicated to describe here. In short, random session keys are generated and signed with a Data Recovery Center's public key. The LEAs could then send encrypted session keys to the DRC, which would decrypt them, and return the unencrypted session keys which the LEA could then used to decrypt the messages. While this is a hardware system, its concepts could be transfered to a software implementation. One obvious problem is that NS' system doesn't meet criteria #8 (retuiring repeated involvement of the escrow agent), since it may require hundreds or thousands of session key decipherments. It also has a number of attractive features, such as never sending the private key anywhere, only the session key is escrowed. The general discussion showed concerns that in the international community, requiring government escrow may cause lose of valuable data, as some foriegn governments are not as trustworthy as the US. It was the consensus that requiring users to have 50 or more escrow centers was unworkable. Yet this could be required for large multinational companies working in 50 or more countries, if each required a local key escrow service. The NS model would allow both date stamping of session keys, and periodic rekeying. Either would satisfy my "unaccepted" Citeria #11, technical limits to the time that a court ordered decryption could be executed. There was a discussion of changing the criteria so that only the transmission of data was concerned with escrow. This would simplify the issue of multinational escrow. We did not resolve whether this would be sufficient or acceptable. Today, we will talk about suitable escrow agencies. Pat -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBME7WOLCsmOInW9opAQHbawP+PSC+9p7ll7yKTiwnkzrIf+aT/ZfuoCqj Fp6ZhykIoJQVF5YAEhz9O1t9FKOauo3baMDhaIvU4pUSm2b/hKlUFB8cwYr7KTjd MFGxTOG/D7blGuX6ZXbHlS5EkKeT1pDtfrd9GlnTKWHxfga/51ROWCG/33BWZxHR lyNLI07UPbo= =kFkC -----END PGP SIGNATURE----- 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

IDEAL FOR BEGINNERS WORK-AT-HOME
by rewards＠t-1net.com 17 Dec '03

17 Dec '03

/////////////////////////////////////////////////////////////////////////////// This Message was Composed using Extractor Pro Bulk E- Mail Software. If you wish to be removed from this advertiser's future mailings, please reply with the subject "Remove" and this software will automatically block you from their future mailings. //////////////////////////////////////////////////////////////////////////////// I have been a business owner for over 30 years, involved in various things, and I have found different strategies for making money, working at home.... I thought you might like to know, this really works, if you will only try it... For more information send e-mail to max(a)answerme.com

1 0

Bernstein decision: image files upgraded
by John Gilmore 17 Dec '03

17 Dec '03

If you couldn't read the decision because the original image files were too fuzzy, try them now. They're wider and longer, and a lot easier to read. They're almost as small as the previous ones, because we encoded them better. We're still working on scanning it in to plain text. http://www.eff.org/pub/Legal/Cases/Bernstein_v_DoS/Legal/970825_decision.im… John Gilmore

1 0