December 2003 - cypherpunks-legacy

Re: PA Remailer Concerns
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

Has anyone examined the legislative history associated with this statute? I would be surprised if they were singling out anonymous remailers. They may have had other concerns regarding phone abuse, e.g., long distance fraud. Then again, I could be full of it...

6 5

proposal: "security spectrum scale" (SSS)
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

regarding the recent Markoff NYT article on NFS weaknesses, I agree it seemed to be overblown. but in fact I have been betting that feeling from *all* the recent articles on the netscape bugs etc (egad, am I mistaken, or whas there front page NYT coverage for a *buffer*overflow*? at least there was for a single *poorly generated random seed*!!). for example, in another, the fact that netscape had a buffer overflow in URLs was translated by a reporter into "a similar bug was used by Robert Morris in the infamous worm that infected the entire internet a few years ago" or something similar. it seems to me what is lacking in all this is a *security spectrum*. unfortunately security experts sometimes have a tendency to equate *any* security weakness with a catastrophic one. while this is a good approach in general, i.e. to be as conservative as possible, in practice there can be no doubt that some security weaknesses are far less severe than others. if the security *experts* conflate the issue of the *severity* of a security breach (and I see this happening all the time on this list), there is little surprise that reporters aren't figuring it out either. some of the really obvious example of the kinds of differences in security that are being conflated: client vs. server problems (server problems are far worse of course; the netscape bugs were mostly *client* problems), subnet vs. overall network problems, bugs that allow people to merely crash a system vs. submit arbitary code, etc. to aid this serious problem, I propose the creation of a UNIFIED SECURITY SPECTRUM RANKING. this would be a list of all the different types of security weaknesses a system can have, and their LEVEL OF SEVERITY. it would attempt to rank every type of security breach possible. then, when a new security weakness is discovered, it could be ranked A1 or B5 or C6 or whatever. this would be a sort of technological "richter scale" that would allow the novice to immediately understand that a given bug that was recently discovered (say, the recent netscape bugs) was, say, not really as potentially severe as the Morris worm. a press article might say something like, "the recent netscape bug was ranked a B5 on the security scale by experts. this means that an unauthorized intruder could break client software. the bug could potentially be as serious as A3, meaning that arbitrary code could be submitted. the other bug was classed B3, because it allows the detector to grab unauthorized data, but still be detected in doing so." etc!! I think it is pretty obvious how much of a positive effect this could have in quantifying and tracking and publicizing new bugs. it might make it impossible for a reporter to give an improperly alarmist position. for example, no one would take seriously an article that gets excited about a 3.6 richter scale earthquake. similarly, the reader might be able to draw his own conclusions if we came up with a sufficiently universal scale and it is widely used in articles. furthermore, this scale would tend to help the reporter/editor immediately know if a given bug report is newsworthy (if they continue to enthusiastically report bugs, although I wonder if this is a fad that may die out). and ultimately it might really help the issue of "proper attention to bugs". the public is getting a scare story for almost every new bug, and this is just not appropriate. to use my tired analogy, it is like the media putting every dinky earthquake item on page 1. another idea behind the rating: it might be a sort of matrix format, such as "a-6-alpha" where each of the elements indicates some kind of independent factor. for example the "a" might mean "client side", the "6" might mean "crash only", the "alpha" might mean "breach cannot be detected after the fact". however it shouldn't be so complicated that the novice can't immediately determine which of two rankings is more severe. now, I am really rather surprised that no such scale appears to exist currently. I highly suspect the NSA probably has a system for this but unfortunately it is not being used by CERT or anyone else that I know of. if anyone does know of this kind of "security spectrum", I think our cause of trying to improve software security would be furthered immensely if whenever reporters call about bugs, the scale factor could be consistently and uniformly used in association with trying to describe the severity of the bug. I am willing to work on a beta version of this "security spectrum" if there is sufficient interest. it certainly seems like a far better and worthwhile investment of time than, say, "the geek code", the latter of which is already highly developed!! I don't really consider myself the best qualified in terms of experience but sometimes if you want something done, you have to do it yourself. however, if we do this, I hope that a good scale that is pretty general and doesn't need extensions can be done from the start, before its widespread usage, so that later changes do not confuse users. there is already confusion in the media about two slightly different richter scales, this is a pity. another neat perq: if the cypherpunks come up with a good scale, it could be a tremendous positive publicity tool. "today experts discovered a bug in -x- that rated a -y- on the CSSS (Cypherpunk Security Spectrum Scale)" generally, regarding cypherpunk priorities, I think the "media can be made our friend", but we just have to learn how to be more meticulous and careful in our interactions with them. in general I don't really think a lot of the misreporting going on is the fault of the reporters involved. it's not surprising they get their stories mixed up, when, IMHO, even the "experts" they quote aren't particularly polished and don't really have their act fully together (or at least, tend to misrepresent the problems from the beginning). (most of the last Markoff article imho can just be chalked up to, "two prestigious graduate students who discovered something significant recently wrote a message warning about another significant security problem." it shows how absolutely critical it is to be careful what you say once you have built up a bit of a reputation. these two grad students are now being watched as the Chicken Little's of Cyberspace by the media, unfairly or not. be careful about wishing about fame, or anything else!! you might get it!! makes me a bit nervous about causes *I* have promoted in the distant past.) --Vlad Nuri

2 1

airport security
by Bob Bruen, MIT Lab for Nuclear Science 17 Dec '03

17 Dec '03

Roy M. Silvernail wriote: >Have you flown recently? They now ask you this scripted question about >whether you have been approached by anyone you don't know since arriving >at the airport, and warn you not to accept anything from a stranger or >leave your carry-on baggage unattended until you board the plane. The >ticket agent told me it was a "new FAA regulation". I hadn't flown >anywhere for a few years. Anyone know how long this has been happening? > Goodbye freedom, hello police state. >I wonder how long before I need a passport to cross a state line... The US is merely trying to catch up to what the Europeans have been doing for over a decade. In fact, the US still has a way to go. You ought to pass through Heathrow in London some time to see what real airport security looks like. The US security changes are a recent response, starting after the World Trade Center bombing and being stepped up on a continuing basis. Today you need a picture ID to board with your ticket. Tomorrow...? We have lived in relative safety compared to the rest of the world, but I think those days are over. Usual disclaimer. Bob Bruen.

5 4

Re: responce to graphic encryption replies
by jps＠monad.semcor.com 17 Dec '03

17 Dec '03

> ... The graphic file is going to have a highly correlated > structure, long runs of white space etc. This is not the case for digital imagery. For any given band, if you sample a significant portion of the image it would not be surprising to see a more or less random distribution over the range. > The statistics for such a file > would be different than the random distribution you'd get from using the > wrong key. If you decrypt with the wrong key, do you get a random distribution? Would this be the case for all wrong keys? Would the statistics change in any discernible pattern as the keys got "closer"? > Even if the graphics format is compressed, leading to a more > even distribution, ... This may give a better result. Most compressions involve a shift to the frequency domain with a quantization of the samples. You might be able to write a detector based on this discontinuity. You could also try throwing an edge detector or some other morphological recognizer at the output. It would still be cheaper than having to a man in the loop, but you're going to spend a lot of cpu time. jps -- Jack P. Starrantino (215) 674-0200 (voice) SEMCOR, Inc. (215) 443-0474 (fax) 65 West Street Road jps(a)semcor.com Suite C-100 Warminster, PA 18974

2 1

Re: Certificate proposal
by tomw＠orac.engr.sgi.com 17 Dec '03

17 Dec '03

In article <DGF06D.HGJ(a)sgi.sgi.com>, daw(a)lagos.CS.Berkeley.EDU (David A Wagner) writes: > In article <199510120147.LAA13833(a)sweeney.cs.monash.edu.au>, > Jiri Baum <jirib(a)sweeney.cs.monash.edu.au> wrote: >> What you are missing is that you should not say >> "I want to send my credit card number to Egghead Software" >> you should say >> "I want to send my credit card number to 12 34 56 78 9A BC DE F0" > Why does this sound so much like defining the problem away? > Maybe I just don't get it... I agree. Sending your cc# to a key or an IP address is not what you want to do. As a consumer, I want to make sure that I send my cc# to the merchant I am buying from. -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw(a)engr.sgi.com

2 1

old doc cohen
by an116512＠anon.penet.fi 17 Dec '03

17 Dec '03

<<this post was written by me and two other people who have been watching cohen's career for the last few years. i'n sorry for the spelling mistakes and typos.>> dr frederick b. cohen's frequent rants in which he expresses nothing but contempt for everyone else in the security and crypt business have to be understood in their context: he's trying to sell something. what's he selling? who's he trying to sell it to? there are several answers. all are partly true and taken together explain his posts pretty well. directly, he's trying to get us to buy his products, services, and books, or at least recommend them to others. it is obvious how setting himself up as the only one who recognizes these serious flaws would enhance his consulting business. he doesn't care about netscape or pgp. he cares about his wallet. indirectly, he's testing out halfbaked ideas here to better learn how to refute those who see through their weaknesses so that he'll be better prepared when he spews in more "serious" forums. this is a low risk place, as far as he's concerned, to make a fool of himself. socially, he's selling the idea of his own academic respectability. notice how he reminds us he's "dr." (look at me! i have a doctorate!!!) cohen. the truth is he never managed to get the respect of the mainstream academic and research worlds. he's been reduced to playing the role of victim-soothsayer. we'll all regret not listening to him back when we had the chance, one of these days. look at the reaction to his "seminal work" on viruses for a great example of how the real research world yawns at him to understand why this is so important to him. he feels cheated out of the respect he deserves. (he's willing not to care about his wallet to the extent that he gets this) psychologically, he's selling the idea that he's respectable to himself. ultimately it doesn't matter that most of us see right through him as long as he gets enough people listening to him to feed his very delicate ego. he needs us (someone, anyone, even us cypherpunks if that's what it takes) to love him and take him seriously. it's very sad. let's just ignore him. he'll find somewhere else to play (he always does). --****ATTENTION****--****ATTENTION****--****ATTENTION****--***ATTENTION*** Your e-mail reply to this message WILL be *automatically* ANONYMIZED. Please, report inappropriate use to abuse(a)anon.penet.fi For information (incl. non-anon reply) write to help(a)anon.penet.fi If you have any problems, address them to admin(a)anon.penet.fi

1 0

Re: Postscript in Netscape
by lyalc＠mail.mpx.com.au 17 Dec '03

17 Dec '03

> >WRONG!!! Netscape claims to be "secure" - hence it is Netscape's job to >be secure - regardless of the user's use of their product. Otherwise, >the ads should read: > > "Netscape can be used securely by sufficiently knowledgeable > users who have emasculated their postscript interpreters before > using them to view files of unknown origin, and who have removed > all other known, unknown, and/or undisclosed security holes from > their systems. Otherwise, Netscape is insecure and should not be > trusted." > >-- cars are claimed to "safe". That only applies is driven sober, within speed restrictions and road conditions by a (basically) trained driver. The same analogy applies, in my view. lyal

1 0

PGP interface for Mac--well...
by tbyfield＠panix.com 17 Dec '03

17 Dec '03

Has anyone seen this yet? The only upload I've seen, on info-Mac, unbinhexes into something called "My Preschool Demo," and that's pretty much what it is. http://hyperarchive.lcs.mit.edu/HyperArchive/Archive/cmp/ mac-pgp-control-10b1-as.hqx >From ~/mac-pgp-control-10b1-as.hqx.abs >Abstract of INFO-MAC archived encoded Mac binary file > 'cmp/mac-pgp-control-10b1-as.hqx' > Uploaded 10/20/95 250028 bytes > >From: raif(a)mpx.com.au ( Raïf S. Naffah) >Subject: MacPGP Control 1.0 Beta 1 > >Hi there, > >Please find attached the first public release (Beta 1) of the MacPGP >Control application. > >MacPGP Control (or MPGPC for short) is an AppleScript application --written >in AppleScript English dialect and FaceSpan 2.0.1-- that offers an >easy-to-use, more Macintosh friendly user interface to MacPGP. > >The main features of MPGPC are: > >1. [Mac]PGP related features: >* Allows definition and use of nicknames for Users and Groups recepients. >* Offers more control for keyring related actions, through a true Macintosh >Human Interface and -in some cases- direct manipulation of keyring file >data, including: editing trust flag byte, enabling/disabling, extracting, >checking, certifying, fingerprinting, and forcing Warn-Only bits. >* Secure clean clear-signed PGP ciphers, through the implementation of >features such as: expanding tabs, transliterating non-USASCII characters, >and word-wrapping lines before processing and handing over to email >application. >* Allows viewing of PGP packets for educational and debugging purposes. >* Allows opaque signing (asciified clear-signed text) >* Supports (low-level) and use HTTP for PGP Keyserver querry and update of >public key information. >* Transparent use of user's UserIDs found in his/her secret keyring file. >* Allows encryption for multiple recepients. >* Generates Key Revocation Certificates. > >2. Eudora related features: >* Supports latest Eudora versions (2.1.3/1.5.3) known to break certain scripts. >* User-configurable Auto Move PGP messages to designated mailbox. >* User-configurable Auto Decrypt source data before processing. > >3. Macintosh related features: >* Handles encrypting/decrypting messages larger than 32K internally, while >allowing editing of the top/first 32K chunck. >* Extensive support of drag-and-drop. >* Documented handlers calls for use by other scripters. > >To run MPGPC you need: > >1. The Scriptable Finder, >2. Geneva font family, >3. MacPGP (tested with the 2.6ui and 2.6.2 versions), >4. The following additional extensions should be in the Extensions folder >inside the System Folder: > * AppleScript, > * FaceSpan Extension v2.0.1, which lives on > <ftp://199.72.251.93//pub/sdu/FaceSpan/FaceSpanext20.sea.hqx> >5. The following osaxen which should be part of the standard distribution >of the Scriptable Finder, and which should reside in the Scripting >Additions folder inside the Extensions folder: > * Choose File, > * Display Dialog, > * File Commands, > * Load Script, > * New File, > * Numerics, > * programmer's tool, > * Read/Write Commands, > * Store Script, > * String Commands. > >MPGPC is a freeware. > >cheers;

1 0

Re: 50 attacks... [NOISE]
by tomw＠orac.engr.sgi.com 17 Dec '03

17 Dec '03

In article <DGpCsv.9r5(a)sgi.sgi.com>, fc(a)all.net (Dr. Frederick B. Cohen) writes: > And how secure is the hash? It it possible to create values that will > hash to each prime (or something else that does the job)? Is the hash > something we can figure a way to precompute using massively parallel > processing so that we can then provide a set of codes which will produce > the desired results? (etc.) Perhaps you should consider learning something about cryptography before you cast aspersions on someone else's cryptographic protocols. To date, MD5 appears to be a secure hash. If you manage to find a way to reverse it, please let us all know. -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw(a)engr.sgi.com

1 0

Re: Netscape rewards are an insult
by tomw＠orac.engr.sgi.com 17 Dec '03

17 Dec '03

In article <DGq01x.ADx(a)sgi.sgi.com>, Aleph One <aleph1(a)dfw.net> writes: > On Thu, 19 Oct 1995 anonymous-remailer(a)shell.portal.com wrote: >> > NETSCAPE CLIENT APIS (NCAPIS) 2.0 >> Generally, we don't routinely trust every other computer, foreign or >> domestic on the Internet to manipulate us by remote control. This is >> as basic as the idea that we don't give out our PIN numbers with our >> banking cards to anyone who asks us. > Have you actually read the stuff? The NCAPIS is not on by default. > You *must* enable it by tellling it to which port to listen on. > Further more Mosaic had a remote control API before Netscape did. They can also be used only from the local machine on Windows or from any machine your X server trusts on Unix. Unless the attacker can control what software is installed on the target system, there's no way for him to use this to his advantage. Of course, there's always the possibility of exploting bugs, but that's not a "flawed algorithm". -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw(a)engr.sgi.com

1 0