December 2003 - cypherpunks-legacy

free market (was RE: GET OFF THE DIME: PGP 5.5)
by rishab＠dxm.org 17 Dec '03

17 Dec '03

Attila wrote: would you rather have PGP, Inc. with its preeminent stature in the defense of freedom, freeware, and privacy as well as an established, TRUSTED product defining THE system which meets the need of the [etc] if i remember right, the idea behind PGP when it first came out was that you ought not trust ANYBODY. that's why you have the source code@! it's a free market. if PGP Inc wants to make money, and needs to meet the corporate demand for some sort of alternative-key mechanism to snoop on their employees (or keep backups of important correspondence when employees forget their keys) so be it. as an individual, it hardly matters to me if it's PGP or Microsoft that's selling this stuff - remember, crypto software doesn't read your mail, people do, and if my company wants to be able to read my mail it'll buy the tools from anyone who's selling. frankly i couldn't be bothered if the tools are from "TRUSTED" PGP or Evil Bill. for all i know, my employer is quite happy with GAK too. of course if i'm willing and able to work independently of any company, then i _do_ have control over the privacy software i use, and in that case, if i'm paranoid enough, i can always go through the source code. -rishab

1 0

InfoWar Epilogue 2 / TEXT
by TruthMonger 17 Dec '03

17 Dec '03

---------------------------------------------------------------------------- ---------------------------------------------------------------------------- The True Story of the InterNet Part III InfoWar Final Frontier of the Digital Revolution Behind the ElectroMagnetic Curtain by TruthMonger <tm(a)dev.null> Copyright 1997 Pearl Publishing ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- InfoWar Table of Contents * Epilogue * Jonathan ---------------------------------------------------------------------------- Epilogue ---------------------------------------------------------------------------- The tattered remnants of the Magic Circle sat quietly in front of the lines drawn in the dirt of the floor of the cave. Alexis placed a white rock in one of the squares. Jonathan placed a black rock next to it. They were engaged in the use of one of the first computers used to wage InfoWaran ancient oriental game, called 'Go.' Fortunes and kingdoms were won and lost over the placement and arrangement of black and white stones. Like 0 and 1, on and off, yin and yang. Cowboy was thinking of an article he had pulled up from the past, titled, "The History of Chess," or some such, from a magazine called 'Playboy.' It described chess as originating in primitive times, with a board having only one square on it. Each player had one playing piece, and you could put your piece on the square, as long as you were willing to back it up with your fists. He thought about the battle for control of the InterNet that was taking place a century in the past. The more things change ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- Jonathan "I've looked at life from both sides now, From win and lose, and still, somehow, It's life's illusions I recall I really don't know lifeat all. - Joni Mitchell During the censorship crisis on the CypherPunks list, when the list members were trying to make sense of what was going down, a lone voice whispering in the wilderness pointed out that the battle being waged had little to do with censorship, and everything to do with InfoWar. The Tao whispers so that it will be heard by those who do not have all of their attention tied up in shouting. The Tao whispered during the censorship crisis, just as it had whispered in the madness that overtook Germany, then Europe, then the World. It was heard by the Hermit, and echoed by the Fool. It whispered "InfoWar." But it seemed that no one had heard ---------------------------------------------------------------------------- The Process of human alchemy marches on: Revelation of the Method. They are Making Manifest All that is Hidden and what a hell-fire joke it is--for almost no one is paying conscious attention, even as the secrets of the time are dropped like pearls before wine. -Michael A. Hoffman II ---------------------------------------------------------------------------- at least, until history took a step back, and a step to the left. ---------------------------------------------------------------------------- The whole goal of the hijacking of the phrase "key escrow" to camouflage GAK was to obscure the difference between voluntary and involuntary participation. Someone getting access to your secrets against your will, whether by trickery, threat of force, or burglary is not escrow. At least, not until the USG deliberately chose to abuse that word to throw a mask of legitimacy upon its rotten idea of mandatory wiretapping for all digital communication. Damn, but it is frustrating to see such a bare-faced NewSpeak gambit succeed so brilliantly against otherwise literate people. Everyone should read George Orwell's paper on (ab)use of language in politics. None of the examples he cites are nearly as worthy of Minitru as is this single conceptual hijacking. -Zooko Journeyman ---------------------------------------------------------------------------- At the time that the Trei Transponder exploded, PGP, the holy icon of the CypherPunks, was under a full-scale frontal attack bythe CypherPunks. The reasonCorporate Message Recovery. Just as the assault by the Dark Forces on PRZ and PGP had alerted the Magic Circle to a soft spot on the underbelly of Gomez and his Dark Allies, the assault on CMR and PGP by the CypherPunks alerted the Dark Forces that they had been premature in celebrating their InfoWar victory in their assault on the CypherPunks list. About a century too early ---------------------------------------------------------------------------- I presume the PGP PR person (who ought to get the sack in my opinion) thought that a sudden press release of such marvelous new feature as PGP SnoopWare and a SnoopWare Enforcer for Third-parties would go down well. It doesn't. -Adam Back ---------------------------------------------------------------------------- Although PGP's 'Corporate Message Recovery' software had its proponents and detractors on the CypherPunks list, the bottom line was that it marked a change in the battle front in the Crypto Wars. Even Philip R. Zimmerman, himself, was not happy with the PGP name being lent to a product which amounted to an expansion of the definition of privacy to include Little Brother as the 'owner' of everyone's privacy within a company, and thus, by future extension of the concept, Big Brother as the 'owner' of everyone's privacy within a nation (and eventually, within the New World Order). After a short period of CypherPissing about the few pros and many cons of this new direction in the encryption battle front, the CypherPunk aphorism, "The answer to noise, is more noise." began to take hold, with Tim May broaching the possibilities that "forward secrecy systems" might hold for empowering the individual caught deep within the bowels of the Great Machine. Wittingly, or unwittingly, the CypherPunk Philosopher King sidestepped the Ministry of Truth's new definition of privacy by counter-attacking with a subtle, but important redefinition of email, by using a seemingly innocent reference to "conventional e-mail" in his post exploring the possibility of simply 'routing around' the 'damage' (an old CypherPunk tradition). Perhaps the answer to 'InfoWar,' is 'more InfoWar.' ---------------------------------------------------------------------------- Gomez stared at the mountain of references that his Dark Allies and their human minions had gleaned from email, news groups, mailing lists and web sites from around the InterNet-references to troubling new trends and technologies that foreshadowed a threat to the future that had been preordained by the Evil One. PHil's Unified Corporate Key-Yardstick of Outbound Uniformity. No details, but the reference to Zimmermann was obvious. Had he just begun to explore new developments in the Corporate Key technology that had been slipped into the mix of his original concept behind PGP, or did he already have methodologies in place to defend against the misuse of Corporate Message Recovery? SAK - Saboteur Access to Keys This had the Mark of the Toad written all over it. Throughout the Corporate Message Recovery system, identical corporate keys began showing up on different systems. All indications were that people inside the corporations had access to a method of slipping in the Saboteur Key in a way which its footprint mirrored that of the original key. Destination Escrow This seemed to be the most dangerous of all the quickly emerging 'unconventional email' technologies. It had all the marks of a collaborative effort between the CypherPunks, the Circle of Eunuch, Alt2600, MI9, COM-12, and a host of other freeh-dumb fighters. Remailers, Eternity Servers, Crowds, DevNull Addressing, Inner Onion Routing-all seemed to play some part in this diverse, but highly effective methodology of disguising the true routing and final destinations of email and other communications. Some of the DE technologies seemed to be escrowed internally, catching the email after it had been processed by the email system, and before it had been sent to its destination, either changing the destination, or mirroring the message to other destinations, as well. Some seemed to have the secret code for their true destination escrowed at some point in the InterNet routing system itself, outside the watching eyes of internal system security personnel. Distributed Key Escrow The Dark Allies were not certain what DKE technology actually referred to, but it was suspected that many communications contained plain-text stego which was protected by use of a distributed encryption and decryption key which could not be compromised except by accessing the systems of all who held a part of the key. Unlike the public-private key technology, it seemed to be highly resistant to attack by gaining control of systems and routers, or any form of Man-in-the-Middle attacks. It was suspected that they were combined with the use of a new type of distributed remailer, as well, but this had been impossible to confirm, as of yet. Gomez frownedit looked like InfoWar was going to be a battle, after all. ---------------------------------------------------------------------------- One thing that the Magic Circle knows from our long battle with Gomez was that he is, above all things, thorough. There is no doubt in our minds that the Dark Allies, upon searching the rubble of our last safe house, will find the small platinum plaque which will provide not only a verification of the presence of the Circle of Eunuchs and the CypherPunks concealed deeply within the heart of WebWorld, but also a confirmation that: "The end of our beginnings, will be to arrive from where we started, and to know it for the first time." -The Magus It will not take long for the Dark Allies to notify Gomez, both now and a century in the past, that the front of the plaque reads: Trei Transponder © Peter Trei 1997 "Those who do not learn from the future, are doomed to repeat it." And Gomez will undoubtedly understand, for the first time, the true meaning of the motto of a small computer company formed in Tucson, Arizona, a hundred years previously, when he reads, on the back of the plaque: Built by: Pearl Harbor Computers "It Ain't Over 'Till It's Over" ---------------------------------------------------------------------------- CypherPunks Write Code ---------------------------------------------------------------------------- "The Xenix Chainsaw Massacre" "WebWorld & the Mythical Circle of Eunuchs" "InfoWar (Part III of 'The True Story of the InterNet') Soviet Union Sickle of Eunuchs Secret WebSite ----------------------------------------------------------------------------

1 0

InfoWar Epilogue 2 (Part III of 'The True Story of the InterNet')
by TruthMonger 17 Dec '03

17 Dec '03

1 0

negative security aspects of GAK compliance
by Adam Back 17 Dec '03

17 Dec '03

I think there is a clear technical security case against the GAK compliant packet, which I would like to see comments on from people who think the political GAK compliant argument is not significant. This ties in with using separate storage and communications keys, and with the better security practice of having shorter lived communications keys to provide forward secrecy from the point of issuing new communication keys (could be once per month, once per week, or once per message). Once you acknowledge that it is more secure to have short lived communication keys (which in my view it very clearly is), it should be clear that by putting a GAK compliancy packet feature, or other second recipient you are weakening the security because that is another door into a message which you are trying to make forward secret -- you are trying to ensure that after the fact, no-one, not even the recipient can decrypt the old traffic. (This is a very good way of ensuring that third parties, like industrial espionage spies, people using black mail or the Feds using rubber hoses, or supeonas or other legal or extra legal forms of coercion, can't obtain from you keys to decrypt it either, so they don't get plain text). The fact that the extra door into the message is outside the recipients control means that his own security could be compromised by sloppy practice on the part of that key holder. This argues that if people are to insist on using the enforced second recipient model for corporate snooping at all, they should for security reasons be at least using short lived communications keys for the GAK compliancy packet also. Or, as I would argue, most secure of all is not using GAK compliancy packets at all, but rather to use escrowed storage keys to retain access to mail archives. This is more secure because you don't keep second doors into what should be a communication encrypted with as few as possible (namely: one) transient communications key, with security policy control being in the hands of the person who owns the key (the recipient). As I have pointed corporate access to stored email can be acheived with similar amounts of snooping enforceability by having the PGP5.5 mail client store to an escrowed communications key after decryption, or even to re-encrypt after decryption to a long term storage company archive access bot within the LAN (with such encrypted messages themselves being wrapped in an extra comms encryption envelope using short term communications key if you like). I would be interested to see anyone refute this security argument from a security point of view. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

4 9

Auto-archiving cleartext is GAK
by Anonymous 17 Dec '03

17 Dec '03

Advocates of the model where software is automatically archived on receipt, either in cleartext or re-encrypted with a corporate key, need to be aware that there are problems with it: No notification to sender about the policy. Imagine encrypting this mail to your friend sue(a)microsoft.com: "Hey Sue - it's been a while. Is your boss still being such a wiener? That was a great imitation you did of the jerk at the party last month. He still doesn't know you're shopping your resume around, right? What a luser." You might have thought you had a certain level of privacy when you encrypted it to your friend's personal key, but you didn't. This is going to cause embarrassment and misunderstandings. People should know if their mail is going to be automatically saved in the clear to a company archive. The best way to make sure of that is to have the sender be the one to do it, or not. No way to prevent third-party access. With the corporate message recovery feature, the sender has the option of simply ignoring the recovery key and sending it encrypted just to the recipient. Some corporations won't let it through, others will. Some companies will want mail to be made recoverable by default, while still allowing an escape clause for personal mail and special purposes (like for "sensitive" mail which needs protection against subpoena and discovery). They can use the "optional" CMR mode. Again, senders are always notified as to which mode is being used by a given company, and senders can be confident that if they don't use the third-party key, no access will be possible. With automatic encryption and archival on receipt, all mail will be archived, and senders have no notice and no guarantee that stated policies will be followed. No escape via super-encryption. Even if the company is mandating a recovery key and filtering out messages which aren't encrypted to it, the sender still has the option to super-encrypt with the recipient key alone, before sending the message encrypted to the corporate recovery key. This ensures that only the recipient's personal key can read the message. With software which automatically saves the cleartext of the message, once the user reads the data it is available to the corporation via the snoopware. Facilitates GAK! Suppose this solution is adopted, and software is developed which automatically re-encrypts received email and sends it to a secure archive. It's robust and works with a wide variety of email packages. Now the government could simply mandate this to be used for all mail reading software. The secure archive would be a remote archive maintained by the FBI to protect public safety. All plaintext would be sent there, encrypted by the FBI key. The business software would already support this. This is GAKware! Unlike with a CMR system, the sender would have no way to prevent access. Can't handle forgotten passphrases. People forget passphrases all the time. With re-encryption on receipt, there is no way to recover gracefully from this error. All the incoming encrypted data is lost until you can notify everyone who has sent mail to resend it, and get your new key out to all of them. These may be purchase orders, sales leads and other important documents which represent lost business if they can't be recovered. This is going to invite people to use poor security practices like writing down passphrases or choosing ones which are easy to guess. Worse, it... Invites key escrow. In order to prevent this problem, employees may be forced to share their secret keys with corporate management. Software will be written to facilitate this process. Crypto companies are already doing this. Nortel Entrust allows key generation by management, where employees are given the keys and management keeps a copy. Shades of Clipper! This also fails the notification requirement. Don't believe me? Take a look at this description of the Nortel Entrust product: > Recovering Lost Keys > > Many data security systems require that users have passwords to access > their keys. However, with some information security systems, disaster > strikes when users forget their passwords. When users of such systems > forget their passwords, not only do they lose their keys -- they also > lose all the information encrypted with those lost keys (forever). > Entrust, however, provides an easy way to securely recover keys. > > If users forget their Entrust passwords, they call their Entrust > Administrator to request that their encryption key pairs be recovered. > After setting up the users for key recovery using Entrust/Admin, the > Entrust Administrator provides each recovered user with a new > reference number and authorization code. Users then enter this > information as part of the Recover User operation in Entrust/Client. > This operation sets up a protected communication session between > Entrust/Client and Entrust/Manager for encryption key pair recovery. > When Entrust/Client recovers a user's encryption key pair, it > automatically creates a new signing key pair. > > Updating Keys > > While users can recover their key pairs if they forget their > passwords, there are some situations in which users may want to get > new key pairs altogether. For instance, the security policy of an > organization may dictate that users get new key pairs every two years. > In this case, a Security Officer uses Entrust/Officer to specify that > key update occurs every 24 months. The term key update refers to the > automatic creation of new encryption key pairs and signing key pairs > at specified times. Any Security Officer can specify the frequency of > key updates. > > Every time users log on to Entrust, the software checks to see if key > update is required. If this is the case, Entrust/Client makes a > request to Entrust/Manager for a new encryption key pair. Once the new > encryption key pair is generated, Entrust/Manager delivers the new key > pair in a protected communications session. Delivery of the new > encryption key pair is completely transparent to the user. No system is ideal. Before pushing this re-encryption model as a panacea, think about the implications. No system which provides automatic access to business data is going to be privacy friendly. Any such system can be perverted into supporting GAK. Load it up with all the disclaimers you like, but if you advocate software which contains key escrow and which automatically provides cleartext to third parties, you are not advocating software which protects privacy. Be prepared to be called an advocate of GAK next time you push for software which automatically archives cleartext, because if it can save it for business, it can save it for government.

2 1

patenting big brother
by Ariel Glenn 17 Dec '03

17 Dec '03

if it's not one thing, it's another. Ariel Glenn ariel(a)columbia.edu ----- http://www.nytimes.com/library/cyber/week/101397patents.html Engineer Invents Computerized Surveillance System By TERESA RIORDAN Imagine that a city park were studded with discreetly placed cameras that fed images into computers programmed to keep a watchful eye. This may sound darkly Orwellian, but David Aviv, a former aerospace engineer, has patented exactly such a system as a way of combating crime. Aviv said his invention, which he calls the Public Eye, used pattern recognition to detect robberies or acts of violence. He said he had digitized and stored a library of physical interactions. "We employed actors to do re-enactments of muggings," he said. "We had 10 different sizes of muggers and 10 different sizes of victims." The camera sends to a computer the real-time images of a person getting money from an automated teller machine, for example. The computer then takes a snapshot and compares the image against the library of threatening interactions. "It takes another snapshot and then another snapshot and does a similar comparison over and over again to reduce false alarms," Aviv said. "I'm describing this in slow motion, but it actually takes place every fraction of a millisecond." If the computer detects a malicious act, an alarm promptly alerts the police or a paid guard. Aviv said he also used a type of pattern recognition, called word gisting, to detect aggressive verbal interactions. Muggers, according to Aviv's research, use a limited vocabulary. "Mostly they say, 'Give me your money,' and then use a lot of cuss words," he said. His word-gisting library contains about 20 basic words, spoken in a number of different dialects. How is Aviv's system different from having a human guard observe a bank of television monitors? "Guards get tired," Aviv said. "And they are expensive." Aviv estimated that it cost about $130,000 a year to have one site manned by guards 24 hours a day. "My system you could lease at $500 a month," he said. "You're not going to eliminate all guards, because you still need someone to run over when a hostile act is taking place." Aviv's company, ARC Inc., which is based in Las Vegas, is seeking financing for further development of the surveillance system. He received patent 5,666,157.

2 1

Re: America as a Shake Down Extortion State
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Ryan Anderson wrote: >That's the point - you ignore the legislation until it becomes a problem >for you. Then you challenge it and get a legal precedent to stop it from >happening again. > >The judicial system is in *much* better shape than the legislative system >(even though they are strongly related) > >This, however, is not to say that the judicial system is in good shape. You're ignoring the fact that the legislative and the judicial are just two different horns on the same beast. "Please impale me with the kinder, gentler horn," is what you're saying. Let's face it. This "challenge it and get a legal precedent" approach has done absolutely nothing to stop America, formerly one of the freest countries on earth, from slowly devolving into a socialist police state. That's why I say fuck the lawyers, and fuck the legislators, too. If a roomful of morons are writing up ludicrous rules and you're gullible enough to listen to them, then who's the real moron? Ignore them. Set a precedent in life. I'm suggesting active civil disobedience by every thinking person in this country. I'm not saying blow up a federal building or any other such nonsense. Be responsible for your actions, but act! And act intelligently... [ Imastun ] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNEISTnC/ZQW0eQF1AQHZ2wP9GpVnZj7M8GErkJY9aKrpU9tSgLM99AKz CdLiDDpJGTLV1w09xhEpHFJWqgBx/Uq+6GdK/ih1Osrdu5vzYHh93eTGWGU1nmYD cbxl8TQOfVw9KbG3drrHx+Azvv6QzYJrrV4e2xPkoGuEeQUByFcemR9XIpcwmg8a 9r/7hyV3dTo= =xnIk -----END PGP SIGNATURE-----

2 1

Attitude and Assumptions
by Jon Callas 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In the course of all the discussion here, I have seen a number of implicit attitudes and assumptions that irritate me. This is a short rant to air my irritation. The first thing that bugs me is what I'm calling Crypto-Correctness. I don't know a single person on cypherpunks who is against privacy, or is against the notion that in the information society, keeping and bearing crypto is an inalienable human right. Politically, I'm a Lockeian, and put privacy up there with Locke's basic trio of life, liberty, and property. As part of this, I fight the stupid notion that because there are bad people out there, rights should be abridged. Crypto is a tool, and nigh any useful tool can be misused. If we let that fact stop us from making tools, we'd be using nerf axes and dressing in bubble wrap. If we let the fact that bad guys are using our stuff bother us too much, we'd be against privacy. Here at PGP, we like to make hay out of the fact Burmese freedom fighters use PGP. A while ago, Tim May sent out something in which he stated that Hamas uses PGP, making the very valid point that one person's freedom fighters are another person's terrorists. He implied that they're not using just to tell each other where the best hummous shops are, and I don't doubt it. I like to say (now that I'm no longer an arms maker) that we are like the Red Cross in that the Red Cross gives medical attention to everyone, regardless of their moral worth; we supply privacy software to everyone, regardless of their moral worth. In the days when crypto was a munition, I used Winchester as a metaphor, complete with Sarah's cute bungalow. In its milder forms, Crypto-Correctness thinks that if a bad guy is using crypto, then it's a mitigating factor on what they're doing. I can see that it might come from not liking tack-on laws like the clause in the present bill that makes using crypto to hide a crime illegal. This is deplorable. But using crypto doesn't make something good. In some of its other forms, it pushes into what I perceive as Crypto-Socialism. We just shrug if suicide bombers or paparazzi are using crypto, but if a property-owner wants to use it, you can just hear the sharp intake of breath. If that property-owner is Big Business, there are howls of indignation. I get the impression that some people think crypto should only be produced by non-profit organizations for the use of non-profit organizations, or those that had the common decency to get their profits illegally. The next thing that bugs me is that the government has us so scared of our shadows that we look askance at anything that might make crypto mass-market. Right now, crypto is rocket science. Many of the people who need it most are only going to understand it after years of acclimatization. The sorts who inhabit the nightmares of tech-support people are going to take at least one more turn of the wheel of Maya to get it. I think a lot of people here think that blade guards on crypto in any form is stark moral evil. You lost your data? Good. Shows you're not worthy. You shouldn't have data anyway. Information is property, and property is theft. In the crypto-anarchist future, after the withering away of the state, you won't need property anyway. I suppose we'll all just eat e-cash. I really believe that this panicked, bunker-mentality fear of anything that might complicate the system with blade guards is doing the cause of freedom a sever disservice. Business people are subjected to a lot of the asinine annoyances and minor evils that government brings, too. If we get them on our side, they will be a powerful ally. I believe that the central thesis of crypto-freedom is that it doesn't matter if a document is on paper or in a text file; it doesn't matter if a conversation is on the phone or in a restaurant. The medium doesn't matter. My papers and effects have the same protection on a disk as on paper itself. We all know that deployment is the key. But real deployment means deploying to people who don't know how their toaster works, too. If we don't solve this problem, we'll get hit with the backlash. Just you wait, once crypto becomes trendy, there will be a Time cover story with some headline like, "How Much Privacy is Enough? Who's Really After You, Anyway?" and in it will be sob stories about how people lost their passphrases, were blackmailed by employees (ask me, I have real-world tales of this), or can't decrypt their backups. Congress will have hearings, and they aren't going to be fun to watch. Is trying to head this eventuality off (yes, I believe it's inevitable) really the work of Satan? The last thing that really, really bugs me is the hostility that's directed towards PGP Inc. because now we're an Inc. The core group of people who are here are the same people they always were, they're just being paid now. I'd love to be independently wealthy and do this for the crypto-anarchist, non-profit joy of it, really I would. But you know, as the great crypto-socialist Balzac said, "behind every great fortune, there is a great crime" so I suppose we must be up to no good. This is a blues riff, so let me tell you how we've paid our dues before I get to the chorus: We published our source code. One of our potential partners said and I quote, "Are you mad?" We stand firm on the issue of No Weak Crypto. A noted GAK proponent asked me at a conference, "Aren't you folks going to do an export version?" I replied, "Sure we are." This person asked, "When?" I said, "The day after the law changes." We put out a freeware product, hoping people will upgrade to the for-pay version. If you're thinking of your own startup, let me give you some investment advice: the crowd who thinks the X-files is a documentary doesn't upgrade to the for-pay version. We started an IETF working group that will take our core technology and put it out for anyone to use. They will own change control. We won't be able to use any patents or intellectual property to enhance our business position. We won't be able upgrade the protocol without a vote. The only thing we offer as a selling point is our superb engineering and our good name. The business version is funding the rest of the ball of wax. Are you afraid we'll make a deal with the devil? I have two comments on that: (1) I work in Silicon Valley. I tell headhunters, "no thank you" every week. I took a pay cut to come here. I can get a 20% raise by going to WebFoo any time I want. My options aren't worth what I would have gotten as a layoff package had I stayed at Apple. If I send out an email message that provides "technical support" to furriners, I could land in jail. I'm here because I care. Ask the people here who left behind Cisco options at 40 if they care. (2) There's one surefire way to make sure we don't make any deals with the devil. Buy the product. Encourage your friends, your mother to buy the product. If you see someone who is using the freeware version, send them a polite message to buy the product. Buy one and send it to your congresscritter. If you don't, what you're saying is, "crypto-freedom is very important to me, as long as I don't have to spend $49 on it." Convince your employer that $119 isn't too much to pay for meta-introducers. Make the crypto market so hot that someone competes with us by being badder than us. Oh, yeah, baby, I got them crypto-startup blues. Jon - ----- Jon Callas jon(a)pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) -----BEGIN PGP SIGNATURE----- Version: PGP for Business Security 5.5 iQA/AwUBND7PCH35wubxKSepEQKD9QCgwPoRbXSHyueb9U4fLztaQkAKLlQAoNdC kX1gOsFsBZ6YDtC9AX5X/VU9 =IiAC -----END PGP SIGNATURE-----

6 5

Key Lookup Optimizations (Was: Re: D-H Forward Secrecy for E-Mail?)
by William H. Geiger III 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In <199710131652.RAA02526(a)server.test.net>, on 10/13/97 at 05, Adam Back <aba(a)dcs.ex.ac.uk> said: >> >I also personally prefer people to send me keys in email, because the pay >> >per second phone lines here at home mean that I tend want to avoid doing >> >too many online key lookups, so I think this would be an individually >> >useful feature. >> >> I do my keylookups automatically durning the msg filtering process which >> is done in parallel to the message Dl's. >A clever optimisation to be sure. >> The outbound message lookups are a little more time consuming but is >> compensated by fewer keys to look for both because fewer messages on >> the outbound side and the use of key caches on the client machine >> for the most used keys for sig verification and encryption. >I don't have a key cache, and my keyring is only 216k. But I'm curious >about your automated process .. are you also checking all signatures that >you can by downloading the keys and checking out the WoT for all received >mailing list traffic etc? This would cleary result in a much bigger key >ring. For the inbound processing of mail I have the following automated processes: - -- Messages is downloaded and checked to see if it is a PGP Message (This is handled by the mailers filters). - -- If the message is signed the keyid of signature is extracted from the sig-block and a lookup is performed on the index table for both the users pubring & sig_cache. - -- If the key is not found in either then the message is placed in a queue and a keylookup thread is spawned. - -- There is a setup for which servers and how many to try when doing the lookups. - -- If no key is found on the servers then a canned e-mail message is sent to the sender requesting his keys. The message is taken out of the queue, marked that no key was found and that a request had been sent out. - -- If a key is found it is added to the key cache (sig_cache.pgp). Then normal sig verification is performed. - -- After X amount of hits on a key in the cache the key is flagged as a commonly used key for the user so he can pursue authenticating the key (no sense in going through a lengthy authentication procedure for a key that is only used once). - -- Attached keys are detached from messages and stored in new.pgp keyring (auto adding of keys to ones keyring is a Badthing (TM) ). - -- Encrypted messages are decrypted. All PGP output is appended to the bottom of the message so the info is there when the user opens the message. If a message is in MIME format then the below is appended as MIME attachments using text/X-PGPCheck MIME type. A sample is provided below: - -------------------------------------------------------------------- MR/2 PGP Signature Check 13 Oct 1997 12:19:55 - -------------------------------------------------------------------- File has signature. Public key is required to check signature. Key matching expected Key ID 142DD151 not found in file 'd:\pgp\pgp263a\pubring.pgp'. WARNING: Can't find the right public key-- can't check signature integrity. Plaintext filename: WHGIII\34425839 - -------------------------------------------------------------------- MR/2 PGP Signature Check [Secondary Keyring] 13 Oct 1997 12:19:55 - -------------------------------------------------------------------- File has signature. Public key is required to check signature. . WARNING: Bad signature, doesn't match file contents! Bad signature from user "Ian Brown <Ian.Brown(a)ncl.ac.uk>". Signature made 1997/10/13 15:15 GMT using 1024-bit key, key ID 142DD151 WARNING: Because this public key is not certified with a trusted signature, it is not known with high confidence that this public key actually belongs to: "Ian Brown <Ian.Brown(a)ncl.ac.uk>". Plaintext filename: WHGIII\34425839 PGPRC=1 PGPRC2=1 >> Also logging of e-mail addresses that do not use PGP cuts down on >> the number of lookups needed >Good optimisation. It sounds really as if your OS/2 setup is more >advanced than a lot of other stuff around. - -- For the outbound messages the following procedures are in place: - -- All messages are signed with the user having an option of disabling this signature either on a per message basis (through the use of a message template at creation time) or default conditions can be set in the filter no to call the signing script (things like don't sign messages to majordomo, or messages going to remailers, ...ect) - -- Outbound messages can be flagged for encryption on a per message basis (through the use of a message template at creation time) or default conditions can be set in a special default.ndx file used by the encryption script. - -- The encryption script first extracts all the e-mail addresses from the To:, Cc:, & Bcc: lines. - -- It then does a lookup on the default.ndx table. This is where several issues are resolved. 1) No key for address. An address can be flagged as a no-encrypt address. This is mostly for mailing lists and receivers that do not use PGP. 2) Default key for address. An address can be flagged as encrypt and the keyid for that address is included in the entry for that address. This handles things like userid does not match the e-mail address for the person you are sending to (change of address, ect...). Also the issue of multiple keys having the same e-mail address are handled (their can be 5 keys all with the address john_doe(a)domain.com in the userid fields but only one is the real john_doe(a)domain.com that you are talking to). 3) Always encrypt flag. You can flag an address to alway encrypt too regardless of wether the message was flagged for encryption at creation time. (hmmmm starting to get into the realm of policy enforcement here <g>). - -- Unless an address is flagged as no-encrypt then a lookup on the keyring indexes for both the pubring and crypt_cache are performed. - -- If and address is not found then a keyring lookup is performed. A separate cache is kept for the encrypted keys and a similar process of flagging frequently used keys is in place as with the sig_cache. - -- now that all the addresses are processed 3 copies of the message are created: 1) Encrypted message. This message is sent to all the addresses where valid keys have been found. 2) Plain Text message. This message is sent to all addresses where they have been flagged no-encrypt in the default.ndx. 3) Error message. This message is returned to the message editor and the user is informed why the message could not be encrypted and then it is up to him to resolve the problem. Most common errors are no key found for the address and multiple keys with the same address found. Both these conditioned can be resolved by making the proper entries in the default.ndx file. 3A) There is a setting flag that tells the script not to split the message as above and error the complete message unless all addresses can be encrypted to. 3B) their is an exception option on 3A where a split message is not in error if the only addresses with no_keys are flagged as public distribution (mailing list, newsgroups, ...ect). 4) BCC messages. Bcc's create a unique problem to the encrypt to multiple recipients function. Because of the format of the encryption block the list of keys used to encrypt is known to all who care to look. This goes against the purpose of a BCC which is to hide a recipient from the rest. In this case I create a separate message for each BCC and encrypt that message with only the key for the BCC recipient. 5) All split messages contain a X-Distribution list containing all the e-mail addresses that the messages was sent to (minus the BCC's of course). I have allot more goodies implemented and/or working on but that should be enough for one message (direct keyring manipulation, remailer support, stamper support, PGP/MIME, balanced b-tree as keyring, ...ect). Much of the optimization work I have been doing is for server side processing useing very large keyrings (+20Mb) but that is another thread in itself. Plus I have a PGP GUI which has many other features for key management & WOT not practical for the automated processing code. >My setup is GNU emacs with Pat LoPresti's mailcrypt.el PGP and remailer >support lisp extension for emacs RMAIL and emacs GNUS (newsreader). I >love it to bits. It is totally excellent. It doesn't have a couple of >your optimisations, but other than that it's pretty good. When you send >messages, if you don't have the key it will fetch it for you by trying >keyservers, then finger user@domain. It can snarf keys out of mail >messages, paste keys into them, sign, encrypt, check signatures, use >remailers (type I and mixmaster). Sounds good except the retrieval of keys from the finger. This is a serious weakpoint in your security. Say you have Adam who wishes to communicate with Mary. He get's Mary's key from her .plan file via finger. Eve has control of the server and replaces Mary's key with her own. Now you encrypt message to Mary but you are using Eve's key. Eve decrypts the message re-encrypts with Mary's and neither of you are the wiser. This is also a weakness in the distributed key approach as it presents a single source of failure unless some type of redundancy is built in. I know that there are many issues involved in this and probably should be spun off into a separate thread if you are interested in pursuing it (too many disjointed subjects in one thread tends to become confusing). - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNEKmhI9Co1n+aLhhAQGgfQP/ZnRMzHAFSgfREts8Op5P+JHfRJHG5khl pUexNZh+VmGpuEkKVMCcIVvYJrICWop7XSYtnI6W0mKd3E2TppVgOplpOvnsHVCv cp1hS8a9MfkBns+Jf7xGG4Z2V3crqGP5ZpcF/PR8Yj8o9wHwx5YoqSLYnF5VTzVM OevaTH+8vJE= =VZeI -----END PGP SIGNATURE-----

1 0

CMR paves the road to GAK, and provides no corporate security.
by Trei Family 17 Dec '03

17 Dec '03

I've been mulling over PGP5's CMR feature for a while, trying to decide what I think of it. It hasn't been easy, but I've come down against it. I'm restricting my discussion to the use of CMR in corporate email. I am not addressing stored data. > Jon Callas (jon(a)pgp.com) writes: > There are two things I will discuss in this missive: > (1) The assertion that Corporate Message Recovery is "just like Clipper" > and why this is not true. > (2) The fear a number of people have expressed that Corporate Message > Recovery (CMR) could be used by the US government to slide in GAK. > I think we're agreed that CMR isn't itself GAK and I'll talk some about why > it isn't with (1). I think that we're a lot more worried that the presence of features like CMR will make it easier for governments to mandate GAK. It's much tougher to insist on GAK if a switch requires new software to be developed, and for everyone to purchase, install, and use espionage-enabled software. If CMR - like facilities are already in the software, then GAK could be mandated overnight by executive order. The inclusion of CMR drastically lowers the barriers to mandated GAK. >CMR isn't like Clipper: >* Clipper was a 64-bit key. CMR symmetric keys are full-strength keys (128 >bits or more), backed with a full-strength public key. A word of advice: don't try to discuss Clipper in this forum without checking your facts. Clipper used an 80 bit key. > * Clipper's key was set in hardware by the manufacturer, and users were > required to use it. Actually, the chips left the manufacturer 'blank'. They were to have their unit keys set by some ill-defined process involving government employees. It never really got nailed down, since Clipper was killed before the key escrow agencies and systems were ramped up beyond demonstration levels. > A CMR key is a software-enabled key, no user is ever > required to use it. With a CMR feature in place, a government can say "Starting now, encrypt to this key or we'll throw you in jail." Without CMR, they can't really do this. > There are cases in which a user might "volunteer" to > use a CMR because they work for someone who requires it, [or because the State says it will toss his sorry ass in jail if he does not] > but that's a > problem we'll address with the PGP Secure Resume Server which allows > headhunters to securely and anonymously find people who've made bad career > decisions. [or bad citizenship decisions?] > * A CMR key can be revoked, reissued, or changed. You can periodically > change it as a matter of policy. You can even stop using it. Clipper's was, > again, set in hardware, with no option of not using it. Once again, you're unlikely to do this if the State decides that that would be a good reason to jail you. > * The Clipper symmetric algorithm was secret; CMR keys use publicly > available algorithms. True, but the point is moot - most people beleive that the NSA is perfectly competant to write secure symmetric ciphers without outside review, and since they had given themselves a backdoor, there was no reason to leave the window unlocked as well. > * With Clipper, there was always a concern that an outside agency had the > keys. This is true with a number of other systems (the so-called key > recovery systems), and is the reason that a number of them are lumped > together with the term GAK. Note that the user-organization creates a CMR > key, and the end-user enables it. If any government gets access to this > key, it is because either (1) they solved the Discrete Logarithm Problem, > (2) they broke the public CMR key, (3) they black-bagged your CMR key, or > (4) they are using a subpoena, warrant, or discovery to get the key. We're > working on a way around (1), we can't do anything about (2) or (3), but > these are fine reasons not to use CMR! If you're beset by (4), you need > lawyers, not cryptographers. If the State could do (1), they would not be asking for key recovery in the first place. (2) and (3), are greatly aided by CMR, since CMR provides high value targets; breaking or black-bagging a single key gives you access to a great deal of traffic, and in the case of (4), you lose 5th Amendment protection, since a third party holds a key. > * With Clipper, there was a central repository of all the keys. With CMR, > there is not. I discussed that in detail in my message, "Why Corporate > Message Recovery isn't Key Escrow." Once again, you haven't checked the record. Clipper keys were to be split, with different halves going to different government agencies. There were fairly elaborate plans to prevent posession of only one half giving an attacker an advantage. Thus there were *two* repositories, not one. (From the point of view of the paranoid, this was not much of a comfort - both repositories belonged to the same entity.) > I have noticed that a number of people have the tacit assumption that > business people and corporations are in cahoots with the FBI, waiting to > hand over everyone's secret key. As in all parts of life, there are many, > many businesspeople and corporate execs who are not particularly moral. But > I don't think that their immorality takes this form. If we could examine > the dark, secret thoughts of a corporate scumwaffle -- the ones that he > *really* hopes don't hit the papers -- I sincerely doubt that, "Oh, Louis, > I love it when you rummage my drawers" is among them. Here's an alternative interpretation. I think that 'business people and corporations' feel (with considerable justification, I might add) that they have a moral right to control the information which flows in and out of their worksites, just as they have a right to control to flow of material goods on and off of their premises. To control the flow of material goods, companies install security systems, guards, metal detectors, etc. Depending on the type of good and it's value, these more or less work, though they're never perfect; when the marginal cost of improving security exceeds the loss that the improvement would prevent, you stop adding security. In the extreme case, the diamond workers of Namibia have to undergo a full-body X-ray whenever they leave the diamond reserve. Companies would like to be able to able to exercise similar control over data. However, bits behave differently than do atoms. Physical barriers are almost perfectly transparent. An employee can slip a multi-gigabyte DAT tape in a shirt pocket, or transfer stego'd data undetected inside innocent cover data, perhaps with non-CMR'd superencryption. For data, physical barriers - firewalls, passwords, isolated lans, access controls encryption, et al, can work more or less effectively to prevent unauthorized outsiders from acquiring data they should not. However, there is *no* way in which you can prevent a person you have authorized to receive data from making whatever use of it they desire, even if those uses are opposed to your reasons for giving them the data. CMR serves to give corporate executives the illusion that they can control the uncontrollable. It lets them think they can monitor the expression of their employess, while they can not. It lets them beleive that they can use technology to protect corporate proprietary data from theft by disloyal employees, while they can not. The only way to protect data is to make sure that employees share the goals and ends of the corporation; ie, give them a reason to be loyal and trustworthy. Classified agencies know this. In the classified world, there is a huge effort to protect data from outside attack. There is a similarly intense effort to check that only loyal, reliable, trustworthy people get clearances, and strong 'need to know' controls to restrict what data even they can see. However, once a cleared person has acheived properly authorized access to classified data, there is (in my observation) remarkably little done to prevent them from deliberately walking off with it. CMR provides an illusion that this loss can be prevented. It looks good in a chief security officer's report; it gives warm fuzzies to senior management. However, it provides no real security. In fact, it actually weakens security, since anyone with licit or illicit access to the CMR key(s) can read the data. > Now then, the next topic is the fear that CMR will be used in some > insidious government plot to slip in GAK everywhere. > I worry about this, too. But I don't think it's feasible that CMR can be a > stalking horse for GAK. If the government wants to GAK-enable all PGP, > they'll have to have a plan similar to this: [Strawman GAK plan deleted] Here's a more realistic scenario. 1. OpenPGP with CMR becomes a standard, and is widely accepted and installed. PGP gets rich. (Are you going to claim that this could never happen?) 2. An executive order is signed by the President, ordering that all encrypted email include the FBI public key as a recipient. He notes that this will be no burden to industry, since it's a freebie with the industry standard CMR facility. To summarize: 1. CMR cannot prevent disloyal employees from sending messages that their employers would want to prevent. 2. CMR, widely deployed, would greatly ease a transition to mandated GAK. Given CMR's inability to provide an a desirable goal (improve corporate security), coupled with the severe downside (paving the road to GAK), I have decided that I must oppose it. > Jon Callas jon(a)pgp.com Peter Trei trei(a)ziplink.net

5 4