- cypherpunks-legacy - lists.cpunks.org

Re: PGP in UK - snooped as unSTEALTHed?
by Bill Stewart 17 Dec '03

17 Dec '03

At 06:29 AM 9/12/95 -0400, Perry wrote, replying to Gary: >> When are the PGP designers and coders going to get serious >> and develop STEALTH PGP inside PGP itself!? >Never, I hope. It would dramatically lower the utility of the >system. Can you imagine how disgusting it would be to try decrypting >something if you have a dozen keys outstanding? I disagree - if it's done right, the degree of stealth can be user-selectable, and even moderately stealthy options can tell which key to use without giving away much information. (For instance, 4 bits of keyid isn't very revealing, but will tell you which one or two of your dozen keys to try.) Have the most non-stealth options indicate that it's PGP-encrypted and addressed to keyid 0x12345678, Joe User <joe(a)foo.com>, blah, blah. The basic problem is that stealth wasn't an original design criterion, so many parts of the PGP data format reveal at least that PGP is being used, and occasionally other information as well. Some things are easy to work around (----- BEGIN PGP etc.), and some aren't. Changing this takes a substantial amount of redesign. >Not to mention how >hard it would be to deal with figuring out that you should even try to >decrypt things in the first place. As you say a couple paragraphs later: >If someone sees a bunch of random numbers in mail sent by me, it's going >to be pretty obvious what the hell is inside anyway. Similarly, if someone emails you a bunch of random numbers.... >I very much see this whole thing as a non-issue. Most of the time, for most users now, it's not an issue. But there are people who will need to hide encrypted messages, and as anti-privacy laws in the US become stronger, that may be us. Is this an issue for PGP 3.0.1, or an issue for Privacy:TNG? Probably the latter, given the state of the PGP world, and certainly ranting at the developers to do it now is uncool. But it should be a design goal. #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: Why ecash is traceable
by Donald M. Kitchen 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Excellent discussion on the subject, actually. However, your idea of the "first person to the bank" maintaining anonymity via remailer block is flawed. First of all, if a collusion with the bank is being taken into account, presumably sufficient enough resources are involved that someone may try and track the reply block. Mixmaster (as your messages mentioned by name) would be necessary to eliminate the chance of tracking the block through combinations of replay attacks etc. (Which reminds me, has anyone implemented an Expiration date on Type I remailers yet?? I remember someone telling me it was being put into the RFC) However, mix does not have a reply block system. Nor are there any Type I -> Mix gateways, for reasons mentioned months ago. (PS, For historical sake, I was a strong supporter of a Shamir Sharing Shell Game[tm] with the type I message. Everything during those months came out of a rant program, so I can hardly expect you to have saved them) Soooo... Anyone up for a Shamir Sharing Shell game? Of course, a drop box system would be *much* sexier. Combined with, say, an encrypted socket, or maybe MIXing a packet straight to your door. (Every client a mix site, remember? Just make yourself a mix key and give it to the drop box. I figure if the TLA has you by then, you might as well trust the drop-box operator too) ObMiscCrypto: Cypherpunk archives seem to have been down for a month, and a mailto:// didn't wake anybody up. I got a message from Bob Silverman, apparently he would not be opposed to giving his software to the C-punk key Cracking Ring, Inc. as a group on the understanding that the group lend him some factored numbers. He reports having no PGP key, so getting a PGP sig won't be happening. Perhaps someone who knows him or someone who knows about factoring software would volunteer to get the goods? ObHiMom: Hi Mom. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMFk9cMLa+QKZS485AQHEpgL8C2N2eioUPaMqLlbzFL29F5zvq50J1o1+ nyoVxV51U4mglT40J8XZmF3/+15mN0aDbbA1NbOzd/7x20TeXnOwGGRHB2iHF0NB k++VRMrwX85MZ5snlf/c0l5XGnxKEuU6 =7hGk -----END PGP SIGNATURE----- <don(a)cs.byu.edu> fRee cRyPTo! jOin the hUnt or BE tHe PrEY PGP key - http://bert.cs.byu.edu/~don or PubKey servers (0x994b8f39) June 7&14, 1995: 1st amendment repealed. Death threats ALWAYS pgp signed * This user insured by the Smith, Wesson, & Zimmermann insurance company *

1 0

RE: Mixmaster status
by loki＠obscura.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I apologize for being so terse in my first message. This is not a red herring. The organization that has approached me is very pro-privacy and anonymity. I see nothing but good coming from this venture. I will be very active in the development of the commercial version of Mixmaster. Let me be crystal clear. 1) I will not support any version of Mixmaster that is weakened. 2) All future clients will be able to generate the current message format. 3) All future servers will be able to read the current message format. 4) There will always be a free version of the client with source code. While I have not discussed it, I can not imagine that there would not also be a free version of the server code (with source). Without remailers what is the point of the client software? At 8:45 PM 9/14/95, ROBO Mixmaster Remailer wrote: >Flame Remailer <remailer(a)flame.alias.net> wrote: > >> Subject: Mixmaster status >> >> There has been an offer to purchase and commercially develop Mixmaster. >> This will hasten the development of Mixmaster for other platforms (e.g. >> Dos, Windows Macintosh), and bring significant improvements to the >> interface, but I will not compromise on the level of security provided by >> Mixmaster. Free client software will continue to be available. >> >> This could be the big breakthrough for remailers, finally thrusting them >> out of the hobbyist's closet into the corporate world. >> >> I wonder. Where is the commercial market for remailers? Who has an >> application for them except hobbyinst? Why would there be a commercial >> incentive to run a mixmaster server, or even a client? >> >> Could this "offer" be a red herring? > >I wondered the same thing myself. It would certainly be a more >cost-effective way for the NSA to compromise Mixmaster technology >than by brute force. > >Consider this scenario ... Mixmaster get's bought by the Acme >Crypto Company of Ft. Meade, MD. They "improve" it, and offer a new >version. It's even FREE (for non-commerical use)! But their >"improvements" make it incompatible with previous versions, and so >you have to upgrade. The new "commercial" version comes with no >SOURCE CODE, of course... -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMFkzR/Pzr81BVjMVAQH6hAf+O+QdTEzNjUh0FYlJEnCakNws4MxPrOt4 miMPaz/aWDOReGb62UPZAEMNXP+hjgy0kTjW4xReTTBAPgtcsInr1Cct6MPr3O/r PGMGmE9z2Fkv3/k7MDG1NiptT2/RwVtmDikIJEQuH5j8ijir28Vvrk9Vs685Qc3j bFz5Q8uRLd57Uk51tQwIiBM6CJ4suQ3WFN++QNTHM9E47J9W8yFBux6ePWPlZOK8 8BnKkhY/auPm85X3MVZhL3y7F6zbFuqPpZrsKpwOOkme8o4l71t2xyhGcZHHxiB7 JLF2As9pNXsKWpYiPZEHTV9hsgxQTHortdhq25DeGyoxhZSrZByP/w== =+O16 -----END PGP SIGNATURE----- ---------------------------------------------------------- Lance Cottrell loki(a)obscura.com PGP 2.6 key available by finger or server. Mixmaster, the next generation remailer, is now available! http://obscura.com/~loki/Welcome.html or FTP to obscura.com "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche ----------------------------------------------------------

3 3

Why ecash is traceable
by Hal 17 Dec '03

17 Dec '03

There has been considerable discussion on sci.crypt and on the cypherpunks list about the fact that currently proposed digital cash is "traceable", or to put it another way, that there is no payee anonymity. This is an annoying asymmetry, where the payor is protected more than the payee. But there is a fundamental reason for this, which I want to explain here. It is not just perversity on the part of digital cash designers. The problem is that there is a conflict between the desire for payee anonymity and the need to prevent double spending. And preventing double spending is far more important, since without that the cash would be worthless. Here is how the conflict occurs. Suppose Alice has a piece of digital cash which she wants to spend with Bob. She goes through some protocol and transfers data to him. Bob, then or later, sends some resulting data to the bank and gets his account credited. Now if Alice spent that same coin with Charlie, we need to have the bank find it out. When Charlie deposits his data with the bank, and the bank compares that with what Bob sent in, there must be a red flag that goes up. The fundamental requirement of preventing double spending implies that Bob's and Charlie's data, when sent to the bank, has some correlation which will identify the fact that they both come from the same coin. It doesn't matter exactly what the form of this data is, or how it has been blinded and stirred, but if double spending is to be detected there must be a correlation which the bank can see. But this correlation is what makes the coin traceable. Suppose Alice is paying a coin to Bob via an anonymous network, and she and the bank are going to try to figure out who he really is. She goes through the payment transaction, and Bob sends his resulting data to the bank. Before doing so, though, Alice simulates a payment of the same coin to Charlie. Charlie doesn't actually have to be involved, Alice can just go through what she would have done if she had spent the coin elsewhere. The result of this simulated payment has been shared with the bank. Now, when Bob deposits his data, the bank compares it with the data Alice sent, the result of her simulated spending of the same coin. By the argument presented above, Bob's deposit will be flagged. It will correlate with the data Alice sent in since this will be the equivalent of a double-spending. So when Bob makes the deposit he can be linked to the specific coin payment which Alice made, and his anonymity is lost. It would seem that any system which is capable of detecting double- spending just from the information which the payees send in to the bank would be vulnerable to this. Systems which use tamper-proof observer chips to prevent double spending beforehand can avoid it, but of course if someone breaks an observer the whole cash system might crash. In general it does not look like payee anonymity is possible without giving up other very important features. Hal Finney hfinney(a)shell.portal.com

3 2

Re: Why ecash is traceable
by Bill Stewart 17 Dec '03

17 Dec '03

I first reacted to Hal's posting about the way Tim did. I got confused by the "Charlie" issue, but I think I see it. >Why not "online clearing" as the preferred model, then? It's probably still possible to do _some_ tracing in an online system. As in the previous example, Alice is going to conspire with the bank to catch Bob, _before_ she pays Bob the money; afterwards is too late. Alice creates an account Alice2 and spends the cash. Then she pays Bob the same cash. When Bob tries to deposit it, the bank notices it's already been spent, and does one of 1) rejects the payment using the normal double-spending prevention (not very useful for kidnapping/ransom cases, since Bob may kill the victim or whatever) 2) detects the double-spending but uses special-case software to tell Bob they're accepting the payment, and trace his account or trace the place he's depositing it from, or not actually credit it the money they're sending him a receipt for, or whatever. If Bob wants to prevent the bank from tracing his deposit back to him, he'll need an anonymous on-line connection; this would probably need to be some sort of packet laundry, which is easy enough to implement, or at least a fancy firewall. If Bob is a real Bad Guy (as opposed to Alice being the Bad Guy), Bob will probably set up some kind of temporary account at the bank to deposit the money in, followed rapidly by withdrawing the money and abandoning/closing the account. If Bob is a kidnapper, he probably kills the kid; if he's just an undocumented retailer, he may not ship the pharmaceuticals, or may start announcing that Alice is a probable narc. >[online clearing vs. double-spender detection] >I'm persuaded that the second approach, involving protocols for revealing >double spending, is much messier than the "he who gets there first" >protocol. The online clearing model largely emulates how real physical cash There are difficulties, with online clearing, though - with physi-cash, Bob can look at it and say "it looks good/bad" without actually possessing it; with online clearing, he can lie about "it was pre-spent", and there's no way to let him check the cash except by either giving it to him or using messy all-or-nothing-disclosure-of-secrets techniques (e.g. Alice and Bob flip a coin to decide whether Bob gets to spend a pre-committed digibuck or Alice gets to demonstrate that it's ok and spend it first) though an online system could reduce this problem substantially by recording the time that a given digicash was spent and reporting that time in double-spending rejections (a first-spending at approximately the same that Alice gives Bob the money and he deposits it is obviously suspicious; it doesn't actually identify which one of them cheated, though they'll both know (unless it was the bank cheating). A first-spending time substantially before that implicates Alice.) >Well, since Alice knows her own blinding factors, she will always be able >to say to the bank: "My cash will look like this. Watch for it." Unfortunately, it's probably a lot harder to design a blinding system that lets the payee blind the cash without allowing him to create forged bills (at least forged bills based on a hard-to-identify original bill.) >My hunch, just a hunch, is that Chaum has been concentrating on the >particular protocols which avoid online clearing and which avoid avoid the >payer/payee untraceability for pragmatic reasons. Pragmatic as in >"politically wise." maybe so... #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: More forged cancels (fwd)
by Michael Froomkin 17 Dec '03

17 Dec '03

why is my mailbox full of stuff from mail.cypherpunks? **** PLEASE NOTE NEW E-MAIL ADDRESS: froomkin(a)law.miami.edu ********* A. Michael Froomkin | +1 (305) 284-4285; +1 (305) 284-6506 (fax) Associate Professor of Law | U. Miami School of Law | froomkin(a)law.miami.edu P.O. Box 248087 | http://www.law.miami.edu/~froomkin Coral Gables, FL 33124 USA | New address, but it's still just as hot here. ---------- Forwarded message ---------- Received: from relay3.UU.NET by law.miami.edu (4.1/3.1.012693-University of Miami Law School); id AA16017 for IFS=' '&&exec /home/faculty/froomkin/proc/procmail -t -f-||exit 75 #froomkin; Mon, 2 Oct 95 01:17:37 EDT Received: from toad.com by relay3.UU.NET with SMTP id QQzjqz13374; Mon, 2 Oct 1995 01:16:43 -0400 Received: by toad.com id AA17355; Sun, 1 Oct 95 22:13:04 PDT Received: from hudson.lm.com by toad.com id AA17346; Sun, 1 Oct 95 22:12:56 PDT Received: (from news@localhost) by hudson.lm.com (8.6.11/8.6.9) id BAA09549 for cypherpunks(a)toad.com; Mon, 2 Oct 1995 01:15:28 -0400 Path: hudson.lm.com!news.math.psu.edu!news.cac.psu.edu!newsserver.jvnc.net!newsse… >From: orbit(a)ix.netcom.com (Michael R. Grabois) Newsgroups: news.admin.net-abuse.misc,soc.culture.german,soc.culture.jewish,rec.radio.shortwave,alt.2600,mail.cypherpunks,alt.privacy.anon-server,alt.stop.spamming,alt.stop-spamming Subject: Re: More forged cancels Date: Mon, 02 Oct 1995 03:31:03 GMT Organization: Netcom Lines: 40 Message-Id: <44nmd0$q13(a)ixnews6.ix.netcom.com> References: <44n926$2dj(a)sundog.tiac.net> Reply-To: orbit(a)ix.netcom.com Nntp-Posting-Host: ix-hou6-03.ix.netcom.com X-Netcom-Date: Sun Oct 01 8:30:40 PM PDT 1995 X-Newsreader: Forte Free Agent 1.0.82 Xref: hudson.lm.com news.admin.net-abuse.misc:16173 soc.culture.german:76152 soc.culture.jewish:188004 rec.radio.shortwave:63171 alt.2600:125976 mail.cypherpunks:18586 alt.privacy.anon-server:4465 Apparently-To: cypherpunks(a)toad.com Sender: owner-cypherpunks(a)toad.com Precedence: bulk On Sun, 01 Oct 1995 23:45:24 GMT, jbyrd(a)tiac.net (Jim Byrd) wrote: [snip] >-----------------begin control message >Path: >sundog.tiac.net!news.sprintlink.net!in2.uu.net!sunic!mn6.swip.net!seunet!news2..swip..net!plug..ne >ws.pipex.net!pipex!tank.news.pipex.net!pipex!usenet.eel.ufl.edu!news.gmi..edu!msunews!netnew >s.upenn.edu!ts7-28.upenn.edu!user >From: 73323.603(a)compuserve.com >Newsgroups: soc.culture.german,soc.culture.jewish >Subject: cmsg cancel <73323.603-3009951517290001(a)ts7-28.upenn.edu> >Date: Sun, 1 Oct 1995 17:56 GMT >Organization: The National Alliance >Message-ID: <cancel.73323.603-3009951517290001(a)ts7-28.upenn.edu> >NNTP-Posting-Host: ts7-28.upenn.edu >Approved: 73323.603(a)compuserve.com >Control: cancel <73323.603-3009951517290001(a)ts7-28.upenn.edu> >X-Cancelled-By: 73323.603(a)compuserve.com >Lines: 1 >CANCELLED. >----end control message Does this mean that the cancel came from the Compuserve account? Forging cancel notices is definitely against CIS rules, as is unsolicited e-mail. I've already talked to a sysop there about it, and he said he'd pass it along to the CIS Security folks. If nothing else, that may get his account revoked. Hey, small victories. Michael R. Grabois | orbit(a)ix.netcom.com Houston, TX | CI$: 74737,2600 ------------------------------------------------------- Gravity. It's not just a good idea, it's the law.

1 0

Certificate proposal
by Carl Ellison 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- X.509 certificates are not totally bad. Their structure contains lessons for anyone designing a certificate structure. [Raw X.509 does not imply a hierarchy, I believe. Steve Kent & Co. do.] However, there are also some serious problems with X.509 certs, aside from their use of ASN.1. Perhaps the biggest problem is the use of a name -- a text string (or some abortion like the DN which can be reduced to a text string) -- as the anchor point. This anchor point needs to be unique. Since it is just a text string, that means that the certificate authority needs to guarantee uniqueness. However, it is also supposed to stand for a unique individual. Since it is not that individual's DNA sequence -- it is not testable. There has to be machinery set up outside the certificate definition for binding this text string to its individual. ------------------------------ PGP certificates have the same problem. In that case, it is an e-mail address and name (by tradition) as the text string. That needs to be bound to some physical body. If it is an e-mail name, there is some binding enforced by whatever access mechanisms protect access to that e-mail account. However, that binding is weak and also outside the certificate definition. ------------------------------ Let me propose an alternative unique name: the public key (or a good hash of it). The public key has an advantage over both X.509 and PGP names. The binding between it and its human being is testable. You can challenge the human in question to sign something. Assuming you use a public key as the unique name, you end up with a much simplified certificate. In fact, the notion of "certificate" may go away, in the sense that the certificate binds a key to a person through a unique name. The person binds himself to his key, on challenge (or on any message signature). What remains is a need for attributes to be bound to a key. For example, someone might testify that E0414C79B5AF36750217BC1A57386478 has brown hair, is balding and wears a pony tail, by signing a message to that effect. Someone else might sign a message stating that the person who owns the private key of 61E2DE7FCB9D7984E9C8048BA63221A2 is authorized to spend money from bank account number 07123 of Provident Savings in Columbia MD. That latter signator needs to be verified as authorized to make such an assertion -- and you end up with a certification chain -- but it is not hierarchical like X.509 and it is not web-of-trust -- it is relational. It is not a chain binding key to person but key's person to attribute or permission. It goes directly to what we need to accomplish without the middleman -- without stopping at a person in the middle. I realize that if you want to revoke a key, then it might help to have bindings be to something other than the key. That way, you can change keys out from under the binding. However, every method I've examined for accomplishing that has security weaknesses. The best method I've found yet has a very long signature key -- used only rarely (e.g., when acquiring an attribute-certificate worth a great deal; and signing more transient keys) -- and never normally revoked (or, if revoked, causing a widespread re-establishment of bindings -- like when you lose your wallet today). ------------------------------ Current certificates are going down a fundamentally wrong path. They are trying to bind keys to people and let Society somehow bind attributes to people -- but the latter binding is too weak to permit keys to be bound to attributes or permissions. The community will discover this, soon, but the farther we play along the X.509 path (especially, but also the PGP path), the more inertia there will be to overcome in trying to fix this problem. I would therefore suggest that the PGP development process address this issue now and continue the established habit of taking the lead into sanity. - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)acm.org http://www.clark.net/pub/cme | |PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2 | | ``Officer, officer, arrest that man! He's whistling a dirty song.'' | +---------------------------------------------- Jean Ellison (aka Mother) -+ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMHAK8FQXJENzYr45AQFsdAP+JswAq/H4JIDE3+VlMsi87PBPCNBA7jg7 0ftkd8v7vrSSNda5aF+HVB7oKHylA/Lb90bvjMK7CKOJJ7aTzRP9IsAiz1i48FAR LAeD59v5SAKmAhaTMMYSRyKFRRXEaqIdEoJW3XKQBJ57b8R38vWKjR/11eTtCKjV joH4c5hhWmY= =ayYh -----END PGP SIGNATURE-----

10 16

Re: Linking = Showing = Transferring?
by aba＠dcs.exeter.ac.uk 17 Dec '03

17 Dec '03

Rich Salz <rsalz(a)osf.org> writes: > >Suppose we interpret Linking = Showing as > > > >For all web pages x and y, > >Showing(x) and Linkto(x,y) --> Showing(y) > > Then we would be fools. No more so than buying a book means you > have instant access to all resources mentioned as footnotes or in > the bibliography. > > Put more simply, *you have to click on Y* so they're not the same. Another even more subtle problem is inline images, can you say that a page with an inline image sourced from a foreign site must obey the foreign jurisdiction. I would assert this is so, because the web surfer's *browser* imports the relevant parts of the page from whatever locations (and jurisdictions) they are in, and displays them as one page. Take a look at: http://www.obscura.com/~shirt/ which is the www space Lance kindly donated for the UK munitions-T. The relevance to this discussion is that www.obscura.com is of course in the US, whilst the inline graphic is in the UK for ITAR reasons, the is of: #!/bin/perl -s-- -export-a-crypto-system-sig -RSA-3-lines-PERL $m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2%Sa 2/d0<X+d*La1=z\U$n%0]SX$k"[$m*]\EszlXx++p|dc`,s/^.|\W//g,print pack('H*',$_)while read(STDIN,$m,($w=2*$d-1+length($n)&~1)/2) ie the html looks like: <img src="http://www.dcs.ex.ac.uk/~aba/obscura/rsa.gif"> So that the image is *imported* by the *viewer*, and not supplied by www.obscura. This means that people outside the US can also view the page with out anyone breaking any laws, even though it appears to contain (allegedly) ITAR contravening material. Same would apply quite nicely to porn from the netherlands etc. [as an aside, any one got info on how you go about converting gifs to transparent gifs - I want the above to be transparent so that it still works on other than a black background in case other people use it on other backgrounds] Adam

1 0

netscape bug
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

clearly the netscape engineers did not practice "safe crypto programming", but I question the seriousness of the crack. none of the articles mention that the cracker must have login access to the computer that the random numbers are generated on. is this true? does the code require knowledge of the PID etc. that can only be obtained by a login to the system that the netscape session is running on? if this is true (i.e. login access required) this bug is by far not as serious as some of the hyperbole is suggesting. I agree it is still very insecure but the most dangerous crypto bugs are those where you can determine keys from data alone.. physical penetration into a machine is another level of security.. furthermore, I would like to commend Netscape for their fast response to the problem and apparent commitment to establishing safeguards that avoid it in the future. cypherpunks have an easy time ridiculing someone who slit their throat on writing some crypto functions, but geez, cut them some slack: crypto stuff has so many pitfalls and bugaboos that even the world-class experts make mistakes. where else can not properly "burning" stack registers (function parameters) and environment variables be considered "lethal"??? PGP errors have been reported on numerous occasions, some in the randomizer code. do people call for Zimmermann's head on a stick and call him "incompetent"? often when cryptographers say something is "broken" it can still mean that it is not necessarily unsafe in practice. there are many shades of "broken", some requiring a Cray and other's requiring a PC. I am really surprised how much people here consider "broken is broken". this is only the extreme theoretical perspective. granted I am not advocating that people *not*fix* bad crypto functions, I'm only saying that maybe its not in everyone's best interest to run around and say "the sky is falling" and lambaste companies for minor difficulties.. Netscape is a world class product, and it's *free*. on this cypherpunks list, I have seen no end to the venemous criticisms that people level at *free* products, which IMHO is quite tasteless at times. Netscape has done far more for the cypherpunk cause than many, many companies just by including RC4 in their product. they have taken some heat for their decisions & code, but they are on the front lines of battle. now instead of our vague claims about how the world can benefit from good crypto, how it is immensely valuable and important to cyberspatial financial transactions, to promote the cypherpunk cause, we now have something *popular*, *physical*, and *tangible* to point to: netscape!! this is *not* vaporware. this is not some cpunk saying, "all one needs is [x] algorithm running on [y] network and you have a world class infrastructure". the amount of work to get something like Netscape into the world is quite daunting and herculean. we owe a great debt to netscape and their accomplishments for furthering our own agenda!!! please do not trivialize what they have accomplished!! Netscape is here, it works, and it is cyberspatial crypto that Joe Sixpack can understand and *use*!! it is not a toy remailer, it is not some PGP front end, it is not some mailer script, *this* is the format in which Joe Sixpack will be using crypto in the future, the format which will bring "crypto to the unwashed masses"!! Netscape may very well be the chief vehicle that puts on *concrete pressure* on our government to relax crypto export laws. I see this happening *right now* with them going to a 64 bit key from a 40 bit one, and the world starting to realize the importance of crypto and the idiocy of the export laws. I am really amazed at how few seem to be supporting Netscape here and considering them the *premiere ally* in our current battle. it reminds me of how much people here rant at Microsoft when virtually no other company on the planet could pull off what they make look easy (ah, that's another story I've filled up other posts with). please do *not* take an adversarial relationship with the companies who are helping advance the cutting edge of cyberspace!! do *not* ridicule them. rather, help them to understand their problems. I think you will find that most companies are *not* hostile to improving their software, and will readily admit it when it needs fixing (intel has been humbled by their pentium glitch, and I doubt any company again will ever be so obstinate and belligerent..) . I am willing to bet that the netscape bug would have been fixed quickly if it had been quietly brought to their attention, without the blaring media lights (I enjoy the media circus as much as the next guy, but on the other hand, doing some things quietly may actually advance the cypherpunk cause further than by making a noisy hullaballoo in cyberspace). once again I commend Netscape for their fine software and willingness to perfect it. netscape is at the cutting edge of advancing key cyberspace technologies and it is not surprising that they make some minor mistakes with the code in these early phases. cyberspace is very young!! give designers a bit of time to get it right. be patient!! do not accuse them of incompetence!! netscape is tens of thousands of lines of world-class code. only in programming can a few moments of total, rapt attention lead to bugs that get blared on the front page of new york times and affect your stock price!! good lord, give the guys a break. cpunks: when Netscape has some serious competitors, they will get their act together. but at the moment they are the only game in town, and it will pay off to be nice to them, and try to support them, instead of kicking them in the teeth and wringing them every time they make a mistake. few in the world are as knowledgeable or paranoid as we are about security, and its going to be a gradual process to get to even a fraction of the expertise here penetrating the mainstream software industry. be patient!! -- P.M. notes that anywhere there is a data-driven buffer overflow (which he suspects are all over netscape) he can get code to execute anything he wants. this reminds me of the Morris internet worm that ran exactly the same way. it used a bug in the finger demon that caused a string buffer overwrite (via strcpy, instead of strncpy) to execute customized code. my question: I have not seen the specifics of how this works. does this require specialized knowledge of the native machine language on the host machine? or is it just used to cause something like a core dump to get a command line or something like that? --Vlad Nuri

3 2

Re: Cypherpunks Hold a Cracking Party
by Duncan Frissell 17 Dec '03

17 Dec '03

At 11:28 AM 9/19/95 -0400, Duncan Frissell wrote: >Just to let everyone know that I've got an assignment from Wired to do a >story with the above working title. > As it turns out, Steven Levy and I had an assignment collision at Wired and were both assigned the story. For some unknown reason, they wanted him to do it instead of me so I will *not* be doing it. Steve -- feel free to use my title if you like. DCF "Anyone know any publications interested in an article on the Crack?"

2 1