December 2003 - cypherpunks-legacy

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

Hmm
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Mr-Anonymous-type-person wrote: > www.telcomtraining.com/downloads what's the l/p Mr. Anonymous?

1 0

None
by Anonymous 17 Dec '03

17 Dec '03

On terrorists, one of the Four Horsemen. IS THE ASSAULT ON NATIVE INTELLIGENCE & GOOD WILL WE CALL THE EVENING NEWS ANYTHING OTHER THAN AN ACT OF TERRIORISM? What was the Gulf War but terrorism wearing the death mask of order?-- One big car bomb it was the guys who drove it are dying now one by one--ignored! Is acid rain a form of terriorism? (Think for yourself.) Is GATT or NAFTA anything but a pact among brigands--the World Bank, the IMP their backup men? How long before they fight over the spoils? Who'll do the fighting for them?"

1 0

Canadian crypto export/re-export rules
by Steve Schear 17 Dec '03

17 Dec '03

Can anyone point me to a site with accurate and complete information? --Steve

1 0

RSADSI open RC2 encryption algorithm
by Nobuki Nakatuji 17 Dec '03

17 Dec '03

RSADSI open RC2 encryption algorithm. http://www.imc.org/draft-rivest-rc2desc ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0