December 2003 - cypherpunks-legacy

Re: MIME attachments and ranting.
by Bill Stewart 17 Dec '03

17 Dec '03

>> >Attachment Converted: D:\DOWNLOAD\MIME\RePGPfor.8 >> I, for one, don't need Mystery MIME Attachments cluttering up my drive. If >> it's worth saying, then *say* it. >I really don't know why any mailers call a monopart MIME message an >"attachment". Mail readers come in three basic flavors of unMIMEificationness: 1) Ignorance+bliss - the mailer doesn't know or care about MIME headers, and you can ignore them when you read them, and may be able to configure the reader not to bother you with most of them (e.g. BSD Mail.) 3) Intelligence - the mailer does something genuinely useful to help you read the attachment, like letting you pop up some appropriate reading tool. 2) Naive friendliness - the Sirius Cybernetics approach. "Your mail file has been tastefully shredded into little pieces and sprinkled around your disk drive. Thank you for making a humble mail system so _very_ happy." Free Eudora versions offer you several choices of tastefulness and shredditude, partly intended to provide artistic functionality and partly to encourage you to buy the commercial version which gives you a more flexible user interface for extensions like MIME. So buy it, or cope with it, or tell Eudora to use your RAMdisk for its attachments where they'll soon go away and not bother you. There's also another approach, typified by a vendor whose name will be omitted but they'd know who they were if they had a <perjorative deleted> clue.... 0) Downright hostile - Not only does it _pretend_ to be Intelligent, while only really doing the right thing with its own proprietary data formats*, though generally doing something reasonable with uuencoded documents with names that it understands, but it chokes and dies on messages that have even moderately large amounts of simple, basic, non-attachmentized _text_, and if you _do_ try to package text up to send to some poor sucker who's stuck with one of these <perjorative deleted> systems, it hands it to a brain-damaged user-friendly mouse-editor that _also_ chokes on more than 64KB of text.... [* where "the right thing" allows it to mindlessly run arbitrary code handed to it as macros in the proprietary data formats that the company encourages its users to use instead of real text....] #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: NYT on Netscape Crack
by Bill Stewart 17 Dec '03

17 Dec '03

> The New York Times, September 19, 1995, pp. A1, D21. > ...... > "The good news and the bad news of the Internet is that > when you put something up there, many more people can test > it," said Mike Homer, the vice president of marketing at > Netscape. "You also give yourself the opportunity of having > people point things out which you can fix quickly." That's a good, and realistic, attitude. > Netscape officials said today that they would strengthen > the system, by making it significantly harder to determine > the random number at the heart of their coding system. They > said they would no longer disclose what data would be used > to generate the random numbers. I do hope this is just John Markoff's simplification of what Netscape's folks said and not an endorsement of security-by-obscurity. I realize that some data does need to be kept around on disk or in the program, since obtaining a lot of random bits at the beginning of every transaction either requires annoying user interactions or takes too long to get decent quality, and certainly this data ought to be kept private by the algorithms involved. One concern I've had about the popular "crunch some bits repeatedly through MD5" approach to random number generation is that knowing one sample from the stream (e.g. by doing a transaction with the victim) gives you the rest of the stream. There's a way to improve that. let X(0) be some number you keep around from a previous session, modified by whatever hardware randomness is available, and seeded by user input the first time. let X(i) = MD5(X(i-1)) let Y(i) = hash(X(i)), where hash is something like MD5(key,X(i)) use Y(i) as the output random number. This eliminates the ability to determine X(i) or Y(i+1) as a function of Y(i), since the search space of X(i) is presumably too large to reverse (unlike the number of bits you can cheaply get in one session). Keeping some of the bits of Y(i) around to use in addition to the other key for the hash, or to key the MD5(X(i-1)) with, may be useful as well. #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: Caribbean Internet Services? (fwd)
by Bill Stewart 17 Dec '03

17 Dec '03

Tim wrote: >>> I suspect "Caribbean Data Havens" and "Internet Sites" are further off than >>> they were a few months ago. The governments of the affected islands will have to make some tradeoffs - do they allow providers of these services to operate freely, bringing in new telecomm facilities so they can get the revenues from (let's keep the Minnesota AG happy) gambling and other private-communications trade, or do they leave their telecomm monopolies in place, so they can get the telecomm revenues which get into government coffers more quickly? Is there enough market to convince them to open up, which will attract more services? How much does being first matter? #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Quick ITAR question....
by descarte＠mcqueen.com 17 Dec '03

17 Dec '03

I've just about finished the perl SSLeay implementation and I was musing about how I would manage to do one for SSLref also....... Here's the situation: I'm in Britain, but I have access to a machine which I wll develop on in the States. Can I develop Net::SSLref on this machine? My feeling is, no, since I'm not a US citizen ( does this matter with ITAR? ). Similarly, it could be construed that the characters constituting the source code are crossing the Atlantic to my machine here, albeit not being stored. Conversely, I'm not reading *all* the code, so I couldn't necessarily build SSLref from this action ( a parallel may be the export of 1/723 of PGP in a .sig! ) Any comments would be much appreciated. Thanks. -- Alligator Descartes | PGP Key available on request. descarte(a)mcqueen.com | http://www.mcqueen.com/hermetica

1 0

Re: taxonomies of 'real money' and e-cash
by P.J. Ponder 17 Dec '03

17 Dec '03

On the 18th, Tim May wrote: > > I wasn't saying they are all on the same footing, or are all separate and > compartmentalizable things. Clearly some of them are just slightly > different "flavors" of other things. I listed a bunch of them not as a > taxonomy or ontology, but as an illustration that there are many kinds of > financial dealings, many kinds of roles played. > > That the real world has so many flavors of financial things could of course > be due to inertia and ignorance, partly. But there are also different > functionalities, and costs. Fitting the different needs, the different > roles of the players. I won't go on and on, as my last post on this I think > hit the main points, but consider how many flavors we have just of > "checks": the "ordinary" checks we write, counter checks, dual-endorser > checks, traveller's checks, and so on. (If you are arguing that only > "digital cash" is a real issue, and all other constructs are "small matters > of programming," then we disagree profoundly.) My mistake then. You obviously have in mind some things much more subtle and more logically removed from money, or currency, or even liquidity than what I thought you were referring to. I'm going back to reading the list in the mornings. --PJ . . . . > --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." >

1 0

Errors in Applied Cryptography, 2nd Edition
by Bruce Schneier 17 Dec '03

17 Dec '03

I have taken a three stage approach to reducing the number of errors in the second edition: 1. Correct the errors from the first edition. 2. Ensure that I don't create any new errors while writing the new material for the second edition. 3. Make sure that additional errors don't creep in during the production of the second edition. In order.... I have done a lot more than incorporate all the corrections from the errata into the second edition. Minor things, too trivial to make the errata list, were also corrected. The first edition was translated into French, and the translator sent me hundreds of queries: things that were unclear, ambiguous, or erroneous. All of those queries resulted in changes to the second-edition manuscript. I was a lot more careful adding new material, reading it over several times to ensure accuracy. And a lot of other people read the chapters over, too. For the first edition, I asked about a dozen people to proofread the manuscript for me. Most people read the first chapters carefully, and then petered out somewhere in the middle. This time I asked about seventy people to each read a chapter (or two)--a chapter within their area of expertise. Each chapter was edited by at least two people, often more. Additionally, two people were paid to read the entire book for accuracy and comprehensibility. I learned a lot about the publishing process during the production of the first edition. For the first edition, I had no control of any of the production decisions. The copyeditor added errors to the manuscript. Some computer idiot lost all of my italics, boldface, superscripting, and subscripting while translating my files from my word processor to their page layout program. The proofreader didn't catch errors that the production people added. I had almost no time to review the manuscript at any of the stages. This time around I was able to choose my own copyeditor, proofreader, and indexer. In fact, there were two separate rounds of copyediting with two different copyeditors. The proofreader is not only the most meticulous proofreader I know, but someone who knows enough math to catch errors in the equations. I verified all file translations myself. And I reviewed the copyedited manuscript twice, and two separate passes of page proofs. I'm not stupid enough to state that the book is 100% error-free, but I am confident that there are far fewer errors in the second edition than there were in the first. I was embarrassed at some of the errors in the first edition, and I put a lot of effort into making sure it doesn't happen again. Bruce ************************************************************************** * Bruce Schneier * Counterpane Systems For a good prime, call 391581 * 2^216193 - 1 * schneier(a)counterpane.com **************************************************************************

1 0

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