December 2003 - cypherpunks-legacy

Public Key Smart Card
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text Date: Mon, 13 Oct 1997 18:48:39 -0400 From: Robert Hettinga <rah(a)shipwright.com> Reply-To: rah(a)shipwright.com MIME-Version: 1.0 To: rah-web <rah(a)shipwright.com> Subject: Public Key Smart Card http://www.businesswire.com:80/cgi-bin/sr_headline.sh?/bw.101397/501100 [(c) 1997 Business Wire | www.businesswire.com] ---------------------------------------------------------------------------- BW1111 OCT 13,1997 5:29 PACIFIC 08:29 EASTERN ( BW)(GEMPLUS) Gemplus Announces Availability Of GPK4000, Public Key Smart Card Business Editors MONTGOMERYVILLE, Penn.--(BUSINESS WIRE)--Oct. 13, 1997-- First Smart Card To Combine Digital Signature, On-Board Key Generation, and Electronic Payment With Multi-Application Functionality Gemplus today announced the availability of GPK4000, the first public key smart card to combine digital signature, on-board key generation, and electronic payment with multi-application functionality. The GPK4000 smart card, with its advanced cryptographic co-processor, can be used to secure Internet, intranet and extranet transactions in such applications as electronic commerce and computer security. GPK4000 features full cryptographic functionality, including 1024-bit RSA-based digital signature at sub-second speed and 4 Kbytes of application memory. Additionally, it provides an on-board key generation mechanism that ensures that the private component of the public key that performs the cardholder's digital signature is never seen outside the card. GPK4000 keys, whether generated internally or loaded by the issuer, can be certified by any certification authority through the card's ability to store industry-standard X.500 certificates in the card's memory. The card has also been specifically designed to strengthen the security of Web sites that rely on the SSL3 protocol for mutual authentication of client and Web server. "We are pleased that industry leader Gemplus has chosen RSAs industry leading technology for their high-quality, high- performance smart card," said Jim Bidzos, president of RSA Data Security, Inc. "RSA is considered to be the most trusted encryption available, whether for Web browsers or smart cards. When it comes to applications of smart cards such as electronic cash or personal identity, there is no such thing as too much security. Users can use these smart cards with the greatest of confidence." Gemplus GPK4000 cards will be used in the upcoming version 2.0 release of ImagineCard, the only complete security solution for both corporate applications and Web services, jointly developed by Hewlett-Packard, Informix and Gemplus. "The additional capabilities of Gemplus GPK4000 enable our customers to deploy more comprehensive smart card applications based on ImagineCard solutions," said Christian Roy, general manager of HP Enterprise Networking and Security Division. "Through ImagineCard and the strength of Gemplus GPK4000 card, HP meets its commitment to bring the benefits of smart cards to support the extended enterprises business processes." "Authentication is a necessary component for the widespread adoption of electronic commerce," said Anil Pereira, director of corporate marketing for VeriSign. "VeriSign Digital Ids stored on Gemplus GPK4000 smart cards provide Internet and corporate network users with a convenient, portable method for secure access to online resources and a trusted, proven solution to participate in secure communications and online payments." Gemplus Public Key Cards GPK4000 is the second in a line of Gemplus public key smart cards for securing Internet, intranet and extranet services. The GPK2000 card, with 512- and 768-bit key lengths was announced in 1996. The GPK (Gemplus Public Key) family will continue to be enhanced, with future versions including more memory and additional functionality. The GPK card range is compliant with ISO7816-1, -2, -3, -4 and is EMV compatible. GPK4000 features a suite of developer algorithms, including RSA, DSA/DSS, DES, Triple-DES, MD5 and SHA1. GPK Developers Kit The GPK Developers Kit enables developers to prototype applications. It includes: -- PILOT GPK, Windows-based software for rapid application development and personalization; -- A card reader (GCR410) with RS232 serial port connection; -- Sample GPK4000 cards; and -- A reference manual and application notes. About Gemplus Gemplus Corporation is the North American subsidiary of Gemplus Group, the world's leading producer of magnetic stripe and smart cards. It manufactures and sells memory cards, microprocessor cards (both contact and contactless), magnetic stripe cards, as well as electronic tags. It also designs and markets software, terminals and systems; and provides personalization, consultancy and training services to offer its customers comprehensive solutions. In 1996, Gemplus Group's total sales were $440 million. By the end of 1997, the company will have a production capacity of 900 million plastic and smart cards. Gemplus sells its products worldwide for such applications as public and cellular telephony, financial transactions, loyalty, transportation, education, healthcare, gaming, identity, access control, pay TV, security for computer networks and electronic commerce. Information about Gemplus' products and services can be found on the World Wide Web at: http://www.gemplus.com. -0- All trademarks are the property of their respective owners. --30--kdb/ny* CONTACT: Dr. Patricia Neptune Neptune Group International Inc. (203)221-2820 or pneptune(a)neptunegp.com KEYWORD: PENNSYLVANIA INDUSTRY KEYWORD: COMPUTERS/ELECTRONICS COMED PRODUCT Today's News On The Net - Business Wire's full file on the Internet with Hyperlinks to your home page. URL: http://www.businesswire.com [Image] --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The e$ Home Page: http://www.shipwright.com/ Ask me about FC98 in Anguilla!: <http://www.fc98.ai/>

1 0

proposal: commercial data recovery
by Adam Back 17 Dec '03

17 Dec '03

If we take the design goal of designing a commercial data recovery system which is not GAK compliant, we can most succinctly state this design goal as the task of ensuring that: - at no point will any data transferred over communications links be accessible to anyone other than the sender and recipient with out also obtaining data on the recipient and/or senders disks I think we can distill the design principles required to meet the design goal of a non-GAK compliant Corporate Data Recovery (CDR) down to ensuring that: 1. no keys used to secure communications in any part of the system are a-priori escrowed with third parties 2. second crypto recipients on encrypted communications are not used to allow access to third parties who are not messaging recipients manually selected by the sender 3. communications should be encrypted to the minimum number of recipients (typically one), and those keys should have as short a life time as is practically possible Included in 2) is the principle of not re-transmitting over communication channels keys or data re-encrypted to third parties after receipt -- that is just structuring -- and violates design principle 2. With these three principles you still have lots of flexibility because you can escrow storage keys, do secret splitting of storage keys, and store keys encrypted to second storage accessors on the local disk for stored data recovery purposes. As an additional bonus, principle 3 adds extra security against attackers gaining access to encrypted traffic after the fact -- the recipient no longer has the key -- this is a form of forward secrecy. Systems designed to the CDR design principles are of significantly less use to GAKkers than PGP Inc's GAK compliant Commercial Message Recovery (CMR) design. The CDR design significantly hinders the take up of GAK if widely deployed. Design principle 3 -- forward secrecy -- is inherently hostile to GAKkers, and is the strongest statement you can make against GAK: you are purposelly _destroying_ communications keys at the earliest possible moment to ensure that GAKkers can not obtain the keys by legal and extra-legal coercion, black mail, and rubber hose cryptanalysis. The whole system translates into the Feds having to come and physically take your disk to obtain information about you, which is much better than GACK, and not what the GAKkers are interested in at this point. The GAKkers would like to install themselves, and coerce companies into installing for them (via GAKker/USG/NSA/NIST organised efforts such as the 56 bit export permit for companies installing key escrow; and efforts such as the Key Recovery Parners Alliance (KRAP)). I fear that PGP Inc's CMR proposal inadvertently meets most of the NIST/NSA specified KRAP requirements. What the GACKers want is systems where they can perform routine key word scanning and fishing expeditions into your communications from the comfort of their offices, without your knowledge. This is push button Orwellian government snooping. Within the constraints imposed by the CDR design principles, there is plenty enough flexibility to acheive the commercial data recovery functionality to similarly weak levels of enforcability as achieved by the CMR design. Weak levels of enforceability are appropriate because there are other exceedingly easy bypass routes: super-encryption, and walking out of the office with a DAT tape. I would like to organise a collaborative effort to write a white paper discussing how to implement various functionalities using the CDR design principle. Then I would like to see discussion of which set of these functionalities which best acheive the user requirement for company data recovery. Lastly I would like to see a collaborative development effort to provide a example implementation of a CDR system which can be used as a discussion point for the OpenPGP standardisation process. I suppose the best place to discuss this process is the IETF forum for discussion of the OpenPGP standard, the OpenPGP mailing list (subscribe by sending message body "subscribe ietf-open-pgp" to "majordomo(a)imc.org"). I have already had people express in email to me their interest in doing this. Those people can speak up if they want to. Technical input is sought from people opposed to GAK compliant software, and from PGP Inc, and others defending PGP's GAK compliant CMR proposal. 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`

12 23

Re: [RePol] First Post!
by TruthMonger 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jari Aalto, confirmed by veteran, respected CypherPunk Dr. Dimitir Vulis, KOTM, to be a government disinformation artist, wrote: > | Sat 97-10-11 Anonymous <anon(a)anon.efga.org> list.repol > | I've downloaded pgp. > > | How do I send the key to this list ? > Don't! DO! > [From ema-tipgp.html] Notice there is no verifiable URL pointer given for this alleged reference. Typical of spoofing attacks. > 10.0 General PGP guidelines According to who? Aunt Ema, or Tot? > 10.1 About including the public key in the mail message > > Do not distribute your public key by mail or Usenet post, because > there are more proper ways. People generally do not want that 'you' > send the key to them, instead they want to get it by itself from > some trusted channel: finger or key server. The reason for this > should be obvious: email is not a secure channel, anyone can > replace the contents of your mail with something other. Bullshit. Email is no less secure than other channels on the InteNet. (Is too!) {Is not!} (Is too!) {Is not!} (Is too!) {Is not!} The chances of your public key being compromised through email to a mailing list are slim. > Use some/all of the ways here to make your public key available: > > o Put it in your ~/.plan file, so people can simply finger > you for it. Open the ~/.plan file and just insert key there, > ,then anyone who fingers you can read the key: > > % finger foo(a)site.com Bad idea! It makes it vulnerable to attack by those with access to your system(s), as well as to attack by outside hackers. > o Post it to a public-key server which in turn automatically > ,distributes your key to all the other keyservers. Be aware that the public-key servers are run by agents of the federal government whose goal is to prevent crypto users from avoiding registering their keys with coming GAK laws. > | I'm new at all this anonymous stuff! > > Please read the pgp docs that came along the program. More pgp and > remailing pointers can be found from my main page > > ftp://cs.uta.fi/pub/ssjaaa/ssjaaa.html Which is full of lies! Please note that the proper procedures for obtaining and using Crypto Keys are outlined by CypherPunk Notable Newbie of the Year, A. Hoir, in a series of posts on the CypherPunks mailing list. I am including my public key below, within the body of this email, and it can be verified by checking it against the listing for my keys on the keyserver at http://www.pgp.com/ . Lastly, and most importantly, take the time and effort to verify for yourself any claims made by those posting to mailing lists, in general, and using anonymous or misleading personas, in particular. TruthMonger > *===================================================================* > To unsubscribe or subscribe send a message of UNSUBSCRIBE or SUBSCRIBE to > the email address REMAILER-POLITICS-REQUEST(a)SERVER1.EFGA.ORG - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGP for Personal Privacy 5.0 mQDiBDRCDGgRAgDz0VR8oKaE3LeAkKi1tnNfTPaUQzhXFD0Tf7HTmO1BxSqxVO8U mxvPCTtw2KLRtYt+udXeHDsduyDxxBC8U0xrAKD/BLyXv9cjrG1pr+y4yaor4TH7 6wH/RlhBvKUwZ2/NOWcS3RKxz/25LoW7Y6LTT4ahiFWQUMFpOBRxclsiLajOoci3 8pdjqr2Oy5uJP6EbUARMFgUThAIAwvqTOSpVumu4ib50yojvuYniN01tg9c3jmCv KV28a/LHEpug3R1FusI1BaOuQVTRyLgmoJRhl9uqjonUS/vdgrQlSmFyaSBBYWx0 byA8amFyaS5hYWx0b0BudGMubm9raWEuY29tPokAUQQQEQIAEQUCNEIMaAUJAAFR gAQLAwECAAoJENVQ+s43zWjf9p0An164iqcY9UfDDacAhKQh0PJ534aoAKDTHx68 3h+G5qyNPYxZXTrVBJy0CLkAjQQ0QgxxEAIA/2RE3cUr5HlC5rDt3D+6LqbA6pt/ Yj8cEhCKzfXepCKyMowSKcSeucikNdFkSpNf4jVZN0aAt3aLgQiubKRdVQACAgIA ojrQS61RR4FHVsn6hi78CIUfdJFtjcPB4PgHMj5VQUCv9QN926d7mk13PCPjeWU3 4eip3RaukG/WfeaQXT58OIkATAQYEQIADAUCNEIMcQUJAAFRgAAKCRDVUPrON81o 3xgEAJ4yQ2yR8W3yLefi5YyhfRNc5kGRYwCfYgVqqCamaOpJhNWfUNfzVVIB7Ng= =SubM - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBNEIPuNVQ+s43zWjfEQKX+wCg5MydykFtaUVN9Pj9mYbT55SdWzMAoKeD SlKAfuAz3OGRko9Chm11NBFy =S6R7 -----END PGP SIGNATURE-----

1 0

No Subject
by biz＠savoynet.com 17 Dec '03

17 Dec '03

//////////////////////////////////////////////////////// Realizing that many of you do not wish to receive UCE, if you would please type REMOVE in the Subject Header, you will not hear from me again, you WILL be permanently removed. If you don't do this, and send me a nasty reply, there will be no way for me to REMOVE you. ///////////////////////////////////////////////////////// We are looking for reseller for our Virtual Pets/Electronic Pets Tamagotchi Style Virtual Pets On sale 3 in 1 Electronic Pets ( We have 200,000 pcs in our Taiwan factory ready to ship ) Price: $3.5 FOB Taiwan at quantity 1000 UP Smaller quantity: price by request. This is most popular electronic toy. We can provide the "Virtualc Pets", Dinosaur, Puppy, Kitten 3 in 1 It can be re-set, so you can play with your pet for a long long time. If you are interested in these products. Please contact with us. mailto:biz@savoynet.com Long Well Electronic Corp. P.O Box 15211, Fremont, CA 94539

1 0

Re: James A. Michner [non-crypto]
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Jim Choate wrote: > Thought some of you might care to know that James A. Michner the Pulitzer > prize winning author who lives here in Austin, Tx. has decided to take > himself off the kidney dialysis machine that has been keeping him alive. I guess that means the end of The True Story of the InterNet...

1 0

Fuck You!
by Bianca 17 Dec '03

17 Dec '03

I found your address, despite your subterfuge, and I am going to fuck up both you and your computer system. I don't like fuckwads sending bullshit to my email. Fuck You (& the horse you rode in on)

2 1

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, plus lots of interesting links to remailer-related resources, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail. For more information, see: http://www.c2.org/~raph/premail.html For the PGP public keys of the remailers, finger pgpkeys(a)kiwi.cs.berkeley.edu This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{'cyber'} = '<alias(a)alias.cyberpass.net> alpha pgp'; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"jam"} = "<remailer(a)cypherpunks.ca> cpunk mix pgp hash middle latent cut ek"; $remailer{"winsock"} = "<winsock(a)rigel.cyberpass.net> cpunk pgp pgponly hash cut ksub reord ?"; $remailer{'nym'} = '<config(a)nym.alias.net> newnym pgp'; $remailer{"squirrel"} = "<mix(a)squirrel.owl.de> cpunk mix pgp pgponly hash latent cut ek"; $remailer{'weasel'} = '<config(a)weasel.owl.de> newnym pgp'; $remailer{"reno"} = "<middleman(a)cyberpass.net> cpunk mix pgp hash middle latent cut ek reord ?"; $remailer{"cracker"} = "<remailer(a)anon.efga.org> cpunk mix remix pgp hash ksub esub latent cut ek reord post"; $remailer{'redneck'} = '<config(a)anon.efga.org> newnym pgp'; $remailer{"bureau42"} = "<remailer(a)bureau42.ml.org> cpunk mix pgp ksub hash latent cut ek"; $remailer{"neva"} = "<remailer(a)neva.org> cpunk pgp pgponly hash cut ksub ?"; $remailer{"lcs"} = "<mix(a)anon.lcs.mit.edu> mix"; $remailer{"medusa"} = "<medusa(a)weasel.owl.de> mix middle" $remailer{"McCain"} = "<mccain(a)notatla.demon.co.uk> mix middle"; $remailer{"valdeez"} = "<valdeez(a)juno.com> cpunk pgp pgponly hash ek"; $remailer{"arrid"} = "<arrid(a)juno.com> cpunk pgp pgponly hash ek"; $remailer{"hera"} = "<goddesshera(a)juno.com> cpunk pgp pgponly hash ek"; $remailer{"htuttle"} = "<h_tuttle(a)rigel.cyberpass.net> cpunk pgp hash latent cut post ek"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. usura(a)replay.com is _not_ a remailer. remailer(a)crynwr.com is _not_ a remailer. There is no remailer at relay.com. Groups of remailers sharing a machine or operator: (cyber mix reno winsock) (weasel squirrel medusa) (cracker redneck) (nym lcs) (valdeez arrid hera) The remailer list here has been out of date for some time, but should be up to date now. I'm still working on updating the web page. Last update: Mon 13 Oct 97 6:45:44 PDT remailer email address history latency uptime ----------------------------------------------------------------------- hera goddesshera(a)juno.com ------------ 5:55:28 99.50% squirrel mix(a)squirrel.owl.de ----- ------ 3:25:30 99.49% nym config(a)nym.alias.net **####+## +# 1:16 95.21% cyber alias(a)alias.cyberpass.net *+++**+** *+ 11:56 94.67% mix mixmaster(a)remail.obscura.com +++++*++* + 26:05 94.54% redneck config(a)anon.efga.org *##**++** ## 1:47 94.48% neva remailer(a)neva.org *+ + -+- - 1:33:09 94.37% winsock winsock(a)rigel.cyberpass.net ..--..--- -+ 9:43:02 94.02% jam remailer(a)cypherpunks.ca ++++*+++ +* 23:21 94.00% cracker remailer(a)anon.efga.org *++*+*++ ++ 17:35 93.90% replay remailer(a)replay.com ****** ** ** 3:46 93.78% bureau42 remailer(a)bureau42.ml.org ----- --- 3:30:56 87.00% arrid arrid(a)juno.com --------- - 8:26:08 86.01% reno middleman(a)cyberpass.net +++ *+++ 1:01:28 66.48% valdeez valdeez(a)juno.com 4:58:22 -25.98% History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. ek Encrypt responses in reply blocks using Encrypt-Key: header. special Accepts only pgp encrypted messages. mix Can accept messages in Mixmaster format. reord Attempts to foil traffic analysis by reordering messages. Note: I'm relying on the word of the remailer operator here, and haven't verified the reord info myself. mon Remailer has been known to monitor contents of private email. filter Remailer has been known to filter messages based on content. If not listed in conjunction with mon, then only messages destined for public forums are subject to filtering. Raph Levien

1 0

After All,-----It Is *YOUR* Life
by skoked＠mail2.c-flash.net 17 Dec '03

17 Dec '03

After all, It is *YOUR* Life-- I would like to let YOU in - on a small Gold Mine!! I have.... If you are like many other people who don't like going to work-This is for YOU!! Even if you love your job (especially if You don't) - This is for YOU!! What I'm about to say maybe UNBELIEVABLE at first, But read on... THIS IS NOT A SCAM--- I am an ordinary Joe just like YOU!! EVERYTHING YOU NEED----(except a small amount of dedication and time) Is being offered to *YOU* ---*RIGHT NOW*!!! The rest will follow !!! I'm going to share with You--- My *FREE* Software--- To get You started on Your way !!! ---WHAT HAVE YOU GOT TO LOSE?--- -Soon, from 9 to 5 , You will be doing all of the things You only dreamed of !!! ***RIGHT NOW*** To get YOUR *FREE* Software, Reply with the subject 'FREE' P.S.- Reply only with Subject 'FREE' (nothing else should be in this field) /////////////////////////////////////////////////////////////////////////////// This Message was Composed using Extractor Pro Bulk E- Mail Software. If you wish to be removed from this advertiser's future mailings, please reply with the subject "Remove" and this software will automatically block you from their future mailings.If you do not reply only with subject "Remove", there is no way for you to be "Removed"........So please do so if you want to be "Removed". ////////////////////////////////////////////////////////////////////////////////

1 0

Why Corporate Message Recovery isn't Key Escrow
by Jon Callas 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A number of people have asserted that the Corporate Message Recovery feature is key escrow. From where I sit, the difference is easy to see. My definition of "key escrow" is that another person or organization keeps a copy of the user's secret key. Here's an example, based on actual customers who use key escrow to manage their data: This corporation uses PGP for a number of things. Email, engineering plans, CAD drawings, and so on. They've done so at least since the days when we were Viacrypt, and I believe they even used PGP 2.x. When an employee arrives at this company, they create a key pair for the new employee, hand it to them on a floppy, keeping a duplicate floppy with the keypair on it, which they toss into a safe. Literally. This is key escrow. They do this because they can't afford to lose their files and messages. Their policies require them to keep the secret keys, as if they were the same as keys to offices or file cabinets. I don't know about you, but I'm appalled. Nonetheless, they're our customers. In spite of inheriting them, we have a responsibility as businesspeople to at least listen to their concerns. - From our standpoint, the issue gets even touchier. They don't like what they're doing, and they want us to give them a better way to manage their data. Does anyone really believe that only moral response is to flinch and turn away? I'd like to be in a situation where I didn't have to deal with this. Wanna trade positions? I'll sit over there and cluck my tongue about how adding an extra recipient weakens security while you figure out how to help these folks out of the mess they're in. While you're at it, I'll pen a few lines about how giving clean needles to addicts undermines society, and handing out condoms encourages kids to have sex. Trust me, it's less nerve-wracking than what we have to do to solve this problem, which involves running through hypothetical scenario after hypothetical scenario, balancing the user's privacy against the organizations property rights, the privacy and property rights of one organization against that of another, and so on. Corporate Message Recovery isn't key escrow for a number of reasons. First, it doesn't involve keeping a copy the end-user's secret key. I hope that's obvious now. Second, the system behaves very differently. With a key escrow system, there is a superb McGuffin (which is what Alfred Hitchcock called the crux of a mystery, like the falcon in The Maltese Falcon) - it's the safe. Break into the safe, or lend its contents out, and all Hell breaks loose. Whoever has those keys (which easily fit on a single Zip disk) has the company at its mercy. They can decrypt or sign anything they care to. There is a great thriller to be written here. It isn't so with a CMRK. The worst possible way to use the feature is to have a single, company-wide CMRK. If that gets lost, the thriller you can write isn't nearly as interesting. Yup, you can steal any of the plans, read all the mail, and so on. That's bad. It's deplorable, actually. But it isn't a difference that makes no difference. At least there isn't a gang of keys out there that can sign anything with anyone's ID. This is not the only way to use Corporate Message Recovery, it's just the worst way. Remember, it's just a notation in the self-signature that states, "When you encrypt to me, encrypt to X." That's any X. You can have a different CMRK for every department, every workgroup, or even every user. A sophisticated policy might be that every user sets their supervisor's key to be their CMRK. Another is that everyone in Department X sets their office mate, or lab partner, or other person. You can have anything that suits your group, from Recovery Central, to Recovery Hierarchy, to Recovery Buddy System. The significant improvement that PGP's web of trust has over a traditional hierarchical system is that you can set up a top-down system for validity, but you don't have to (and in our opinion, shouldn't). Analogously, the significant improvement that Corporate Message Recovery has over key escrow is that you can tailor a recovery system to your needs (including and especially deciding it's not for you). Jon -----BEGIN PGP SIGNATURE----- Version: PGP for Business Security 5.5 iQA/AwUBND6j8H35wubxKSepEQI58gCfQuiMZCyfe7cD1F2nNgFtluQqGXMAoJUh yHFMApAlDjzwRTCspBi7p9t3 =a2Zo -----END PGP SIGNATURE----- ----- 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)

6 10

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