- 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

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

Re: netscape bug
by David_A Wagner 17 Dec '03

17 Dec '03

In article <199509201855.LAA17261(a)netcom16.netcom.com> you write: > > 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? > No, the time, pid, and ppid often leak to a remote adversary too. The attack probably requires a bit more sophistication when the cracker doesn't have login access, but I believe it's still possible. See my recent post to sci.crypt for some comments from Ian & I about this.

1 0