December 2003 - cypherpunks-legacy

Escrow system design query
by Michael Wilson 17 Dec '03

17 Dec '03

Does anyone know of a solid document out there in the web that actually describes the proposed key escrow backbone network? After wading through considerable junk in the search engines (my, but the net is wordy on the topic), I didn't turn up anything that looked like architecture. MW

7 7

National Security Committee amendments to SAFE
by Greg Broiles 17 Dec '03

17 Dec '03

Got a fax from Dellums' office this afternoon (finally!) with the amendments from the National Security committee to SAFE - this will be on the web at <http://www.parrhesia.com/safe-dellums.html>. --- AMENDMENTS TO H.R. 695 OFFERED BY MR. WELDON AND MR. DELLUMS Strike Section 3 and insert the following: SEC 3. EXPORTS OF ENCRYPTION. (a) EXPORT CONTROL OF ENCRYPTION PRODUCTS NOT CONTROLLED ON THE UNITED STATES MUNITIONS LIST. - The Secretary of Commerce, with the concurrence of the Secretary of Defense, shall have the authority to control the export of encryption products not controlled on the United States Munitions List. Decisions made by the Secretary of Commerce with the concurrence of the Secretary of Defense with respect to exports of encryption products under this section shall not be subject to judicial review. (b) LICENSE EXCEPTION FOR CERTAIN ENCRYPTION PRODUCTS - Encryption products with encryption strength equal to or less than the level identified in subsection (d) shall be eligible for export under a license exception after a 1-time review, if the encryption product being exported does not include features that would otherwise require licensing under applicable regulations, is not destined for countries, end-users, or end-uses that the Secretary of Commerce has determined by regulation, with the concurrence of the Secretary of Defense, are ineligible to receive such products, and is otherwise qualified for export. (c) ONE-TIME PRODUCT REVIEW - The Secretary of Commerce, with the concurrence of the Secretary of Defense, shall specify the information that must be submitted for the 1-time review referred to in subsection (b). (d) ELIGIBLE ENCRYPTION LEVELS - (1) INITIAL ELIGIBILITY LEVEL. - Not later than 30 days after the date of the enactment of this Act, the President shall notify the Congress of the maximum level of encryption strength that could be exported from the United States under license exception pursuant to this section without harm to the national security of the United States. Such level shall not become effective until 60 days after such notification. (2) ANNUAL REVIEW OF ELIGIBILITY LEVEL - Not later than 1 year after notifying the Congress of the maximum level of encryption strength under paragraph (1), and annually thereafter, the President shall notify the Congress of the maximum level of encryption strength that could be exported from the United States under license exception pursuant to this section without harm to the national security of the United States. Such level shall not become effective until 60 days after such notification. (3) CALCULATION OF 60-DAY PERIOD. - The 60-day period referred to in paragraphs (1) and (2) shall be computed by excluding - (A) the days on which either House is not in session because of an adjournment of more than 3 days to a day certain or an adjournment of the Congress sine die; and (B) each Saturday and Sunday, not excluded under subparagraph (A), when either House is not in session. (e) EXERCISE OF EXISTING AUTHORITIES. - The Secretary of Commerce and the Secretary of Defense may exercise the authorities they have under other provisions of law to carry out this section. Amend the title so as to read "A bill to amend title 18, United States Code, to affirm the rights of United States persons to use and sell encryption." [Note - title 18 is the criminal section of the US Code. SAFE's original title was "To amend title 18, United States Code, to affirm the rights of United States persons to use and sell encryption and to relax export controls on encryption."] -- Greg Broiles | US crypto export control policy in a nutshell: gbroiles(a)netbox.com | http://www.io.com/~gbroiles | Export jobs, not crypto.

7 8

RE: "Notes" to be Eclipsed by "Netscape"
by Pete Loshin 17 Dec '03

17 Dec '03

Timothy C. May[SMTP:tcmay@got.net] wrote: >At 6:52 PM 9/25/95, Jon Lasser wrote: > >>Perhaps the Notes pricing scheme is sooo outrageous (by the standards of >>a student like myself, and probably most others, if it's still anything >>like it was at the 1.0 release) that mostpeople have had zero opportunity >>to examine the program, let alone really have time to play with it? > >I've never even _seen_ a copy of Notes running on any machine, nor do I >know directly of _any_ of my colleagues who has. (Not saying nobody has, of >course, just that I can't find anyone I know well who has.) I've used Notes myself (and have written about how it and Notes add-in apps are used). Yes, it was overpriced, but they came out with a less-featured, less-expensive version (which I haven't seen). Based on my experiences, it appears to be a choice for rigid/business management/TQM types in big corporations, among others. >I've been following the news on Notes for at least several years, even to >the point of buying some Lotus stock several years ago on the strength of >what I had read about Notes. (Alas, I sold it soon thereafter, before a >run-up in price.) > >My point? Notes is nearly invisible in the non-corporate community I now >hang out in. No question about that. You need a dedicated server, server software and, at least a year ago, it all cost something like $500+ per seat to setup. Plus, it doesn't do you any good unless you are working in a workgroup. >Who knows what weaknesses or bugs it has in it. Folks on our list probably >don't have much familiarity with it. I only just subscribed to this list, and by all rights should probably spend more time lurking; that said, Notes includes encryption and digital signature. >My hunch is that, as the "Wall Street Journal" reported yesterday, that IBM >overpaid for Lotus, that the notion of Notes becoming the universal >collaboration/communication option is flawed. There has been growing sentiment among certain sectors that workgroup computing is the wave of the future. Unfortunately, given IBM's track record, their purchase of Lotus seems to doom it to a fate similar to OS/2: an excellent product with a track record, with a small but fervent following, which will soon be eclipsed by some less-featured, newer product that makes someone a pot of money (like CollabraShare). Notes end users have always seemed to feel it had too much power and was not easy to figure out how to use; Notes programmers love it, and there are lots of addins. With Notes going to IBM, Netscape seems to have made another very clever move--while it still doesn't justify the overall stock price, it does justify the rise associated with that move. >(I've been saying for a while that the Web serves that purpose better, and >that Web browsers will likely edge out Notes. Apparently I was hardly >prescient, as Netscape recently bought Collabra, which is pushing that >point exactly.) Notes uses replication to distribute data across networks; there are better ways to have people compute remotely in my opinion too (not sure WWW is THE answer, but it certainly is one of them). >--Tim May -Pete Loshin peter(a)world.std.com

4 3

[NOISE] Re: SAIC bought InterNic, but who is SAIC? A spook contractor!
by Bill Stewart 17 Dec '03

17 Dec '03

>SAIC's board members include Admiral Bobby Inman, former NSA head and deputy >director of the CIA; Melvin Laird, Nixon's defense secretary; and retired >General Max Thurman, commander of the Panama Invasion. Recently departed >board members include Robert Gates, former CIA director; William Perry, >current Secretary of Defense; and John Deutch, the current CIA director. ... >"At the very time the Internet community is struggling with the issues of >encryption and privacy, I'm more than a little uneasy to find this bunch of >ex-spooks sitting at the very entry point of the Net," says Jim Warren (a Yeah, that _is_ a pretty spooky bunch; I don't know if anybody'd have standing to do a conflict-of-interest or governmental ethics case of any sort, since it is more or less a monopoly? [BEGIN NOISE] On the other hand, I suppose I'd rather have the CIA making money by selling directory services than, say, dealing cocaine or collecting graft from third-world governments :-) [END NOISE] >Current SAIC government contracts include re-engineering information systems >at the Pentagon, automation of the FBI's computerized fingerprint >identification system, and building a national criminal history information >system. SAIC's a fairly generalized contracting firm, specializing in study contracts and other front-end work rather than back-end implementation grunt-work; I'm not surprised by the list. #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Cypherpunks Fax Service
by sameer 17 Dec '03

17 Dec '03

I see a potential business opportunity for enterprising cypherpunks: People have been posting things saying "we should have press releases". People have been posting useful information regarding fax numbers of reporters around the country and such. In this I see a potential low-maintenance business opportunity for some enterprising cypherpunk with a high-grade fax machine. There is no way anyone can make a 'Cypherpunk press release' because there is no "Cypherpunk Organization". There -are- however, cypherpunks organizations. Community ConneXion is one, for example, and others such as COMSEC partners may be considered cypherpunk organizations. Some enterprising cypherpunk may wish to sell the services of their fax machine so that cypherpunk organizations don't need to invest the time towards building up a good database of press fax numbers. For some fee a cypherpunk organization would send only to the service a press release, and the service would make sure it reaches all the people in the press who find cypherpunk topics interesting. Hell, if no one sets this up before I get my own mass-faxer setup, I might just do it myself. -- sameer Voice: 510-601-9777 Community ConneXion FAX: 510-601-9734 An Internet Privacy Provider Dialin: 510-658-6376 http://www.c2.org (or login as "guest") sameer(a)c2.org

1 0

COMMUNITY CONNEXION TO OFFER REWARD FOR HACKING MICROSOFT
by sameer 17 Dec '03

17 Dec '03

For Immediate Release Contact: Sameer Parekh 510-601-9777 (Pager: 510-321-1014) COMMUNITY CONNEXION TO OFFER REWARD FOR HACKING MICROSOFT Sept. 29 1995 - Community ConneXion, an Internet Privacy Provider in Berkeley, CA, announced today that it will be providing awards to people who find and publicize security holes in Microsoft products. "Microsoft claims to be promoting secure transactions on the net," said Sameer Parekh, founder of Community ConneXion, "We will prove them wrong." Microsoft has been quoted making disparaging comments about their competitor Netscape's product, Netscape Navigator. Community ConneXion has also been offering a reward to expose holes in Netscape's products. "We target widely used programs," said Parekh. Parekh expects that many bugs and flaws in Microsoft's security software will be found. People want to use the Internet to do business. They want to be able to buy things, manage their finances, and communicate privately from the comfort of their home computer. Without a secure infrastructure none of this is possible. Information about the Hack Microsoft promotion is available from http://www.c2.org/hackmsoft/. People who have found security holes and have written exploits are directed to send mail to hackmsoft(a)c2.org. Community ConneXion is the premier provider of privacy on the Internet. They provide anonymous email accounts and support the anonymous remailer infrastructure. Information is available from http://www.c2.org/ or info(a)c2.org. Microsoft is a trademark of Microsoft Corp. Netscape and Netscape Navigator are trademarks of Netscape Communications Corp. This promotion is not affiliated with Microsoft or Netscape.

1 0

Cryptanalysis of RC4 - Preliminary Results (Repeat)
by Andrew Roos 17 Dec '03

17 Dec '03

(This is a repeat because I posted the original 36 hours ago and it still hasn't bounced back to me.) -----BEGIN PGP SIGNED MESSAGE----- Hi c'punks & sci.cryptites About a week ago I posted a message about weak keys in RC4. This is an update on the results of my continued 4am sessions with RC4 and shows that certain weak keys lead to an almost-feasible known plaintext attack on the cipher (well, about as feasible as the differential attack on DES, shall we say). The attack is based on two particularly interesting three-byte key prefixes which have a high probability of producing PRNG sequences which start with a known two-byte sequence. The prefixes are: 1. Keys starting with "00 00 FD" which have a 14% probability of generating sequences which start "00 00". 2. Keys starting with "03 FD FC" which have a 5% probability of generating sequences which start "FF 03". Note that the expected frequency of any two-byte output sequence is 1 in 65536 or about 0.0015%, so these key prefixes are highly unusual. I won't go into the reasons why in this post, since it follows the same reasoning as my last post, but these prefixes are special in that they have a high probability of initializing the RC4 state table in such a way that the first two generated bytes depend only on the first three entries in the state table. This observation is the basis for a simple known-plaintext attack which reduces the effective key space which you need to search to have a 50% probability of discovering a key by about 11.2 bits. The down side is that you need "quite a few" known plaintexts to make the attack feasible. It works as follows: 1. Collect a large number of known plaintexts (and hence known generator sequences). 2. Discard generator sequences which do not start with "00 00" or "FF 03". 3. For generator streams starting "00 00", search all keys which begin with "00 00 FD". 4. For generator streams staring "FF 03", search all keys which begin with "03 FD FC". 5. Keep going until you find a key :-) Clearly this attack will only discover a small fraction of the keys. However since most generator sequences are discarded without being searched, and for those which are searched the search is 2^24 smaller than would be required to search the entire keyspace, the number of trials required to determine a key is significantly lower than for brute force alone. Enough of an intro, here are the relevant results. Forgive my simplistic approach to maths, I'm a philosopher-come-software developer, not a mathematician. I've run the relevant simulations with 40-bit, 64-bit, 80-bit and 128-bit key lengths, and with two different PRNGs. For the sake of consistency with my earlier paper I'll use the figures gathered for 80-bit keys (this seems to be RSA's preferred key length for RC4), but there are no significant differences for other key lengths. The PRNG used for these tests was L'Ecuyer's 32-bit combined linear congruential generator as described in "Applied Cryptography" p. 349. (a) Out of one million trials, keys starting with "00 00 FD" generated sequences starting "00 00" 138217 times, and keys starting with "03 FD FC" generated output sequences starting "FF 03" 50490 times. (b) Out of ten million trials, arbitrary pseudo-random keys generated sequences starting with "00 00" 446 times, and sequences starting with "FF 03" 146 times. (Note the abnormally high incidence of "00 00"; the expected mean is 152.8). Suppose we have the output stream generated by a randomly chosen key. The chance that it will start with either "00 00" or "FF 03", and that we will therefore search it, is: (446 + 146) / 1e7 = 5.92e-5 The chance that it starts with "00 00" and was generated by a key starting with "00 00 FD", or that it starts with "FF 03" and was generated by a key starting "03 FD FC" - i.e. the chance that we will search it and be rewarded for our efforts - is: (138217 + 50490)/(1e6 * 2^24) = 1.12e-8 The total number of plaintexts required for a 50% chance that we will discover one of the keys is: log(0.5)/log(1 - 1.12e-8) = 61 900 000 Well I did say "quite a few" plaintexts would be necessary :-) And the number of plaintexts which you expect to search in order to find the "right" one is: 61 900 000 * 5.92e-5 = 3665 Since the total key length is 80 bits, and we are "guessing" 24 of these, each search requires 2^56 trials. Hence the total number of trials for a 50% chance of discovering a key is: 3665 * 2^56 = 2.64e20 = 2 ^ 67.8 Since brute search alone would require 2^79 trials for a 50% chance of determining the key, this reduces the number of trials by 2^11.2. The results are essentially identical for all the key lengths I have tried, and in each case reduce effective key length by about 11.2 bits. So, for example, a 64-bit key would normally require 2^63 trials for 50% chance of solution; this attack reduces the number of trials to 2^51.8 at the cost of requiring 62 million known plaintexts. I'm still running simulations to check my maths, and although initial results are encouraging, I don't have enough data for it to be statistically relevant yet (generating all these sets of 62 million known streams takes time...) So consider this preliminary (again), and I'll post the results of my simulations when I have enough data. Andrew ________________________________________________________________ Andrew Roos <andrewr(a)vironix.co.za> // C++ programmers have class (but not much inheritance) PGP Fingerprint: F6 D4 04 6E 4E 16 80 59 3A F2 27 94 8B 9F 40 26 Full key at ftp://ftp.vironix.co.za/PGP-keys/AndrewRoos -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMGrlfmatuqa4OR+lAQF1eQP+IBBmSztAYUpq1q/BjzvYDCbb+Ns0Gi1S u9wTaZOCl32fdp7NSUEQBX39nVJkQZginug56BZXzijRvOx6fl4+z7dmW9jwtE5E YNCOhx+/fHX4psszMyEUTrnza7MYDc4HXlgv743LOD/xvEyU0D5OGgB5fg+lyhAK 6xQ/Zy8JpE8= =BdMn -----END PGP SIGNATURE-----

1 0

screensavers and idle computation.
by nefud＠io.com 17 Dec '03

17 Dec '03

To the folx working on the RC4 et. al. distributed keysearch Net: Add a module that will be run from things like "xscreensaver". As Tim May pointed out, current use of crypto is a "tiny fraction of the total computons consumed running screen savers". So let use them, eh? Besides, it'd be kind of neat seeing the "galaxies in hyperspace" displayed in a fractal like screensaver image. -- Allan Bailey | "Freedom is not free." _O_ Senlima Diverseco je Senlimaj Kombinajxoj.| nefud(a)io.com | KC5KSF | GCS w+ v-/+ C++++ U@$ P+++ L++ E++ N++ po--- Y++ b++ ============================================================ = When Privacy Is Outlawed, Only Outlaws Will Have Privacy = = I Support the Phil Zimmermann Legal Defense Fund! = = email: zldf(a)clark.net http://www.netresponse.com/zldf = ============================================================

1 0

FinCen Blurb in local paper
by Kevin L Prigge 17 Dec '03

17 Dec '03

Found this in the St Paul Pioneer Press yesterday, no wire service attribution. Cyber banking risks cited New York Smart Cards, on-line banking and other high-tech consumer payment services could be exploited by money launderers and other crooks, a Treasury Department official warned Wednesday. Stanley Morris, director of the Financial Crimes Enforcement Network, said that government and regulatory agencies believe the new systems, known as cyber banking, will profoundly alter financial services in the future. "The government has got to get its act together" and quickly decide on whether on-line banking systems and smart cards require new regulations," Morris said. Morris spoke to reporters after a day-long closed-door meeting of bankers, regulators, law enforcement officials and technology executives sponsored by FinCen, the governments anti-money laundering agency. --- end article --- -- Kevin Prigge | Holes in whats left of my reason, CIS Consultant | holes in the knees of my blues, Computer & Information Services | odds against me been increasin' email: klp(a)cis.umn.edu | but I'll pull through...

1 0

Assessing Netscape Commerce Server Risk
by millar＠pobox.upenn.edu 17 Dec '03

17 Dec '03

Would anyone care to critique this assessment? >Q: What is the risk of implementing the Commerce Server without waiting for >the Oct. 9 patch (which fixes the randomness problem with the server's >public/private key pair)? >A: The exposure is essentially this: if someone were to make a concerted >attack on your public/private key pair, they might be able to discover your >private key. Combined with net eavesdropping this would allow interception >and decrypting of SSL-encrypted traffic to your Commerce Server, and >combined with IP address and DNS domain impersonation would allow someone >to masquerade as your server. > >I would characterize this risk as low to moderate, with the higher risk >only applying if your Commerce Server is handling larger financial >transactions or extremely sensitive information. > >The time required for an attack on your key pair depends on how close the >attacker can come to guessing exactly when your key pair was generated, and >what the pid/ppid were for the key generation program at the time the key >was generated, as well as how fast the attacker can generate candidate key >pairs. Since the time and pid/ppid are probably guessable only within >broad limits (e.g., within a few days for the time), and generating key >pairs takes on the order of a second or so, the estimated attack times are >much longer than the attack times for SSL messages. I believe Netscape has >published estimates like 60 days or so to crack a key pair; even if those >estimates are too high by factors of two or three the times are still >comparable to the time until the patch is available. > >So if you're really concerned you can certainly eliminate the risk by >shutting down SSL-secure services until you get the patch; however I'd >weigh that against the downside of not having those services accessible. > >P.S. If you do continue running your Commerce Server with SSL, one simple >thing that might help thwart attacks is to do a "touch" on your server key >file and server certificate file (or copy them somewhere and then copy them >back) to update the date/time modified on the files. This eliminates one >possible clue as to when the key pair was generated. _________________________________________________ Dave Millar University Information Security Officer 3401 Walnut St., Suite 265C Philadelphia, PA 19104-6228 University of Pennsylvania For security matters: security(a)isc.upenn.edu (read by Data Admin. staff) Other matters: millar(a)pobox.upenn.edu voice: (215) 898-2172 fax: (215) 898-1729 For PGP 2.6 Public key: http://www.upenn.edu/security-privacy/ PGP Fingerprint: 28 FB 09 DC C7 96 C2 53 1A B8 BE 3B 73 32 46 4C

1 0