December 2003 - cypherpunks-legacy

Re: Linking = Showing = Transferring?
by dsc＠swcp.com 17 Dec '03

17 Dec '03

Whoops! I mentioned the "linking to a page that links to a page..." problem without noticing that Joseph Sokol-Margolis had already brought it up. Maybe pornography is not in the page (or resource) but in the browser. For example, I have a "pornography enabled" browser, because I can use it to access pornopages. What if I set up a browser for my child that saw a smaller view of the net that did not include pornopages. That browser would not be "pornography enabled". The limited view could be created from some combination of lists of OK sites & pages, lists of off-limits sites & pages, and certification requirements for those in between (virtual OK lists). I have seen the off-limits lists in association with some blocking products. Frank Stuart wrote, >And then there's the problem of URLs not being static. What may be a perfectly >innocuos link one day may turn into something not perceived as harmless the >next. The blocking (off-limits) lists are then always behind and flawed. Better OK lists might be created by the list publisher having contractual commitments from the site owner. A virtual OK list publisher would publish the key for verifying approved pages that have built-in certs. This would provide the better probability that the browser was not pornography enabled. A page would not show if it had been changed. A problem to be solved would be doing this with minimal psychological time costs to the user. Another is making sure that getting certs would not be such a pain that only a few sites would be on the virtual OK list. Of course, I would not want my kids under 10 to see certain ideological pages and there might not be a market to justify certs. I would have to make my own list or get a cheap blocking list or something from the major-group-with-same-ideological-bent-as-dar ftp site. Dar =========================================================== Dar Scott Home phone: +1 505 299 9497 Dar Scott Consulting Voice: +1 505 299 5790 8637 Horacio Place NE Email: darscott(a)aol.com Albuquerque, NM 87111 dsc(a)swcp.com Fax: +1 505 898 6525 http://www.swcp.com/~correspo/DSC/DarScott.html ===========================================================

1 0

Re: Celco Sting
by Rich Salz 17 Dec '03

17 Dec '03

> A computer "hacker" is an individual with expertise in gaining > unauthorized entry into computer systems. I heard the special agent in charge being interviewed on NPR this morning. He was very careful to distinguish between "classic hackers" who just poke around for their own edification, and those who are using networks to actively commit crimes. My paraphrase, but it was definitely a praiseworthy viewpoint. /r$

1 0

Re: Linking = Showing = Transferring?
by Rich Salz 17 Dec '03

17 Dec '03

>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. /r$

1 0

Re: Explaining Zero Knowledge to your children
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 6:18 PM 9/14/95, Hadmut Danisch wrote: >There is a paper about explaining Zero Knowledge methods in simple >words. It's titled "Explainig Zero Knowledge Authentication to your >children" or something similar. It's said to be in the proceedings of >any conference. Does anybody know where to find it? Schneier describes the "cave" analogy in his book, on p. 85, and gives a reference: Quisquater, Guilou, Berson, "How to Explain Zero-Knowledge Protocols to your Children," Advances in Cryptology--CRYPTO '89 Proceedings. The paper is only a couple of pages long and would make a nice scan project for someone, as it has no equations. But Schneier is the easiest way to read up on it. --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

RE: Mixmaster status
by ROBO Mixmaster Remailer 17 Dec '03

17 Dec '03

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...

1 0

[non-crypto] Any info on Motorola Digital cell phone?
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Well, I finally broke down and bought a cell phone. Motorola Digital 52134 flip style. Would the (numerous) cell phone pros on this list please get in touch with me and teach me the things not mentioned in the manual? Thanks guys and gals, - -- - -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred. - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMFj/pyoZzwIn1bdtAQGVTAGAmjw4ryqx3SiaPyFscACXsgCfq7ATT5EZ 8URi+2KH2e5xSLeOgj0+R+Z6Bcvvxoas =zXFO -----END PGP SIGNATURE-----

1 0

Re: Why ecash is traceable
by tcmay＠got.net 17 Dec '03

17 Dec '03

Hal, a very nice summary! I have some questions, though. At 5:32 AM 9/15/95, Hal wrote: >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. Agreed, any system which allows makes double spending possible results in a currency collapse as the currency becomes worthless. Chaum points out that there "is no digital coin," that is, that software (numbers) must by their nature be easily copyable. Thus, any system to prevent double (triple, quadruple, etc.) spending must take this into account. Why not "online clearing" as the preferred model, then? To use your example: >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. With online clearing, Bob sends his data to the relevant bank, confirms that his account has been credited, and tells Alice that her "check has cleared," so to speak, and the transaction is completed. Then, when Alice tries to spend the "same" digital cash with Charlie, he sends his data to the bank and the bank tells him the money has already been spent. Charlie informs Alice that the transaction has failed, that her money is no good. I'm not claiming this is how Chaum's currently-available system works, only that nothing in Chaum's scheme hinges on a True Name, of course. So with online clearing, the second spending is blocked, but there is still no leakage of identity, is there? >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. I agree. But this is like the following analogy: Alice has a special kind of money, called a "train locker combination." This special kind of money is the location of a storage locker and the combination of a lock on the locker. She "spends" this special kind of money by giving this information to the person she is paying. The recipient has a couple of basic options: 1. Send someone to verify that the locker contains the specified goods, at which point the transaction is completed. This is equivalent to ONLINE CLEARING. (I'm not going to get into the situation where he gets the money, then cancels or reneges on the deal....this is a possibility in "cash" transactions as well, save with escrow schemes, and even then...) 2. Accept the word of Alice (in the sense of not actually transferring the money via online clearing) and count on systems which implicate her if she tries to spend the money a second time, i.e., tries to tell someone else the locker and combination. (The "observer chip" option Chaum raises, and which may have a parallel here, I'm not considering. I'm deeply suspicious of solutions calling for tamper-resistant hardware...just not very strong by cryptographic standards, etc. Maybe I'm just ignorant, but the observer chip approach Chaum described in his "Scientific American" article a few years ago was unconvincing to me.) The elegance of the first option, online clearing, is that Alice is motivated to keep her secret information (the money) secret, and that once it is "spent," or cleared and transferred, there's no going back. She can't renege, she can't collude with the bank to see where it went. The bank, upon valid receipt of an order to "cash" the "check" then could place the money in an "envelope" (in Chaum's terms) supplied by Bob and then post it in a message pool. (Bob can submit his claim to the money via remailers, and receive the money-in-envelope via remailer return replies (if they ever get perfected, as I suspect they will be) or via message pools. Bob receives the envelope and reverses the blinding operation, thus having cash not traceable to him in any way. 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 works, where there is a direct transfer, where the cash must be protected against loss (lose it and you're just out of luck, unlike, say, as with traveller's checks, which are account-based), and where a kind of "online clearing" is actually done when the cash is checked to see if it's counterfeit. >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. With online clearing, this kind of "sting" by Alice is impossible (at least in the way described here). Alice pays Bob, Bob sends his data to the bank, the bank reports the money has already been transferred (or, simply reports back "invalid transaction"). An account-based system, one that doesn't do online clearing, will need the correlation that Hal cites. An online system will not...whoever gets to the money first gets it, as with real cash. (There are more abstract ways of viewing this advantage. While mere software is always duplicable, and cash numbers are of course duplicable, one thing that is not duplicable is this: "the first agent to present a valid number at this bank." There can be only one of these, and this uniqueness is what keeps the currency from collapsing, what introduces _conservation_ into the system.) >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. 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." The key is for Bob to take the cash Alice gives him and communicate to and from the bank with mixes, as described above. Bank / \ / \ / \ Alice - - - Bob (Sorry I can't flesh out this diagram....ASCII just won't cut it. Mere English is even worse at describing these transactions.) Another elegant way of viewing things: If Alice colludes with the bank, by doing a fake-spend with the fake "Charlie," or by reporting to the bank what her blinding factor will be and hence what "her" cash will look like, then effectively the transaction collapses to: Alice/Bank \ \ \ Bob But if Bob can get cash from the bank that the bank cannot trace, via the blinding factors, then Bob can get cash from the Alice/Bob collusion. The fact that Alice can correlate a particular transaction to Bob's contact with the bank can be defeated by Bob using anonymous remailers to protect his identity. My Apologies: I suspect I've been rambling a bit, thinking out loud by typing. There are different issues involved here: offline vs. account-based systems, the use of remailers and message pools to sever the links between transactions and identities, and the (mostly unmentioned) role of third-part escrow agents and "anonymizers." (Think of what happens when online clearing is used to shuttle the cash between N different agents...even if Alice is colluding, will Candy, Devon, Eric, Floyd, etc. all be in the same collusion set?) >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. I don't think all systems must be able to deal with double spending. For example, the first person to read this number: 45%2)d[12ks&Qmdx and to then submit it any form--in person, by e-mail, via remailer, etc.--to The First Bank of Cyberspace will have $10 sent to him or her, as cash or as a spendable amount of digicash (untraceable to recipient, of course). Where's the payee traceability that I, the payer, have? (The key is that I don't have to deal with double spending, as there is only one "first person to ....") I believe Chaum has thought about the issues in creating "Pure Digital Cash." While a pure "digital coin" may not be possible, I believe a two-way untraceable digital cash system is possible. Frankly, I think Chaum's work on DC-Nets points the way, though even simpler realizations may be enough for practical purposes. 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." --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

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

Check Cloning frenzy and attack on anonymous accounts
by Black Unicorn 17 Dec '03

17 Dec '03

Cypherpunks might want to take note of the recent flurry of news program stings on banks which do not demand 12 pieces of identification in order to open an account. The latest horseman, check "cloners." Two networks have now run hidden camera stings on banks where they offer all manner of obnoxious fake identification and open accounts in silly names. The "purpose" being to expose the ease with which a dreaded check "cloner" can open an account to transfer your funds into. The process goes something like this: Check cloner gets account number from ATM slip or otherwise. Check cloner prints up 30 "checks" in any name at all with magnetic ink account number on the bottom for the benefit of automatic readers at the bank. Checks are written to the account in false name and withdrawn. For some reason, the focus seems to be on the ease with which one opens an account- rather than with the need to safeguard account information, and the lack of oversight by banks. Of course, the liability for these crimes is with the bank, which cleared a check without the proper signature. Of course, the immediate solution, rather than insuring the banks pay their liability for their insecure payments and check clearing system, and their printing account information on any piece of paper they can find, is going to be a crackdown on account identification- and probably legislation. (Note that often banks take months to pay the shortfall- when they do at all). New accounts can expect to have to cough up significant identification and I predict a re-newed call for national identification credentials. Tell the banks they have to pay within 2 days of the presentation by the duped depositor of the fraudulent checks and I would lay odds that the banks would be screaming bloody murder for a more secure payments and check clearing system than the trash they have now. Of course, because of the ignorance of the media, this will never happen. Of course, paying in cash will never be looked to as an answer either. Typical creeping statism. I suggest those of you who open clandestine accounts open a flurry now, before things get tough.

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: 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: Scientology/Wollersheim as test case for key disclosure
by Bill Stewart 17 Dec '03

17 Dec '03

At 02:42 PM 9/9/95 -0400, Phill wrote: >One solution to this problem would be to modify PGP so that the session key for >the document was released rather than the passphrase for the public key. The >former would provide only read access, the latter would allow th scientologists >to forge Wollerstein's signature on other material. In addition many of the >documents may be subject to privillege. It wouldn't be hard, though I'm not sure it's much different from requiring the owner of the public key to decrypt the document in the first place. It does give you some verifiability (somebody else can take the session key and demonstrate that encrypting it with the recipient's public key does or does not produce the encrypted-key string in the document being verified.) If that's what you plan to use it for, you would also need to have the entire padded session key and not just the session key itself. Total amount of work to implement - another command-line option, a print statement, and maybe another command-line option and bit of code to allow decryption of a public-key-encrypted document using a command-line-supplied session key. #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

RE: Mixmaster status
by Alan Olsen 17 Dec '03

17 Dec '03

>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. But will the commercial version of the server come 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? Will Mixmaster become the Netscape(tm) of remailers? And when is the IPO? ];> | Visualize whirled keys | alano(a)teleport.com | |"It's only half a keyserver. I had to split the | Disclaimer: | |other half with the government man." - Black Art | Ignore the man | | -- PGP 2.6.2 key available on request -- | behind the keyboard.| | http://www.teleport.com/~alano | <fnord> |

1 0

Re: cryptography eliminates lawyers?
by liberty＠gate.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Brian Davis wrote: <snip> >Last I checked, FDA, UL, or state bar association approval does not >*require* you to take, use, or hire the approved drug, toaster or lawyer. >Market forces are still at work, albeit in a filtered environment. The filter is weakest from UL, yet I trust its output the most. >Just a first cut. And even that can usually be gotten around. Getting around David KeSSler involves about $30 million and a *bunch* of lawyers. Skipping this first cut, even with far safer products (IMO) than "Proscar," can lead to an armed raid of your doctor's office. If state bars can usually be gotten around, why take three of them? JMR -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Freedom isn't Freeh iQCVAwUBMFk2Jm1lp8bpvW01AQESMwP/abBCBbhGKOjVFFkjl4elOcTA3oD9WgEa e+AsmtuLSEstvSfZ6u3CxO5sfu0lka0erBsVyDjqWs97WlvQOD0qX+3O91hoURp4 pytfTSE+MtTlIQCIoxVBMgjOYplNLOOYmnomksypJFpOzyuofoYnIScfRLkAWvAB SFEqvrCtfP8= =cfgW -----END PGP SIGNATURE----- Regards, Jim Ray "When making public-policy decisions for the government, I think one should ask oneself which technologies would best strengthen the hand of a police state. Then, do not allow the government to deploy those technologies." -- Phillip Zimmermann, talking to himself. (Congress sure-as-hell wasn't paying attention!) ----------------------------------------------------------------------- PGP key Fingerprint 51 5D A2 C3 92 2C 56 BE 53 2D 9C A1 B3 50 C9 C8 Key id. # E9BD6D35 James M. Ray <liberty(a)gate.net> ----------------------------------------------------------------------- Help Phil! email zldf(a)clark.net or see http://www.netresponse.com/zldf _______________________________________________________________________

1 0

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

Some informed comments on RSA's S/MIME
by Rich Salz 17 Dec '03

17 Dec '03

Date: Thu, 14 Sep 1995 08:39:49 -0700 (PDT) >From: Ned Freed <NED(a)innosoft.com> Subject: Re: Re[2]: MOSS conformance testing Cc: pem-dev(a)TIS.COM Message-id: <01HV9F2PHBSU8Y4Z8U(a)INNOSOFT.COM> > I just got wind of RSA's draft for Content-Type: application/x-pkcs7-mime. > Has there been any discussion on this - comparison to PEM etc.? If so > where's the list, URLs of archives....? Or did I just go "deaf" for a while > here on thist list? (The last could of months have been caught up in > changing companines...) S/MIME was developed privately by RSA in conjunction with a number of other companies. To the best of my knowledge all discussion has occurred on closed, private lists. As a potential customer of RSA I recently managed to get myself added to one of these lists (it may or may not be the only one where S/MIME is discussed) but I haven't had time to post anything there yet. I plan to post this message there in the next couple of days. I'm not saying this approach to protocol development is a good thing or a bad thing, but I do believe that it has led to the production of a specification that is seriously flawed, and that those flaws would have been detected and probably corrected had the discussion been more public. More on this below. > I browsed through the IETF drafts & personal contributions & search tool... > didn't find anything on RSA's "S/MIME". > I did get the PostScript file from RSA's pages & had a read.... > http://www.rsa.com/pub/S-MIME/ The specification, at least, is public. Given the amount of press surrounding this proposal and the strong liklihood of it being widely used I strongly recommend that everyone who is interested in email security obtain a copy of the specification and read it. However, the proposal is simple enough that it can be summarized in just two paragraphs. S/MIME is based on PKCS #7, which in turn is based on classic PEM. The significant difference between PKCS #7 and PEM is that it uses an ASN.1 encoding for the entire security object rather than the header/text encoding of RFC1421. In fact the specification states that mechanical conversion between RFC1421 formats and PKCS #7 should be possible as long as the proper set of algorithms are used. I think that mechanical conversion into and out of the PEM-derived subset of MOSS is also feasible but I haven't checked up on the specifics of this. S/MIME in turn is a simple encapsulation of PKCS #7 in MIME, consisting of an application subtype label and an encoding of the PKCS #7 object using standard MIME encodings. The inner secured content is then seen as another MIME object. This is almost identical to Jeff Schiller's earlier proposal for embedding PEM in MIME. There is only one significant twist -- in the case of signed but not encrypted data the specification calls for the use of multipart/alternative, with the first part being an unsigned copy of the signed data and the second part being the PKCS #7 object, including the signed data. Two obvious flaws in this approach should be obvious from this description. The first is simply one of excessive overhead -- sending signed material in such a way that it can be read on vanilla email systems as well as with an S/MIME system introduces something on the order of 133% overhead. The second flaw is more serious. The data that a user without S/MIME reads is not signed. This opens the door to attacks where the unsigned version is tampered with but the signed version is left alone. This turns into a really insidious problem when you consider how privacy services are likely to be deployed in some environments. One model I expect to be rather popular is that of having a remote signature verification service within a secure enclave. That is, most of the user agents that people use won't have the ability to validate a signature. Users will, however, have secure access to an agent that will validate the signature on a message for them. (The service may well be a different application on the same machine.) They simply submit the message to this service and it tells them whether or not the signature matches. The problem, of course, is that the material the user of the unextended agent reads isn't what's signed. And in general there is no way to correlate this material with the signed copy -- since it was exposed to the message transport layer without any special tagging to indicate its signed nature the transport may well have changed it so its no longer a byte-for-byte copy of the signed version (which is inherently protected against such munging). Comparing this approach with security multiparts is quite instructive. Security multiparts only introduces the overhead necessary to encode the single copy of the data -- at most 33% in the case of base64 -- plus of course the fixed overhead of the signature information. As such, it is far more efficient than S/MIME when it comes to signed but unencrypted material. Security multiparts can be processed in a single pass as well. I'm not sure this is true of S/MIME -- it depends on the specifics of the ASN.1 structure that's used. But by far the most important difference is that security multiparts do not suffer from this vulnerability when used in an environment with remote security servers. You can of couse avoid this problem by not including the extra copy of the signed material. The problem with this approach is that you won't be able to read such a message on anything short of an agent that knows how to take apart a PKCS #7 structure. I note in passing that there was absolutely no reason why security multiparts could not have been used in S/MIME instead of the chosen encapsulation. PKCS #7 explicitly provides a facility whereby the secured data is stored outside of the ASN.1 object. This then fits seamlessly into the security multiparts methodology. I do not propose to debate the relative merits of PKCS #7 versus MOSS. Modulo the MIME issues this is essentially the same as debating the merits of PEM versus MOSS, and I've had more of that than I care for. Besides, I think folks should use whatever security service they feel like using. I've maintained all along that my interest is primarily that of standardizing on a single embedding methodology for use with MIME. I'm very disappointed that S/MIME has seen fit to use what to my mind is a technically inferior embedding solution when compared to security multiparts, and I'd really like to try to get the S/MIME folks to switch to a security multiparts approach if its not too late for them to do so. I'm very interested in any and all comments on what I've written here. I intend to post them to the S/MIME list I'm now on. Ned

1 0

Re: Why ecash is traceable
by Pat Farrell 17 Dec '03

17 Dec '03

tcmay(a)got.net (Timothy C. May) writes: > Hal, a very nice summary! Yes, good job Hal. > Why not "online clearing" as the preferred model, then? Because you lose most (all?) anonymous abilities. (I think) > (There are more abstract ways of viewing this advantage. While mere > software is always duplicable, and cash numbers are of course duplicable, > one thing that is not duplicable is this: "the first agent to present a > valid number at this bank." There can be only one of these, and this > uniqueness is what keeps the currency from collapsing, what introduces > _conservation_ into the system.) > > 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." So when the money Alice gave to Bob gets deposited by TCMay, That it was Alice's is instantly known. This is not how physical cash works. There is a chain from TCMay through some number of steps to Bob. Even if you can't find it with this single case, you could use a zero-knowledge type proof to slowly uncover Bob's identity. I keep wanting to believe in ecash, but I'm not convinced it can exist. Pat Pat Farrell Grad Student http://www.isse.gmu.edu/students/pfarrell Info. Systems & Software Engineering, George Mason University, Fairfax, VA PGP key available on homepage #include <standard.disclaimer>

3 2

VIO_lat
by John Young 17 Dec '03

17 Dec '03

9-15-95. NYPaper: "Company Says Electronic Mail Was Opened to Find Pornography." America Online gave the FBI access to the mailboxes of its subscribers to identify several thousand users who viewed images of children in sexual poses and to trace messages beyond AOL to many more computer users nationwide. Because electronic mail has a life of days or weeks, can be traced and can be easily copied without alerting the owner, reading the mailboxes was particularly effective. It was unclear how much information about subscribers is routinely kept and how much private information was provided to the FBI. Actions of users can be recorded and can reveal much more personal information than the records a telephone company. "F.B.I. Chemist Says Experts Are Pressured To Skew Tests." Officials at the F.B.I. crime laboratory have been accused by one of its chemists, Frederic Whitehurst, of pressuring forensic experts to commit perjury to help secure criminal convictions. With opinion polls showing public support for the F.B.I. eroding after Congressional hearings into the Branch Davidian siege, the accusations regarding the laboratory are in some ways the worst blow yet. Two: VIO_lat (11 kb)

1 0

Chiffrement en Fr
by anonymous＠freezone.remailer 17 Dec '03

17 Dec '03

A web search for Quisquater led to: URL: http://www.cnam.fr/Network/Crypto/ which offers, among other belle chiffre-escrits: L'UTILISATION DU CHIFFREMENT EN FRANCE Le chiffrement est la technique qui consiste à modifier un fichier de façon à le rendre illisible par les personnes auxquelles il n'est pas destiné. Pendant longtemps l'apanage des militaires, il est maintenant un outil indispensable à l'ère des réseaux pour ceux qui veulent protéger la confidentialité de leurs messages. Son utilisation soulève diverses questions. Si cette page Web est l'une des premières en France, il en existe de nombreuses aux Etats-Unis . Je ne parlerai pas beaucoup de technique sur cette page. Si vous voulez en savoir plus, regardez : * L'excellent serveur du Groupe de Recherche en Complexité et Cryptographie, * Quelques modestes explications. Le chiffrement est pratiquement interdit en France par la loi 90-1170 du 29 décembre 1990 (avec décret d'application en décembre 1992). Une excellente petite brochure (avec un sphinx sur la couverture :-) de la Délégation Interministérielle pour la Sécurité des Systèmes d'Information (DISSI) explique cette loi (mais malheureusement ne détaille pas ses conditions réelles d'application). Elle est envoyée gratuitement sur simple demande : DISSI 3 avenue Octave Gréard 75007 PARIS C'est le Service Central de la Securite des Systemes d'Information (SCSSI) qui doit etre contacté pour plus d'information et dépôt des demandes d'autorisation. Il existe deux cas : 1. Soit vous utilisez le chiffrement à seule fin d'authentification (chiffrement de mots de passe pour qu'ils ne circulent pas en clair sur le réseau, par exemple) : il faut faire une déclaration au SCSSI qui est ensuite vérifiée. 2. Soit vous l'utilisez pour la confidentialité. Il faut alors demander une autorisation au SCSSI. SCSSI 18, rue du Docteur Zamenhof 92131 ISSY-LES-MOULINEAUX Cedex Tél. : (1) 40 95 37 15 Fax. : (1) 40 95 37 01 Dans les deux cas, la demande aura pu être faite par le réalisateur ou le vendeur du logiciel. Plus de détails sont donnés dans la présentation de Bruno Malhey (également en PostScript). J'y ajoute que les critères d'acceptation ou de refus ne sont pas publics. Il semble que l'autorisation ne soit donnée qu'aux institutions "sérieuses" (banques, ...) et à condition de ne pas utiliser de logiciels trop efficaces. En effet, il s'agit de conserver la possibilité pour la police de suivre les échanges. On notera que la plupart des pays comparables à la France autorisent le chiffrement, comme le montre l' excellente enquête de Sylvain André (vous pouvez voir aussi l'étude du gouvernement américain). Le logiciel de chiffrement le plus connu est PGP (Pretty Good Privacy). Gratuit, assez simple à utiliser, très efficace, bien documenté, tournant sur de nombreuses plate-formes (Unix, MS-DOS, Macintosh), c'est un excellent outil pour l'utilisateur. Il semble que son autorisation en France soit hors de question. Notez que, si vous voulez utiliser PGP en France, vous avez deux obstacles successifs : 1. PGP est interdit d'exportation par les Etats-Unis. Il faut donc récupérer une des (nombreuses) versions sur un serveur non-américain. 2. Le chiffrement est soumis à autorisation en France. Voir ci-dessus. Certaines personnes trouvent qu'un autre obstacle à l'utilisation de PGP est la difficulté d'utilisation. Celles-ci peuvent lire le remarquable livre de Garfinkel : Simson Garfinkel PGP ; Pretty Good Privacy O'Reilly & associates ISBN 1-56592-098-8 Et il existe d'autres présentations de PGP comme celle d'Ollivier Robert (fichiers PostScript PGP.*.ps), qui existe aussi sous forme d'un serveur Web. PGP protège des fichiers, soit lors de leur transmission sur le réseau (par courrier électronique ou autre méthode), soit en local. D'autres logiciels protègent, par exemple les connexions à distance ou le système de fenêtrage X ( SSH assure ces deux fonctions). Visitez le service Web "International Cryptography Pages" pour avoir tous les renseignements possibles, notamment sur les logiciels disponibles en dehors des Etats-Unis. Enfin, après ces informations purement factuelles, voilà mon opinion. Voir aussi * L'Electronic Frontier Foundation qui lutte pour les droits du citoyen dans le monde informatisé dispose de nombreuses informations sur le chiffrement. * Computer Professionnals for Social Responsability travaille également sur le respect de la vie privée. * Toujours en français, mais conçernant plus spécifiquement le Québec. Page faite par Stéphane Bortzmeyer sur le serveur du CNAM. Dernière mise à jour le 4 août 1995.

1 0

Smart Cards, Credit cards, Payment systems
by anonymous＠freezone.remailer 17 Dec '03

17 Dec '03

URL: http://www.dice.ucl.ac.be/~dhem/card.html Smart Cards, Credit cards, Payment systems. This page is under development. _________________________________________________________________ Card Europe DigiCash MasterCard Futur 1 , 2 Virtual Open Network Environment (V-ONE) MONDEX AT&T and GiroVend agree to promote smart card applications AT&T Universal Card Services ATT buyinfo ibd.ar.com/lists/comp/cypherpunks Discussions, mailing lists, and sites , Payment mechanisms designed for the Internet News items on information technology (Not especially Smart Cards) Electronic Cash, Tokens and Payments in the National Information Infrastructure Forum On Risks To The Public In Computers And Related Systems (ACM) The Risks Digest Volume 4: Issue 32 The Risks Digest Volume 15 The Risks Digest Volume 16 SMI Finger Check -- Fingerprint Verifier DIGITAL SRC Research Reports Authentication and Delegation with Smart-cards Innovonics QC consultancy University of Wollongong: Centre for Computer Security Research SecureWare, Inc. OKI Telecom (Smart) Cards Museum (big) Buying Prepaid Calling Card S. Brands Cyberbank '95 Electronic benefits transfer (EBT) in US NCSA/DTIC Security Seminar Power Broker First Union Corp. will offer stored-payment ''smart cards'' Network Payment Mechanisms and Digital Cash PCMCIA Cards THE PREPAID & RECHARGEABLE PHONE CARD Cardservice International _________________________________________________________________ UCL crypto group _________________________________________________________________ Last update: 11 September 1995. Send any comment to: Dhem(a)dice.ucl.ac.be (J.-F. Dhem)

1 0

Loi Log
by anonymous＠freezone.remailer 17 Dec '03

17 Dec '03

There was an uncharacteristically long delay (2+ hours) in receiving documents from the <http://www.cnam.fr/Network/Crypto/> site, including those linked to non-fr sites. Not sure if it is due to self-applied site restrictions or the other loi-logging.

1 0

Re: CYPHERPUNK considered harmful.
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 10:43 AM 9/13/95, Peter Trei wrote: > "CYPHERPUNK" considered harmful > > I would like to propose that we, the 'cypherpunks', are making a >strategic error, which will make it far more difficult to achieve the >goal we share. Discussing some goals we might share, or ought to share, is certainly not out-of-line. Indeed, this discussion has come up many times on this list, though perhaps not much in the past year. (Those C coders do seem to be having their way...:-} ). > Our error lies in our approach to encouraging the widespread use of >crypto. It is an error of hubris - overweening pride. I think many people here are doing a lot to encourage wide use of encryption, remailers, etc. They write hooks to popular mail programs, they give public talks, they fight against restrictions and regulations, and they deploy new systems. That some folks have very occasionally mentioned "Joe Sixpack" does not mean that much. in my opinion. > > We too often think of ourselves as an elite - smarter and better in >various ways to our non-cpunk neighbours. We refer to these others as >'Joe Sixpack" and other such derogatary terms. > > The problem is that in doing so we are marginalizing ourselves. > > We call ourselves 'cypherpunks'. While this is derived from the SF >term 'cyberpunk', consider the image we are creating for ourselves: > > A 'punk' is a marginalized young adult, one who rejects the norms >of his or her society, and takes delight in irking those around him with >his or her rejection. The older of us will think of James Dean in 'Rebel >Without a Cause', or Brando in 'The Wild One'. Later, you get images >such as Peter Fonda in 'Easy Rider', and more recently, Sid Vicious and >other icons of the 'punk rock' movement. While I have had some qualms about the name, on balance I think it has been good for us. After all, it's not as if _other_ groups don't already exist! In particular, the British branch of Cypherpunks disliked the name "Cypherpunks" so much that they used a different name for themselves, the "U.K. Crypto Privacy Association." It doesn't seem to exist anymore, for whatever reasons. But the name may have been a factor, at least. Similarly, there's the Libertarian Party, with similar themes to our own, the International Association of Cryptographic Research (or somesuch), and even several nascent groups like "Terra Libre" and "DigitalLiberty" which purport to have a similar focus to what we have. And of course there are _several_ groups devoted specifically to lobbying for various sorts of cyberspatial rights, laws, etc.: EFF, EPIC, CPSR, VTW, and the ACLU. All of these groups have a different focus than we have. If I were to pick one that matches Peter Trei's proposed organization, it would be the EFF. Thus, I suggest Peter and others of like mind look into helping out the EFF in its worthy causes. I mean no disrespect here to Peter's views, nor am I suggesting he leave this list. Plenty of room for support of the EFF and being on this list. I'm a member of the EFF, for example (though their computer has me as "Tim Mat" for some reason). But for some reason--draw your own conclusions--the Cypherpunks list has a membership of something like 600-800 subscribers, more if you count folks who subscribed for a while, or who read it in other places. I don't think "Terra Libre" or "DigitalLiberty" are quite as successful and visible. We fill a certain niche which is useful to have filled, a more radical facet of things. If we didn't exist, or renamed ourselves "Concerned Citizens for Cryptographic Protection," CCCP, then somebody would have to _invent_ the Cypherpunks! I addressed the issue of our name, pluses and minuses, in an early chapter of my Cyphernomicon (http://www.oberlin.edu/~brchkind/cyphernomicon/) 2.4.10. "Where did the name 'Cypherpunks' come from?" + Jude Milhon, aka St. Jude, then an editor at "Mondo 2000," was at the earliest meetings...she quipped "You guys are just a bunch of cypherpunks." The name was adopted immediately. - The 'cyberpunk' genre of science fiction often deals with issues of cyberspace and computer security ("ice"), so the link is natural. A point of confusion is that cyberpunks are popularly thought of as, well, as "punks," while many Cyberpunks are frequently libertarians and anarchists of various stripes. In my view, the two are not in conflict. - Some, however, would prefer a more staid name. The U.K. branch calls itself the "U.K. Crypto Privacy Association." <check this> However, the advantages of the name are clear. For one thing, many people are bored by staid names. For another, it gets us noticed by journalists and others. - - We are actually not very "punkish" at all. About as punkish as most of our cyberpunk cousins are, which is to say, not very. + the name - Crypto Cabal (this before the sci.crypt FAQ folks appeared, I think), Crypto Liberation Front, other names - not everybody likes the name...such is life -------- Getting back to your suggestion that "we" change the name to something more respectable. How could "we" do this, given that "we" are an effective anarchy? I can't imagine a vote on this, and the endless debates on what "we" ought to call ourselves would be a waste of time. Fortunately, there's an elegant solution: form your own group. Form your own group, your own mailing list, with a catchy name, something like "The Privacy Education Foundation," or "The American Civil Liberties Union" (whoops, taken), or "The Society for the Preservation of Cyberspatial Liberty." Then announce it on our list, and elsewhere. People will vote with their feet. If your "meme" is catching, your list will rapidly gain members. Maybe this Cypherpunks list will even atrophy away. Evolution in action. The market in action. A better approach than trying to get the name and the charter changed. --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

Oct Byte - Wayner's article heh
by Mark Hittinger 17 Dec '03

17 Dec '03

Check it out

1 0

Re: Why ecash is traceable
by Hal 17 Dec '03

17 Dec '03

Sorry, I don't have time to write much now. The missing piece in my description was the assumption that people would have to send received cash to the bank non-anonymously. However as Tim points out that can be avoided in on line systems, and in that case Alice cannot actually learn Bob's identity. However as was also pointed out the cash can at least be detected and invalidated so technically it is still traceable. The protection of the payor is still not really as strong as that of the payee. I should also mention that when we discussed this earlier Jason Solinsky suggested that transferrable cash systems also provide a means for Bob to keep his identity secret. The cash is still traceable in that the bank can recognize it when it is finally deposited, but it may have passed through many people's hands in the meantime and their identities are not known. Hal

1 0

Re: Linking = Showing = Transferring?
by Rich Salz 17 Dec '03

17 Dec '03

> I think this case is safer than the porn one, because the actual data > in this case is legal in both jurisdictions, it just must not be > transferred from jurisdiction US -> jurisdiction non-US, which it has > not been. I believe you're right, this is the key distinction which I missed. (Disregard my earlier email to you :) Thanks for the patient explanation. /r$

1 0