December 2003 - cypherpunks-legacy

Crypto Hearings
by John Young 17 Dec '03

17 Dec '03

Declan, or anyone, are there any transcipts of this SAFE hearing, or news reports, or other documents: September 4, 1997 SECURITY AND FREEDOM THROUGH ENCRYPTION ACT Committee on Commerce: Subcommittee on Telecommunications, Trade, and Consumer Protection held a hearing on H.R. 695, Security and Freedom Through encryption (SAFE) Act. Testimony was heard from Representatives Goodlatte and Lofgren; William P. Cowell, Deputy Director, NSA, Department of Defense; William A. Reinsch, Under Secretary, Export Administration, Department of Commerce; Robert S. Litt, Deputy Assistant Attorney General, Criminal Division, Department of Justice; and public witnesses. ----------------------------------------------------------------------- And for these of the coming week: Congressional Record: September 5, 1997 (Digest): CONGRESSIONAL PROGRAM AHEAD Week of September 8 through 13, 1997 [Excerpts] House Committees Committee on National Security, September 9, to markup H.R. 695, Security and Freedom Through Encryption (SAFE) Act, 1 p.m., 2118 Rayburn. Permanent Select Committee on Intelligence, September 9, executive, hearing on Encryption legislation, 10 a.m., H-405 Capitol. September 11, executive, to markup Encryption legislation, 10 a.m., H-405 Capitol. Committee on Science, September 10, hearing on Next Generation Internet Initiative, 10 a.m., 2318 Rayburn. September 11, Subcommittee on Courts and Intellectual Property, hearing on H.R. 2265, No Electronic Theft (NET) Act, and also on electronic copyright piracy, 10 a.m., 2237 Rayburn. September 11, Subcommittee on Crime, hearing regarding cellular telephone fraud, 9:30 a.m., 2141 Rayburn. Senate Committees Select Committee on Intelligence: September 10, to hold a closed briefing on intelligence matters, 2:30 p.m., SH-219. Committee on Labor and Human Resources: September 11, to hold hearings to examine the confidentiality of medical information, 10 a.m., SD-430.

2 1

Re: SSL implementation problem at Netscape
by dawagner＠flagstaff.princeton.edu 17 Dec '03

17 Dec '03

It looks like there's some confusion about the Netscape security problem Ian Goldberg (iang(a)cs.berkeley.edu) and I found, as mentioned recently on cypherpunks. If we'd foreseen that such a silly bug would receive so much attention, I think we would've tried to prepare a more comprehensive description... But we didn't. Anyhow, let's see what I can clear up for you now. [Note: Ian isn't here right now, so he hasn't had a chance to look at this. Any errors are mine, any opinions are mine, etc.] In article <david-1909951219130001(a)192.0.2.1> from sci.crypt, David Sternlight <david(a)sternlight.com> wrote: > If the above is, in fact, accurate it appears to apply to previous > versions of Netscape, not the 2.0 versions for which the public beta goes > out next week. We haven't tried it on v2.0, as we only have a copy of v1.1 right now. But the front-page New York Times article today said that the next version also has the same flaw, and that it'll be fixed before release. A Netscape official press release is available at http://www.netscape.com/newsref/std/random_seed_security.html Also our prototype code can be found at ftp://ftp.csua.berkeley.edu/pub/cypherpunks/cryptanalysis/unssl.c > In addition the flat statement that "keys can now be found > in appx 1 min." is not, as it seems, a general one but (if one reads the > details) requires a number of special assumptions, applies only to some > machines, and applies only if one can develop certain collateral > information. You are partially correct. It all depends on the threat model. If the attacker has user-level access (e.g. an account) on the machine where you run Netscape, your encrypted sessions can be broken quickly. (Our tools took about 1 minute on 1 machine, but was just a proof of concept -- I believe the time could be significantly reduced, and automated completely.) This model is not entirely unreasonable IMHO. If the attacker is simply sniffing the wire somewhere between you and the https: server, and has no account on your machine, things are a bit more complicated. Ian & I are still discussing this case, but I'll mention a few of our observations: * the time, pid, and ppid are mixed together in such a way that there is certainly no more than 47 bits of entropy (which is a far cry from the 128 bits claimed for their commercial domestic version). * the attacker can guess the current time to within a few seconds easily. * maybe the attacker can get this down to about 10 msec uncertainty, possibly even less in some cases. * the ppid is often 1 (e.g. when you start up Netscape from a X-windows menu). * if not 1, the ppid is often just a bit smaller than the pid. * on personal workstations, the pid and ppid are often quite small. * one can remotely determine pid's by talking to sendmail on the attacked machine and bouncing mail -- the pid will usually be in the Message-ID. (if the attacker host runs sendmail, which is a usual case) because pids are assigned sequentially, this leaves very little uncertainty in Netscape's pid. * there's no notion of pid or ppid on MS-DOS: God only knows what Netscape does there. maybe it's just seeded from the time!! * the PRNG is never reseeded for the duration of a cached connection. While we don't yet know exactly how long it would take to break Netscape's PRNG in this threat model, I think it's clear that Netscape's current implementation is insufficient and insecure. You mention that our attack is only applicable to certain machines. You may well be correct -- this is one area where our experiments were still proceeding when the media descended on us today. <chuckle> Certainly the Solaris 2.0 and HP-UX versions of Netscape v1.1 are vulnerable: we tested them ourselves. Ian told me he got email from people who are trying unssl.c on other architectures, and apparently the SunOS 4.x.x version is vulnerable too (and tests of other machines are in progress). We don't know about e.g. PC's yet -- this is another area we were still working on. I will note that Netscape didn't try to claim that any version was safe from this flaw, for what that's worth... Hopefully this will be quickly fixed by Netscape, and then we can all stop worrying about it! :-) David Wagner, daw(a)cs.berkeley.edu, speaking {for,to} himself

1 0

After Key Escrow Passes
by bureau42 Anonymous Remailer 17 Dec '03

17 Dec '03

"Badges? We don't need no stinking _badges_!" PlagaristMonger

1 0

Re: netscape's response
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:53 AM 9/20/95, Jeff Weinstein wrote: > Of course none of this reduces the magnitude of the screw up/bug/design >flaw/whatever. I really can't say which of these it was since I wasn't >around at the time that this code was being written. I must admit that >the RNG seed code was not an area that I thought to examine when I took >over our security library. In _retrospect_ (:-}), the approach taken by Goldberg and Wagner seems pretty obvious. Where PGP, for example, asks the user to go through a laborious process of "generating entropy" through ostensibly-random keyboard button presses, Netscape does not do this. Nor does it, for example, "listen" to a microphone input for some amount of time (to at least make a plausible pretense of gathering entropy), nor does it measure a Zener diode, or count clicks of a Geiger counter, or whatever. The very speed of Netscape's PRNG process suggests the usual weakness in PRNGs: simply not enough entropy. That is, a limited search space allows the guessing of a seed or entry point in a deterministic process. > This was a bad mistake on our part, and we are working hard to fix it. >We have been trying to identify sources of random bits on PCs, Macs, and >all of the many unix platforms we support. We are looking at stuff that >is system dependent, user dependent, hardware dependent, random external >sources such as the network and the user. If anyone has specific >suggestions I would love to hear them so that we can do a better job. I think a reasonable way to generate several hundred seemingly random (or at least highly unpredictable) bits is the "swirling the mouse" approach mentioned by several people. All implementations of Netscape involve mice, I assume, and this is a fairly fast way of generating hard-to-guess bits. Colin Plumb has code to do this, as has been mentioned. (I'm not saying that some number of "mouse swirlings" will generate some number of bits of entropy...this depends on the platform, the granularity of mouse measurements, etc. Better to take several times as many bits as needed and distill them down, with MD5 or other hash functions....can't have too many bits of entropy to start with!) This could be done fairly quickly by Netscape, and doesn't assume the platform has microphones to "measure background noise" or other exotic and nonstandard inputs. Years ago, I recall articles in sci.crypt about getting "pretty good random numbers" from complicated measurements of disk accesses on a local machine, ticks of the system clock, times between keyboard button presses, etc., all mixed and convolved together. Not perfect, of course, but if enough bits are started with (e.g, 2000) when "only" 126 or 512 or whatever are ultimately used, this "mixing" can probably be pretty damned good. At least, I doubt any t-shirts will be won. > Do you mean that cypherpunks offered to review the netscape code >if only we made all the source available on the net? I think that it >is unrealistic to expect us to release all of our source code to the >net. > > We will be having at least some of our code reviewed by a >wider audience, but I don't yet know which code, or how wide a review >group. If anyone has specific suggestions for pieces of code that >you would like to see widely reviewed (such as RNG and seed generation) >let me know. > > I realize that some cypherpunks think that we should make all of >our code publicly available. In an ideal world that would be great, >but we live in a world with politicians, crooks, lawyers, stockholders, >etc... Don't expect to see us posting our entire security >library source code to cypherpunks. I think a better approach is to modularize the functions, so that a "PRNG" chunk could be shown without "damaging" Netscape's market situation. (I doubt the crypto section is seen as Netscape's market edge, and use of industry-verified crypto modules would be a net plus, anyway.) In other words, keep secret (arguably) the things you don't want competitors to have access to. But things like crypto modules are rarely trade secrets--if only because the cores are so often licensed anyway--and can be shown and vetted without affecting the rest of the product. (I said "arguably" because many will argue for showing all of the source code, anyway, as the almost-ultimate check on integrity and reliabilty. And there may be subtle security flaws that hinge on the overall program, not just specific parts.) > I would love to hear your suggestions for good sources of entropy >on any systems that our products run on. See above. This has been a recurring topic in sci.crypt and Cyherpunks---so recurring, in fact, that several of us have expressed bemusement at seeing "yet another "How do I generate entropy" argument." I guess we all (save for Mssrs. Goldberg and Wagner) tacitly assumed that a modern product claiming to have strong crypto would use commonly-accepted techniques for generating enough entropy. (Commonly used in RSA's crypto products, and in PGP.) I suggest you take RSADSI up on their offer to advise you. (Or Cylink, as the case may soon be.) --Tim May ---------:---------:---------:---------:---------:---------:---------:---- 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

Interactive Journal Launches New Tech Center
by WSJ Interactive Edition Editors 17 Dec '03

17 Dec '03

Dear Interactive Journal Subscriber: If you haven't noticed it already, I wanted you to be aware of our new Tech Center (http://interactive.wsj.com/edition/current/summaries/techmain.htm) which represents a dramatic expansion of the Interactive Journal's coverage of technology companies, trends and stocks. Since we launched the Interactive Journal more than a year ago, our technology pages and articles have consistently been among our most popular. Tech Center, we think, not only organizes our coverage better but also increases the number of stories we follow and the depth of background we can deliver. Tech Center reflects news contributions not only from the print editions of The Wall Street Journal and from Dow Jones Newswires, but also from an expanded Interactive Journal news staff in New York and San Francisco dedicated to original coverage for the section. Its four news areas, all updated throughout the day and night, are: · Systems - Breaking stories in hardware and software. · Ventures - Alliances and new businesses shaping the technology landscape. · Fast Forward - The converging worlds of telecommunications, media and computing. · Tech Stocks - Major earnings announcements and other trends of interest to technology investors. In addition, Tech Center will offer a growing library of "Issue Briefings," concise background reports on key technology trends such as Java and online privacy; exclusive Interactive Journal profiles of dozens of top technology companies; and reader forums on major technology stories and controversial issues. Naturally, we also include the latest from Personal Technology columnist Walter S. Mossberg, along with an archive of all his recent columns. Please take a moment to explore Tech Center and let us know what you think, and what else you would like to see there. Neil F. Budde Editor The Wall Street Journal Interactive Edition feedback(a)interactive.wsj.com _______________________________________________________________ Check out Small Business Suite, a new Interactive Edition feature covering issues that matter most to small business owners, entrepreneurs, and anyone who markets products or services to small businesses. http://wsj.com/edition/current/summaries/small.htm ________________________________________________________________ This is the New Features Alert e-mail list. If you do not wish to continue to subscribe to this list, sign on to The Wall Street Journal Interactive Edition and go to the following URL: http://wsj.com/user-cgi-bin/userMenu.html to change your account preferences. Or you can just send email to: stopmkt(a)lists.wsj.com Cancelling your subscription to The Wall Street Journal Interactive Edition will automatically un-subscribe you from any e-mail lists you might be subscribed to through our service. For further questions, please call our customer service department at 1-800-369-2834. __________________________________________________________________

1 0

COMMUNITY CONNEXION CORRECTS INACCURACIES IN NETSCAPE PRESS RELEASE
by sameer 17 Dec '03

17 Dec '03

Sept. 20, 1995 For Immediate Release Contact: Sameer Parekh 510-601-9777 COMMUNITY CONNEXION CORRECTS INACCURACIES IN NETSCAPE PRESS RELEASE In response to Ian Goldberg and David Wagner's recent cryptanalysis and defeat of Netscape Navigator's security, Netscape Communications Corporation has recently issued a press release describing the work Ian and David had done, announced a fix, and offered comments on what they felt were the implications on the security of their software. Community ConneXion congratulated Netscape Communications Corporation today for their quick response to this security problem. The fact that they responded to the problem within two days of its publication reflects well upon their responsiveness to the internet community, said Sameer Parekh, Community ConneXion founder. Sameer noted, however, that their release contained a number of inaccuracies. He wrote a document detailing the inaccuracies that he found, available via the World-Wide-Web at http://www.c2.org/hacknetscape/critique.phtml. He noted that they overestimated the time necessary to exploit the bug by roughly two orders of magnitude. The description of the bug was also flawed, said Sameer. Finally, he described how the solution Netscape was presenting to the problem was viewed by many members of the internet security community as only a partial fix. "Millions of customers and their sensitive information are at stake. Had Ian and Dave been criminals rather than honest students, they might have taken this opportunity to steal credit card numbers, snoop on people's financial transactions, and possibly more." "Are we going to take the chance that the next person who finds a Netscape bug may be someone who would rather steal lots of money than win some T-shirt?" asked Sameer, referring to the T-shirt promotion his company has developed, offering free T-shirts to people who have found holes in Netscape security software. Community ConneXion is the premier internet privacy ISP. They offer anonymous accounts, remailers, and psuedonym servers, in addition to the standard ISP fare of webspace and dialup IP access. Information is available from http://www.c2.org or mailing info(a)c2.org. Netscape and Netscape Navigator are trademarks of Netscape Communications Corporation.

1 0

FBI calls for mandatory clap escrow; Denning on export controls
by Ernest Hua 17 Dec '03

17 Dec '03

All clap-on products sold or distributed in the U.S. must have a clap escrow backdoor "like an airbag in a car," law enforcement agents advised a Senate panel this afternoon. FBI Director Louis Freeh also told a Senate Judiciary subcommittee that "appliance makers should be required to have some immediate clap signature ability available" permitting agents to readily identify clappers who turned on or turned off appliances. This marks the most aggressive push to date for mandatory domestic clap escrow (or "clap recovery"), which means someone else other than the clapper can figure out who did the clapping. Freeh noted that "technology has greatly changed the balance of power in favor of the criminal element. We must right that balance by giving law enforcement the tools necessary to catch the criminals. The ability to remotely enable/disable terrorist devices is a serious challenge to law enforcement, and the only to stop its criminal use is to allow law enforcement the ability to identify the clapper. Of course, there is already full due-process procedures to ensure that law enforcement officers do not violate the privacies of law-obiding clappers. But under a court-order warrant, we must be able to trace the clap to its origin." Many privacy and civil rights groups have raise objections against such regulations. Several court challenges to existing clap export limits are well under way, all citing 1st Amendment violations. Lawyers for the Department of Commerce insists that the limits have nothing to do with the 1st Amendment, and that Commerce (and formerly, the Department of State) has consistently approved all export requests for printed claps. "But real clapping is a mechanism, not an element of speech; it truly enables or disables devices, including bombs and weaponery. There are several industries where we not only allow, but encourage the use of clap-on technology, but we simply cannot allow arbitrary export of clap-on devices, because terrorists could get their hands on it." Sen. Jon Kyl, chair of the Judiciary subcommittee on technology, terrorism, and government information, opened today's hearing not by saying its purpose was to discuss clapping in a balanced manner, but that he wanted "to explore how clap-on is affecting the way we deal with criminals, terrorists, and the security needs of business." Then he talked at length about "criminals and terrorists" using clap-on bombs, and child pornographers "using clap-on to view pornographic images of children that they transmit across the Internet." Dorothy Denning, a Georgetown University professor of computer science, did testify. Kyl made a point of asking her if she still supported clap escrow systems (two recent articles by Will Rodger and Simson Garfinkel said she was changing her mind). "I think clap recovery offers a very attractive approach," Denning said. What about export controls? "In the absence of any controls, the problem for law enforcement would get worse," she replied. But when Sen. Dianne Feinstein (D-Calif) asked if Denning would support a *mandatory* clap escrow system, the computer scientist said she wouldn't. "No, because we don't have a lot of experience we clap recovery systems ... a lot of people are legitimately nervous." Sen. Feinstein asked Dir. Freeh if such voluntary systems would give the clapping criminal freedom to simply turn off the features to support lawful clap recovery. Dir. Freeh replied that he was certainly "warm" to the ideal of mandatory clap escrow, but public opinion simply did not support it. Recent FOIA'ed documents obtained by EPIC, a privacy watchdog group, showed that, as far back as the Reagan administration, clap-on technology was under the scrutiny of the law enforcement and intelligence agencies. The memos include references to the Digital Clapphony legislation, which was pushed through two years ago by heavy last-minute behind-the-scene lobbying in the congressional budget bill, and to the proliferation of software clapping technology. The administration refused to comment on the FOIA'ed documents. -------- Another one that couldn't wait until 4/1. Apologies to Declan to extremely "liberal" pilfering of his article. And, of course, to the Clap On! lawyers: This is a parody and a joke ... in case it was not clear. Ern

1 0

Re: Big Brother is watching
by Sean Roach 17 Dec '03

17 Dec '03

At 03:01 PM 9/4/97 -0400, Ray Arachelian wrote: > >On Thu, 4 Sep 1997, Anonymous wrote: > >> 2) When you find one of these unattended critters along the road, wave >> your hand in front of it at amazing speeds until it runs out of film. >> (Ensure middle finger is extended.) > >Depends on the kind of camera. If it's a video camera, you might be able >to blind the bitch by blasting loads of IR at it which would be >invisible to any donut munchers watching you.... Anyone know a source >for big IR lamps? > >Any way to defeat film bearing cameras? Better yet. A carbon dioxide lazer. Can be small and could probably be rigged up to plug into the ciggarate lighter. A focused, IR beam. X-Ray tubes look simple enough. Might want to invest in a little shielding however. If it is an old fashoned camera, you might be able to beat it with the same countermeasures that mess up tv sets. Heck, if the thing is connected with any RF system for recording, you might anyway. Just use a boosted CB to jam it. If the system relies on the radar gun to activate it. Invest in a jammer, (only illegal in a few states, such as Oklahoma, which can use a radar-detector so it really doesn't matter.) Even if it doesn't work, (in that the camera actually takes a picture) at least it should say that you were going the speed limit. The unit I saw advertised said that the gun wouldn't even display because it wouldn't be able to get consistant readings. But I have heard of people setting transmitters on thier cars that broadcast at a certain frequency which corresponded to a certain speed to those doppler guns.

1 0

response to netscape's press release
by sameer 17 Dec '03

17 Dec '03

I plan on releasing a press release regarding the misleading statements made by Netscape in their statement about the seed bug, announcing the web page describing my objections in detail. The document is http://www.c2.org/hacknetscape/critique.phtml detailing my objections to their statements.. I would appreciate comments, corrections, and criticisms. Thanks. (The press release will not be written in the style of the web page. ;-) IN REPLY TO NETSCAPE Netscape announced that they are going to "fix" the problem. In traditional Internet style, I will respond to their post. With this knowledge, an experienced computer programmer could decrypt messages sent by Netscape Navigator to other computers in a few hours of computation time. "a few hours"? Ian and David's program generates keys in 25 seconds. The random information is found through a variety of functions that look into a user's machine for information about how many processes are running, process ID numbers, the current time in microseconds, etc. Specifically, the Parent Process ID, the Process ID, and the time in microseconds. See the exploit code for more details. The current vulnerability exists because the size of random input is less than the size of the subsequent keys. The vulnerability exists because the random input isn't random. Since when is the time "random"? I'm sure a few physicists would love to see your theories on that one. (Berkeley Standard Time notwithstanding) Once this improvement is made, protection of the random information will be as strong as the rest of the security built into Netscape Navigator. That's not saying much, considering that the security community has not had a chance to independently verify the security in Netscape Navigator. Netscape has also begun to engage an external group of world-class security experts who will review our solution to this problem before it is sent to customers. So after someone violates Netscape Navigator's security do they decide to have an external group verify their code. (Note that they still don't plan on making it available for the security community at large to review). According to RSADSI's Jim Bidzos, his company offered to review Netscape's security when it was first introduced, but Netscape declined. "They're asking us to review it this time," he said. This discovery does not affect the strength or security of SSL (Secure Sockets Layer), RC4, or any other portions of our security implementations. True, but this implies that SSL is a secure protocol, which has been shown to be false. At the beginning of their release: Netscape secure software has been in use for almost a year on the Internet by millions of customers and no thefts of actual customer information protected by our security have been reported - this posting on the Internet reported a potential vulnerability, not the actual theft of customer information. Yes, Netscape is very lucky that Ian and David are students, and not criminals. I sincerely hope that the next time someone finds a hole in Netscape that it's someone who would rather win a free T-shirt than steal lots of money. -- 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

2 1

Investing on Information We Get Here
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 1:35 PM 9/19/95, Duncan Frissell wrote: >At 11:00 PM 9/18/95 -0400, John Young wrote: >> The New York Times, September 19, 1995, pp. A1, D21. >> >> >> Security Flaw Is Discovered In Software Used in Shopping >> >> By John Markoff > >On the Front Page, *above* the fold. Perhaps John was trying to make up for >being scooped by the WSJ on the SSL Crack story. Also front page, above the fold, for the "San Jose Mercury News," the newspaper of record of the Silicon Valley. And CNBC is reporting the story on its hourly updates of the news. (These computer lists are really great for investors! I heard about the Apple problems a few days before they hit the street, and was able to unload a bunch of shares at $45, a day before it dropped, now down to around $36. "He who hesitates to act on inside information is lost.") P.S. On Netscape, I've finally decided to do some buying. Sure, this latest flaw is another embarrassment. But more deals and link-ups than ever are being inked, and they've got the resources to really spruce up Navigator and related products. I just don't see too many competitors on the horizon. Actually, I was planning to buy some Netscape stock, now that the IPO froth has settled. And since I have this info on the flaw, I _have_ to buy it, else be guilty of "insider non-trading." As Stew Brownstein, a friend of mine, has noted, if insider trading rules are interpreted logically, then _failure_ to make a planned trade on the basis of insider information is just as illegal as deciding to make some trade on the basis of insider information. The SEC should require all insiders to file a daily report, preferably before the market opens in NY, listing all of their planned transactions for that day, so that violations of the "insider non-trading" laws can be detected and prosecuted. (Yes, I know that I am not an "insider" by SEC definitions. Poetic license.) --Tim May ---------:---------:---------:---------:---------:---------:---------:---- 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."

4 3