- cypherpunks-legacy - lists.cpunks.org

RE: Cyber 'Nannys"
by WebWarrior3＠InfoWar.Com 17 Dec '03

17 Dec '03

An anonymous person wrote, in reference to CyberSitter type 'blocking' software: "These companies are attempting to provide the services desired by their customers... They give concerned parents a sense of safety..." While I do not disagree that these companies should be able to market their products, I wholeheartedly disagree with the fact that often their customers (the adults who bought the software or subscribed to he 'service') are not allowed to have a list of what is actually blocked, and decide for themselves if they want their kids to have access to any of these sites. It would be beating a dead horse to describe, here, the potential value of some of the information that is blocked by these packages; one only has to take a look at any of the published news reports (or actually use one's sense of reason) to see that there are many web sites that contain some of the words that are automatically bloked by these 'services' that are absolutely not...smut <for lack of a better term>, hate speech, or illegal/illicitly oriented. On another, perhaps more severe (to you, Anonymous poster,) angle, they DO NOT, NOR CAN THEY provide a genuine saftey zone for the children who are to be 'protected.' They are providing a false sense of security to parents who, for one reason or another, feel that they are not able to provide their children with direction on what to, and what not to, view on the internet as well as what to do if the instance arises that something that is deemed taboo happens to pop up on their monitor when they click on the 'Chutes and Ladders' web site <for example, I don't know if there is one...trying to be safe and guess that there is not>. I am assuming that there is no latent support for the use of these packages in public libraries, so I won't go into that issue. In general, these programs are flat out crap. They purport to do something that is impossible to accomplish and they often refuse to even inform their customers what they actually ARE doing. Scott R. Brower http://www.infowar.com http://www.efflorida.org

5 11

E-cash and Interest
by Frank O. Trotter, III 17 Dec '03

17 Dec '03

Once the Ecash Mint and the account (in our case the WorldCurrency Access account - others will be different) are merged, the balance you hold in the Mint may be able to earn interest. Like an individual, the amount of interest offered will involve a cost benefit relationship based on cost of funds, regulation, and operational costs, but there should be no obvious reason not to pay something in most curencies. One note, under US banking regulation, "transaction accounts" fall under different rules than money market accounts, savings accounts, and NOW accounts. Depending on the exact functionality desired, and future regulation changes, there will be more or less incentive and/or legal ability to pay interest. Given the current functionality of Ecash there will be little incentive to hold balances on your hard drive once interest is available. It is just too easy to move the money down when you need it. Today there is no specific cost incentive between the Mint and your hard drive. It does not take a long leap to see that when the account and the Mint are merged, that since the Mint _is_ the account, PC/Internet banking, debit and all other regular banking functionality can become immediately integrated! Frank Trotter ftrotter(a)marktwain.com Opinions expressed are my own.... > On Wed, 10 Jan 1996, Tim Philp wrote: > > > With the E-cash systems that I have seen, you generate your own E-cash > > and have it signed by a 'bank' At that moment, it becomes like cash in > > your wallet and you loose interest that this money could be earning. > > >From the standpoint of monetary economics, this is correct. The (ecash) > bank has the right to use your deposits to give out loans. When you > withdraw your money (and turn it into either cash or ecash) they (the > bank) no longer have the right to turn your deposits into loans. > Withdrawn cash/ecash can not earn interest. > > This is the problem of (e)cash: if you have it on hand you _must_ forgo > any interest earnings. Theoretically, the optimum holding of (e)cash is a > function of interest rate (the greater the interest rate, the less cash on > hand), transaction cost of making withdrawals (the easier and more > convenient the withdrawals, the less cash on hand), and the "providence > value" of cash (the more you value instant gratification, the more cash on > hand). > > Thats why ATM machines have caused us to hold less cash. We can now keep > money in the bank (letting it earn interest and letting the bank create > loans with it) and withdraw from ATM terminals only when we need it. > > ------------------------------------------------------------------------------- > Patiwat Panurach Whatever you can do, or dream you can, begin it. > eMAIL: pati(a)ipied.tu.ac.th Boldness has genius, power and magic in it. > m/18 junior Fac of Economics -Johann W.Von Goethe > -------------------------------------------------------------------------------

2 1

Reliance Limits Considered Harmful
by Jueneman＠gte.com 17 Dec '03

17 Dec '03

>Suppose I am a CA. I am worried that by issuing a certificate with a >lifespan of more than 2 milliseconds I am opening myself up to unlimited >liability if for some reason, despite my best efforts, I issue an >erroneous certificate. > >I know I can write disclaimers, but that's not reliable since courts >often ignore them, and anyway it scares off customers. > >I know I can put an expiration date on the certificate, but that's not >enough. I can accumulate a lot of exposure in a few seconds, much less >weeks. > >I know I can put a reliance limit in the X.509 ver 3 certificate, but >that's not enough. Even a $1 limit could be used many millions of times. > >Is it feasabile to say: Can only be relied on once per day/week/month? >Is this something the relying parties can reasonably be expected to monitor? > >It seems to me that this sort of a limit is essential if a CA is to feel >comfortable outside Utah.... > >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 | It's warm here. > I have been troubled from the first with the concept of a reliance limit, in particular because of the problem Prof. Froomkin cites. In the "normal" paradigm for digital signatures, neither the CA nor the relying party(ies) have any knowledge of how many times that particular certificate/key has been used. As a result, there are few if any controls that would operate to enforce the notion of a reliance limit. Even in the electronic credit card environment where there is some sort of a closed loop system (the purchases are reported back to the Issuing Bank, and presumably would be or could be known by the CA, which is probably acting as an agent of the bank), there are some substantial problems. The first problem is one of privacy. If I have a very high credit limit, I certainly don't want to advertise that fact in a public certificate. On the other hand, if I have a low limit, I don't want to advertise that either. And in any case, the reliance limit is not intended to be a "floor limit", i.e., an amount below which it is not required to contact the credit card company for authrotization. (Floor limits used to be popular, especially in Europe where the cost of telecommuncations was high. But now almost all transactions are authorized against the customer's current balance and credit limit, and if the merchant doesn't check he can be stuck with the charge if the customer doesn't pay.) I have argued (quite unsuccessfully in the credit card community) that the reliance limit can provide a useful means of limiting the subscriber's exposure (as well as the CA's) in the event of a security compromise affecting the subscriber's private key. Since there are no perfect computer security solutions available at any price, much less an affordable price, both the subscriber and the CA have to make a tradeoff between their risks and the rewards of greater convenience, etc. I tried to get around the privacy issue in the credit card environment by treating a negative reliance limit as a percentage of the customer credit limit. But no one in the credit card industry was convinced, and maybe I'm not either. The concept of a reliance limit is enshrined in the Utah Digital Signature statute (and the ABA draft Digital Signature Guidelines), where it is wrapped up with a draconian requirement that registered CAs have to put up a surety bond or irrevocable letter or credit in the amount of 30% of the aggregate of all outstanding reliance limits. This is not just an insurance policy -- a CA's corporate assets are pledged to back up the certificates issued, not withstanding the fact that the identification system we have in this country is not sufficiently reliable to warrant such representations. And surely no CA is going to hire private investigators to check out who someone claims to be with sufficient credibility as to be able to issue certificates to individuals -- at least if they intend to charge any kind of a reasonable price for the certificates. In my personal opinion, that requirement in the Utah law makes it highly unlikely that anyone will ever become a registered CA in Utah, unless the reliance limit is set to $1 and/or the expiration period to about 1 millisecond. (Maybe the Utah statute was really trying to set up a lottery, rather than a system for registering CAs. Everyone gets to play, and if you can find a person who has invalid credentials, even if issued through an innocuous clerical error (someone misspelled the street name in someone's address), you can claim you were harmed in some way, sue them big time and collect millions. That's the American way, isn't it? :-) Although X.509 v3 provides a simple mechanism to allow additional attributes, potentially including a reliance limit, to be included in the certificate, there are at present no plans that I know of for any existing CA to actually do so, or more importantly, for anyone else's software to be able to read and comprehend those reliance limits or perform any checking. As a purely technical matter, the problem could be solved by requiring the relying party to validate the transaction (not just the certificate) with the CA in real time. (Checking a CRL database isn't good enough.) By providing a transaction amount, the CA could keep track of the extent of its liability, and could detect misuse. Alternatively, the subscriber could request a new certificate for each one time use. However, both of these "solutions" would require a significant extension to the current mechanisms, and also give rise to a number of privacy issues. In addition, there are other practical problems. If I am the relying party (or the CA), and the subscriber is using his digital signature to confirm an order to sell futures on the commodities market, how can I evaluate the potential risk? If the subscriber is selling futures for orange juice and a storm wipes out all of the orange trees, his losses could be unbounded. Similar situations could exist in the case of a signature on a patent claim, and creative people can probably think of many more cases. Although the notion of a reliance limit usually arises in conjunction with digital signatures, it would presumably apply to certificates used for message encryption, to set up encrypted sessions, etc., as well. This puts the CA in an even more difficult position, for now we are not talking about a (single) financial transaction. If I send an encrypted message to someone, and it turns out that the person who received it was not who he claimed be, I may in fact be greatly harmed. (If the message wasn't important, why would I have encrypted it in the first place. Suits for violation of privacy have resulted in millions of dollars in damages -- does that mean that the CA ought to provide a million dollar reliance limit? My conclusion after having thought about this a lot is that reliance limits are at best ineffective and at worst positively harmful. They are difficult or impossible to enforce in any meaningful way, they raise substantial privacy issues, and at least as codified in the Utah Act and the draft Digital Signature Guidelines they will almost surely act to dissuade any prudent business from setting up a licensed CA. Does this mean that the subscriber, relying party, and CA all have effectively unbounded liability, absent a stated reliance limit? No, I don't think so, but we may have to change our paradigm a little bit. Most people accept a driver's license as providing a degree of proof of someone's identity, but very few would consider it proof positive. Since the state-issued driver's license is the only practical means of identication available to a CA in the case of private individuals, that consitutes the weakest link in the system and is quite likely to remain so. The only other identification document I am aware of that is available to private individuals that provides substantially better identification than a driver's license is a permit to carry a concealed weapon. Here in Massachusetts, obtaining a pistol permit requires a trip to the local police station, where you are photographed, fingerprinted, and two or more affidavits concerning your character are reviewed prior to submitting your fingerprints and picture to the FBI, where a search of the NCIC database is used to determine if you have any prior arrests, etc. The permit card that is issued carries your residence or business address, your picture, fingerprint, date and place of birth, height, weight, complexion, hair color, eye color, and occupation. Since the Brady Bill was passed, I believe that many states have set up similar systems. (Of course many jurisdictions sharply limit who can actually receive a weapons permit. I'm only describing the process, not debating the reasonableness or unreasonableness of gun controls.) Even if state laws were amended to make this degree of identification assurance available for purposes other than weapons permits, many if not most people would have strong reservations about the privacy implications. And to the best of my knowledge, private companies are not allowed to access the NCIC, also for privacy reasons. Does all this mean that digital signatures are worthless? No, not at all. But it does mean that they are unlikely to convey a degree of surety as to someone's identity that is very much stronger than a driver's license identification. In my personal opinion, I think we need to establish a stronger degree of "no fault" protection for CAs that follow the rules. Whose rules are to be followed, and who audits them for conformance are valid issues. We clearly don't want irresponsible CAs issuing certificates to all and sundry, but we can't make the cost of entry into the business so high that no one takes on the burden of being a CA at all. The issue is how to balance risks, the costs, and the rewards equitably between the subscriber, the relying party, and the CA. In the case of the credit/debit card industry, the credit card companies charge a fee that covers both the risk and their administrative costs. If digital signatures can be used to reduce their risks, presumably the fees charged to the merchants can be reduced somewhat. But in any case, the fee that is charged is proportional to the amount of the transaction, and therefore statistically covers the risk. The real question is what to do outside of the credit card industry, where certificates may be used for transactions are much more complex, and where there may not be the infrastructure to collect a percentage fee for each use. Please copy me directly on any replies, as (to the best of my knowledge) I am not a subscriber to cypherpunks. Bob ---------------------------- Robert R. Jueneman GTE Laboratories 1-617-466-2820 "The opinions expressed are my own, and may or may not reflect the official position of GTE, if any."

1 0

Re: Theory Question: Why isn't RSA a 0-knowledge Proof
by Joseph M. Reagle Jr. 17 Dec '03

17 Dec '03

At 06:01 PM 1/13/96 -0500, you wrote: > >Zero knowledge means that the recipient obtains no information that they could >not have obtained without knowing the secret information corresponding to the >key. > >If I authenticate myself to you by giving a signature on a nonce you chose you >have obtained information that you could not have obtained otherwise. Seems right enough. Still pondering though... [1] If I (the signer) choose the series of messages to sign, this still demonstrates that I have a secret without telling you the secret (and without giving you the information you might have been fishing for..) You do get information you would not have been able to create otherwise,(whatever it is I choose to sign) ...but it doesn't matter if you wanted the information or not, what matters is that you got it??? You could get random information (entropy) as part of a protocol, would this destroy the 0-knowledge aspect as well (and make it merely a min-disclosure proof...?)) (if you aren't directly challanging me, there could be a replay or man in the middle attack or whatnot, but the man in the middle attack also applies to 0KP.) What I was thinking of, was a hamiltonian cycle example: [2]where the person that wants to see the proof is getting information regarding the iso-morphism between the various graphs... (For instance, say G is the real graph, Alice knows the path, and Bob wants proof that Alice knows it...) So in the first instance Alice produces H1 and shows it to Bob and proves it is iso-morphic, in the second example she produces H2 and shows the cycle, in the third instance, she provides H3 and it's isomorphism to G... Bob can then conclude that H1 and H2 are isomorphic... I'm not sure about this (this must be where I am in error) but I don't think Bob could have derived the fact easily (if it is plausible for him to believe H1~=H2 based on this protocol) that H1 and H2 are isomorphic without Alice's help here... So in this case, Bob picked up some info he would have not otherwise known for free (similar to the first example) even though this information isn't of any use to him with regard to the solution to G. >If it wasn't for the fact that it is IAP and you apear to be a grad student I >might wonder about somone doing their course assignments via the net... :-) The effect of the eggnaugh hasn't worn off and trying to vamp up... <smile> _______________________ Regards, Is this true or only clever? -Augustine Birrell Joseph Reagle http://farnsworth.mit.edu/~reagle/home.html reagle(a)mit.edu 0C 69 D4 E8 F2 70 24 33 B4 5E 5E EC 35 E6 FB 88

1 0

Re: What's the latest in factoring?
by Alan Tu 17 Dec '03

17 Dec '03

Dear Bill, Sorry, but you may see this message twice. Bill Stewart wrote: >>>>> There are two countervailing arguments about very long keys; one is that if you understand cryptography well enough to evaluate the issue, you'll know you don't need to bother, but the other is that if you don't understand crypto very well, maybe you should be overly conservative. <<<<< Well, personally, I guess by your def I'm in the second group, since I didn't know I don't need to bother. >>>>> Remember that factoring difficulty is roughly exponential; adding logn bits about doubles the cracking workload (depending on which factoring method is being used). Factoring a 1024-bit number is _much_ harder than factoring a 512-bit number, and factoring a 2048-bit number is well into age-of-the-universe difficulty level. The practical level of factoring right now is about 512 bits, for either a distributed internet effort or an NSA internal one; <<<<< I kind of knew this from a hypothesis, so PGP 5.x is being conservative, possibly overly so by your definition. I've seen a screen on a friend's computer and the default is something like 2048. By the way, we don't know about NSA. They may be able to factor any number, if they have an algorithm. >>>>> in the unlikely event that Moore's law lets us double processing power 100 times in the next 150 years, that means a 1500-bit key could be crackable. So 2048 bits is certainly more than enough for _your_ lifetime. Increasing processing power 2**100 times is likely to be tough :-) After all, features in current microprocessors are on the order of 100 atoms wide. And by the time we've developed the level of nanotechnology needed to speed up processing that much, there'll be tiny audio bugs listening to you type your passphrase into your keyboard and reporting it back to the Central Intelligence Corporation, or picking up the electromagnetic fields from your direct neural interface, so the crypto strength won't matter much. <<<<< I believe in Moore's law, since in 1992-1993 I read an analysis that Moore's law was true for the last 100 years. I think its still true today. Your last set of thoughts is chilling, isn't it? But consider this. People 10, 20, 30 years ago like us are saying that the government can eavesdrop on their communication in the future, just as you are saying now. Look now. I am very proud that I am part of the e-crypto revolution (my coined word). I am helping to slow down NSA. I hope that, by the time the tech you hypothesize about is here, we again will have technology to slow down NSA. >>>>> But do you really _need_ to factor the prime number to crack PGP? No. Remember that PGP uses the RSA key to encrypt session keys for IDEA, or for signing MD5 hashes of documents, rather than using it directly. So you can decrypt the message by cracking IDEA, or forge a message by finding MD5 collisions. Cracking IDEA's 128-bit keys was estimated to be about as hard as factoring a 3100-bit number, though improvements to factoring technology may make a 4096-bit number as easy as IDEA. Also, PGP 2.x passphrases are encrypted with IDEA, so if they've got your secring.pgp and can crack 4096-bit keys, you're toast, <<<<< I know this. The point is that most if not all people know that RSA is the weak link, not IDEA. Would you rather start to work on a 1024-bit RSA key or IDEA passphrase of an enemy? Obviously the RSA key. Barring any mathematical weakness in IDEA, I am not worried about IDEA. By the way, my three-year-old info says that IDEA was being mathematicly attacked in many quarters, civilian and non-civilian alike. If they was anything, I would have heard by now, but I still want to ask. Has any significant cryptanalysis attack against IDEA been "successful"? >>>>> even if your passphase isn't just your dog's name spelled backwards. Similarly, by the time processing power doubles 100 times making your 1500-bit key insecure, MD5 will be long toasted. Either way, there's no need to go beyond 4096-bit keys ever, with old-style PGP. Even if you're being overly conservative, that's more than enough. <<<<< You seem to be suggesting that MD5 will lead to the downfall of all of our keys. Let's think about your toasting of MD5. The worst thing that can happen to a one-way hash function is that it can go both ways. So its dead for signatures. So let's suppose now that I can take any document and produce another document with a higher or lower dollar figure in it and come up with the same hash. I can do this easily. But to somehow exploit MD5 to crack a passphrase it is impossible because you have nothing to start working with. You only have an encrypted key, encrypted with an 128-bit IDEA key. Look, for our lifetimes, I don't see much point in going beyond 4096 bits either, maybe even 3072. >>>>> Newer versions of PGP dump RSA and IDEA for patent reasons, but they also offer alternatives to IDEA and MD5 which may be stronger. (SHA-1 is stronger than MD5, triple-DES requires immense amounts of storage to reduce it to a strength similar to IDEA, and just being extensible means you can replace algorithms that are obsolete.) <<<<< Triple-DES is not stronger than IDEA, although it is secure for the most part. According to Phil Zimmerman, its effective key length is 112 bits to 128 bits for IDEA. Its also 3 times slower than DES, which is comparably slow anyway. Also, to settle this issue once and for all in my mind, the Win95 version of PGP, what symetric algorithms do you have to choose from? Does anyone have any comments on the relative strength of Blowfish? What about the mathematics of Blowfish? Has anyone tried to cryptanalyze it yet? Also, I apologize for going on like this, I'll post a separate question on that. >>>>> The other side of practical is how much work it takes to use long keys, and how many people who want to talk to you use them. The answer to the latter is "Not many" for RSA keys over 2048. The former is about N**2 for decryption and N**3 for key generation, and about linear for encryption with short exponents, so it'll take you 64 times as long (once) to generate the key, and 16 times as long to decrypt or sign anything, compared to the far-more-than-strong-enough 2048-bit key, which is already 4 times as hard to use and 8 times as hard to generate as a 1024. <<<<< As I said, I have a 2048-bit key in hibernation. I haven't posted it to a key server, but a friend who recently got PGP decided to use my public key ring, and use my 2048-bit key. There are only two places in which this key of mine is accessible. Anyway, I don't see the 4 time slowdown for using my secret key. (I have a 133 MHz). However, the effect is probably true for slower processors. I agree that we shouldn't bother with keys above 4096 bits because its not necessary and it takes too long to communicate with people who have slower processors. >>>>> It's not worth the bother, unless you know have a really, really special application that needs to remain secret until long after you've overthrown the government. On the other hand, at least the RSA patent will have expired by then :-) <<<<< I already addressed this point. >>>>> The Diffie-Hellman implementations in PGP 5.x will let you use key lengths up to 4096, but the speed behaviour is a bit different. In particular, key generation is much faster, so generating overkill-length keys isn't as boring. <<<<< First of all, Win95 (not my computer) seems slow to me, even if that person's processor is faster than mine. And I hear so much disk reading or writing, no wonder its slow. Boring? Win95 cannot make you bored. Go do something else, or play a MIDI file. You can multi-task. --Alan

1 0

Algorithms used in PGP 5.x; Relative strength of Blowfish
by Alan Tu 17 Dec '03

17 Dec '03

What are the algorithms used in PGP 5.x, symetric ones, that is? For anything besides 3DES and IDEA, what are their relative strengths to 3DES or IDEA? Could someone tell me what their key lengths are? Also, what's the relative strength of Blowfish to 3DES or IDEA? Its key length is variable, as I recall. Could someone tell me the range? --Alan

2 1

Cryptology and classification
by nobody＠tjava.com 17 Dec '03

17 Dec '03

Hi all, Just received a memo, the "Desk Reference Guide" to Executive Order 12958. This memo/executive order discusses classified national security information. The cypherpunks-interesting aspect of this memo lies in exceptions to some new guidelines. Basically, this executive order removes the authority for the government to "permanently" classify information. Basically, classification is now limited to 10 years (or 25 years in some special cases). The exceptions to this allow classification for longer durations for certain types of material. These types include things like protecting intelligence sources and nuclear weapons design info. One of the other exeptions is for: "...information that would impair United States cryptologic systems or activities." This appears to be taken directly from the executive order, so these types of decisions are being made at high levels. Thought you might be interested. Hooker

1 0

Mitnick Road Show
by Andrew Barrett/CheckFree Corporation 17 Dec '03

17 Dec '03

Andy P. wrote: >Saw the Stanford seimnar given by Tsutomu Shimomura and John Markoff, >on the subject of Tsutomu's pursuit of Kevin Mitnick. Saw a teaser last night for Friday's broadcast of the Stone and Pauly show. Looks like they're doing a piece on Mitnick. They did not mention him by name, but used some of the epitaphs commonly associated with Mitnick since Markoff's Cyberpunk. Which makes sense, since most of the viewing public doesn't know Kevin Mitnick from Steve Jobs. I just hope this piece is better than the infamous Unsolved Mysteries treatments. I am not holding my breath.

1 0

Cybersloth
by John Young 17 Dec '03

17 Dec '03

Shimomura and Markoff give an illuminating account of tracking system break-ins; it is in those that Tsutomu and his road crew really dazzle. Skip the filmic crud and enjoy the gritty details of hackers hacking, stretching legality and propriety, emulating their mocking nemeses. Glimpse the far-side hackers, say, jsz and jft and xxx, still taunting, eluding, taking down, making pay for job- security cybersloths.

1 0

AP story on PGP
by anon-remailer＠utopia.hacktic.nl 17 Dec '03

17 Dec '03

U.S. Attorney Won't Prosecute Author of Computer Encryption Program By ELIZABETH WEISE= AP Cyberspace Writer= SAN FRANCISCO (AP) - A software writer won't be prosecuted for a program he wrote that was put on the Internet and is now widely used by computer users to keep their communications secret, the government said Thursday. Philip Zimmermann's Pretty Good Privacy encryption program turns computer messages into a jumble of numbers and letters unreadable to anyone except the intended recipient. The code is so unbreakable that it is classified as munitions under the Arms Export Control Act, making its export without a license a felony. Federal prosecutors began investigating Zimmerman in 1993 after the program appeared on the Internet global computer network. Zimmerman said that others put it there, not him. The government opposes export of cryptographic technology for fear it will make it harder to monitor electronic communications overseas, and domestic law enforcement agencies are concerned such programs could keep them from eavesdropping on digital conversations. U.S. Attorney Michael J. Yamaguchi announced the decision not to prosecute Zimmerman, but didn't say why. If convicted, Zimmermann would have faced 51 months in prison. ``I'm just really pleased that the sword of Damocles is not over me anymore and I wonder why it took so long,'' Zimmermann said in a phone interview from his home in Boulder, Colorado. ``This is not just for spies anymore. It's for the rest of us. The information age is here. The rest of us need cryptography to conduct our business.'' The case had been closely watched as computer users and the government square off over free speech and privacy rights. Some critics contended it was foolish of the government to claim that Zimmerman had broken the law because the same coding information forbidden for export electronically may be shipped abroad in print form. They also noted that the technology already circulates throughout the world, making the law unenforceable. ``Zimmermann never exported Pretty Good Privacy, so the U.S. Attorney seemed to be missing the point. Unfortunately there still is no clear ruling from our government as to whether or not making software available on the Internet counts as exporting it,'' said Simson Garfinkel, who wrote a book about the program. Zimmerman's supporters argued that without encryption, government could do widespread eavesdropping, perhaps for political reasons, scanning for words and phrases it considers subversive. They acknowledge that a few criminals may use programs like PGP to hide out in cyberspace, but believe that concern is outweighed by free speech and privacy rights. ``The case was part of the government effort to crack down on good technologies for privacy. We hope the government's decision signals a rethinking of federal policy in this very important area,'' said Marc Rotenberg of the Electronic Privacy Information Center in Washington, an on-line civil rights watchdog group. Others see the 2.5-year investigation of Zimmermann as intimidation. ``It seems to me is that all the U.S. Attorney is saying is that they don't want the public relations nightmare of prosecuting Philip Zimmermann, but they still want everyone scared so that they won't exercise their Constitutional rights,'' Garfinkel said. --- Pretty Good Privacy is available on the World Wide Web at http://www.epic.org/privacy/tools.html

1 0