December 2003 - cypherpunks-legacy

Re: PGP CAKware & IETF controlled Open-PGP standard
by Adam Back 17 Dec '03

17 Dec '03

Jonathan Seybold <jseybold(a)pgp.com> writes: > > Adam, one aspect of your suggestion puzzles me: > One thing which concerns me most is KNOWING when a message I send > (or receive) could be read by someone else. The PGP CMR scheme makes this > very clear: if there is an extra CMR key, the message may be read by > whomever controls that key, if not, only the recipient may decrypt the > message. > If, however, the message is secretly re-encrypted to a corporate > storage key AFTER it is received, I will never know that. You will if you mark the key with this information. This is the same approach PGP is already using to provide the GAK compliant implementation of corporate access to stored emails. > The reality is that: > 1) Organizations have a legitimate need to recover information. You > can argue about this as much as you want. I'm not arguing. Of course they do. What I _am_ arguing is that in designing systems to provide companies with data recovery mechanisms that you should a) not weaken security more than necessary, and b) that it would be nice if you used a method which doesn't introduce GAK compliancy for communications keys. I presented I think in plenty of detail an alternate mechanism which is both non-GAK compliant, and more secure. So what is the problem? Is there a technical flaw in my solution? > A great many organizations will simply NOT INSTALL systems which do > not accommodate this. If businesses, law firms and many other > organizations will not use PGP, we will not have a viable standard. Agreed 100%. This is why I went to great pains to demonstrate precisely how you could achieve recovery of stored messages in a more secure and non-GAK compliant way. > which are easy to use and administer, which balance the rights of > the individual against those of the organization, and which do not > mislead people inside OR OUTSIDE of the organization. my proposed mechanism for stored email recovery copes with all that. > This means, I believe, that they should NEVER INVOLVE HIDDEN BACK > DOORS THAT USERS ARE NOT AWARE OF. Agreed. You can flag backdoors with either solution. > PGP Inc. has tried to work through these issues in a new way. I think that > we have agonized through a lot of trade-offs and come up with something > that will really work -- and work well. It works well enough, but it could be made much more secure, by separating storage key functionality from transient message key functionality. This would also give you the chance to resolve the articificially created need for GAK compliancy, which arises because you are being forced by this lack of distinction between key functionalities to use one key for both long term storage and what should be transient communications key usage. > There is always the danger that someone is going to use your tools > in ways that you do not approve of. We are trying to make it as easy as > possible for people to do the "right" thing, and to discourage them from > doing the "wrong" thing (like secret snooping). > With regard to GAK, the objective should be to accommodate > legitimate corporate needs without setting in place the foundation for GAK. If that is PGP's aim, they failed most miserably. > We have tried very hard to do this by creating the foundation for a highly > flexible and decentralized approach which allows different organizations to > do things in very different ways. We have also tried to keep everything > very visible so that every party to a conversation knows exactly how > "private" that conversation is. Decentralised control is good, of course, but the pgp5.5 and SMTP policy enforcer is a ready to roll GAK system. The visibility principle is good but is an entirely separable issue. > I think that the sort of thing that PGP Inc is doing is the best > defense against GAK. It knocks the pins out from under the argument being > used in this country that corporate message recovery requires a key escrow > infrastructure, Yes, it is better than a government arranged "key recovery" key infrastructure. > and will almost certainly lead to a wide variety of > organization-specific implementations that will be jealously guarded > and very difficult to corral. I cannot imagine your 80% scenario > working in the U.S. where there are so many small and medium-sized > organizations and so much concern about government intrusion. If the OpenPGP standard is to include the GAK compliancy features, and these competing systems use this standard, as long as the sum of the OpenPGP compliant systems gets to 80% (or whatever) it doesn't matter whether this is mostly provided by PGP, or mostly by GAK sellout companies like IBM, or TIS. It is a dangerous development to have a largely fielded compatible set of GAK compliant products, whoever the providers are. Email encryption needs to be standardised, otherwise people can't talk to each other. This suggests to me that one standard _will_ evolve as the winner, or if there are other standards, they will be backwards compatible to this main standard. A very related example of this kind of principle in action is the fact that most secured web traffic is secured by Netscape's SSL. > I do worry a little more about countries like France, but I have yet > to see any guaranteed "safe" alternative (including yours) that the > French Government is likely to accept. The French Government used require licenses for crypto, which were hard to come by, and crypto without licenses was illegal. In that framework you couldn't see them liking PGP period. More recently they have been swaying towards allowing crypto without licenses, but only if it is GAK compliant. PGP 5.5 & SMTP policy enforcer should be a sell out. Maybe y'all should pitch it to the French government and SCSII (their NSA). > I am very interested in seeing criticism and suggestions for > improvement and would like to see this discussed and debated as openly as > possible. In particular, I would be interested in how one could reconcile > your scheme of separate transmission and storage keys with my concern that > everyone party to an exchange always be informed about who might be able to > read that exchange. That's simple: you already have the mechanism, just put one of those attributes Jon described on the key stating this fact. > However, I think that some of this discussion should be separated from the > Open PGP discussion. NO ONE wants to build any sort of mandatory message > recovery scheme into the base Open PGP specification. PGP Inc itself is > committed to always providing a base client software product which does not > implement message recovery keys. Glad to hear it. Can we take it from that that PGP won't be arguing for the GAK compliancy flag Jon Callas described to be part of the standard then? This is needed for said non "message recovery" base client product to also be OpenPGP compliant. > The key structure needs to be flexible enough to accommodate all > kinds of uses we cannot now envisage. Yes, I believe that CMR keys should > be supported -- as should a lot of other things we need to talk about. CMR keys and the way that PGP has designed their associated flags and the SMTP policy enforcer app are what make PGP GAK compliant. Also there are clear security advantages to _never_ send communications encrypted to two keys. There are clear security advantages to separating the functionality of storage and communications keys. Communications keys are the most sensitive of all, and should have the shortest life times. In some applications this could be minutes. > Finally, let's dispense with the non-productive PGP Inc- bashing. We > founded this company to take something which was going to die because it > had no company behind it, and push it forward. PGP Inc was the first step > in that process. Open PGP is the next step. The PGP bashing PGP observes is an attempt by the pro-privacy crypto community to influence PGP to re-think the GAK compliancy, and to point out the more secure way to implement corporate recovery of stored email messages without GAK compliancy. I reserve the right to bash any company which attempts to field GAK compliant software. > Most companies are very ambivalent about "open" standards. Most of > the time, "open" to them means something which they control and everyone > else adheres to. PGP Inc, on the other hand, is very committed to the > spirit of open standards. We understand very well that we will only be > successful if there is an open and completely interoperable international > standard. > > I also want to assure you that all of the things we do get > extensively debated within PGP. Thus far, we have always been able to work > out consensus decisions which, I believe, are more sophisticated and better > thought-out for that debate. In all of this I have never heard ANYONE at > PGP Inc. suggest that the company add any feature or capability to the > software in order to appease any government agency. GAK is just as scary to > us as it is to you. If PGP wants to make an additional stance against GAK here are my recommendations: 1. remove GAK compliancy fields 2. scrap SMTP GAK compliancy policy enforcer app 3. separate storage and communications keys 4. use shorter lived communications keys giving forward secrecy 5. implement corporate recovery of stored mail folders with escrowed storage keys Forward secrecy is _the_ strongest statement you could possibly make against GAK. > Jonathan Seybold > Chairman, PGP Inc. Adam Back Protocol designer, Cypherpunks list member

1 0

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

17 Dec '03

I also was pondering this question as to which purpose the current "encryption key" could be used for; should it become the "communications key", or should it be the "storage key". Clearly it could be used for either; and is in fact currently used for both, which is where the security problem arises. What you have described (very clearly as always) is the case for making the current "encryption key" the "communications key". You are forced to make this choice because there is only one key available, and without a communications key .. well you can't communicate :-) However this leaves the question: what do you use for a "storage key"? To see why this argument is important, you can see that you have painted yourself into a corner where you will be forced to admit that you need to have separate storage and communications keys. Probably this doesn't bother you as you didn't react adversely to my earlier description of how it was a good idea to separate key functionality. Let me quote: Hal Finney <hal(a)rain.org> writes: > This should facilitate more frequent changeover of encryption keys as Adam > Back describes, which can be good security practice. It is a significant > improvement provided by the new key structures of PGP 5. It is indeed. It is also very good for another reason: it allows corporate escrow of encryption keys without simultaneously allowing the company to forge signatures. However you have created a problem for your self in the following argument which suggests that you must have two encryption keys; one for storage and one for communication. It also suggests that my method for achieving corporate recovery of email is better acheived without the GAK compliancy field (second recipient) which was my earlier point. > Adam wrote: > > > 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. > > That sounds reasonable, at least if the first recipient is also using > short lived keys. Presumably these kinds of policies would be established > by the corporate security office. But certainly if one class of keys > uses short lived keys then it would be logical for the other class to > do so as well. By doing it this way you do claw back some of the security lost by having a second crypto recipient, as you say. However you now can't recover communications past the expiry date of the short lived corporate key. As the whole point of corporate message recovery is to guarantee message recovery of stored messages (or at least this is the user requirement Jon Callas gave in his post explaining the need for CAK), you have just thrown away much of that ability. This is an extreme pity because you are now faced with a dilemma. Your dilemma is, do you: a) use short lived encryption keys (for both user and corporate master key), and have good security but limited recovery of stored encrypted email after that short period. Also the poor user won't be able to even access, never mind recover his stored encrypted email! b) or do you use a long term encryption key for the corporate master key, and hence good recovery of stored encrypted email, but poorer security (and as an additional disincentive end up building a GAK compliant system.) This dilemma highlights really very well my point as to why you really do need separate storage and encryption keys. Introduce them, and both problems vanish. You can then: - Have short term communications keys for the employee - Have long term storage keys for the user escrowed with the company - Have long term key recovery storage key for the company It's beautiful, everything falls into place, and it's more secure. Also as a convenient side-effect the way that you build a corporate stored message recovery scheme under this system is non-GAK compliant, which saves you from being screamed at by cypherpunks, and from being dissed in the NYT and other places. Presumably given Jonathan Seybolds clear statement of PGP's aims: Jonathan Seybold <jseybold(a)pgp.com> wrote: > With regard to GAK, the objective should be to accommodate > legitimate corporate needs without setting in place the foundation > for GAK. this side-effect of removing the GAK compliancy should therefore be very pleasing to PGP also. The way that you implement corporate recovery of stored encrypted messages once you accept the clear need for separate communications and storage keys is easily derivable from new the key purposes. It is basically as easy to circumvent as the previous GAK compliant method. Several PGP employees commenting on this didn't seem to think enforceability was that big a deal. (I agree with them: if all it takes is to super encrypt with PGP itself, it's not worth losing sleep over.) Here's how to do corporate recovery of stored encrypted messages, now with the new separated storage and communications key functionality: 1. Corp. employee receives encrypted email, the email is encrypted to the employee's short life time communications key. - employee decrypts email with pgp5.6 client - pgp5.6 client encrypts the plaintext to users long term storage key, and to the companies recovery key as a second "storage-recipient", and places in received mail folder 2. Corp. employee sends encrypted email - The pgp5.6 mail client encrypts plaintext of email to users long term storage key and to the companies long term storage recovery key and stores in the sent email folder - The pgp5.6 mail client encrypts the plaintext of the email to the recipients short lived communications key and passes on to the MTA 3. Normal user access of encrypted stored email - user's email client decrypts stored email with users storage key 3. User forgets password, or dies, or leaves in a huff, company needs access to stored email - company uses company recovery key to decrypt users stored email An alternate set up would be to escrow the users long term storage key with the company. Basically equivalent. But I think it is probably easier to use multiple recipient as it saves the headaches of having to securely transmit 10000 users storage keys securely. Much easier to install the software with the department/company recovery key bound into it, and to remote update the company recovery key by fetching the new from the company key server when it expires. There are lots of other issues of course, with regard to architecture of recovery setup. However there is a basic equivalence between key escrow and session key recovery methods, and you can acheive all kinds of departmental escrow jus the same as you could with the previous system. > Actually it's likely that the corporation will change its shared access > keys more frequently than user keys, at least if they are using an > access model where there are relatively few shared keys. It will be > easier to change a few keys which are controlled by corporate officers > than to get every one of 10000 employees to generate a new key every week. I can't see any reason why you would not be able to entirely automate and hide the process of generating new communications keys every week, every day, or _every communication_. The process can be handled automatically by the software. With El Gamal you have a very computationally cheap way to generate keys other than the first key; discard the private components, and treat the public modulus as a pre-computed prime as you currently do for the fast key generation option on EG key generation. I feel somewhat better about this post than previous ones; I haven't been rude to PGP, and I feel some progress has been made in clarifying things. Perhaps it's just interacting with Hal, who always was one of the most level headed people on cypherpunks; it's much harder to pick faults in what he says, and he doesn't make ill thought out political statements. I think there are still some issues to resolve if we start to talk about "per communication" communication key updates, but for per week, or per month or whatever, I think the above is good. 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`

1 0

Phone Line Internet
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Inter@ctive WeekOctober 10, 1997 Nortel Unveils 1-Megabit Phone Line Ethernet By Peter Lambert 1:00 PM EDT Northern Telecom Inc. announced the Nortel 1-Meg Modem, a modem designed to extend Ethernet-equipped personal computer access across standard telephone lines. The company plans to deliver plug-in modules for its DMS phone company central office switches and its Internet Thruway voice switch bypass device in the first half of 1998. It will license the 1-Meg Modem technology to modem makers. The 1-Meg will deliver 1-megabit-per-second speeds downstream into homes or businesses and 120-kilobit-per-second speeds in the other direction, and like Ethernet-connected local area network (LAN) interfaces, the modem will always be on, requiring no dial-up connection. The technology will offer compatibility with both frame relay and Asynchronous Transfer Mode (ATM) backbone networks. Separately, Nortel finalized a deal to gain an unspecified equity interest in NetSpeed Inc. and rights to integrate NetSpeed's Digital Subscriber Line technology into its own products. NetSpeed's ATM-based LoopRunner Digital Subscriber Line Access Multiplexer is designed to terminate up to 560 users per central office system rack. Nortel can be found at www.nortel.com NetSpeed can be found at www.netspeed.com Email Peter Lambert

2 1

DCSB: Carl Ellison on Identity and Certification for Electronic Commerce
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text X-Sender: rah(a)pop.sneaker.net Mime-Version: 1.0 Date: Mon, 13 Oct 1997 12:52:18 -0400 To: dcsb(a)ai.mit.edu, dcsb-announce(a)ai.mit.edu From: Robert Hettinga <rah(a)shipwright.com> Subject: DCSB: Carl Ellison on Identity and Certification for Electronic Commerce Cc: cme(a)cybercash.com Sender: bounce-dcsb(a)ai.mit.edu Precedence: bulk Reply-To: Robert Hettinga <rah(a)shipwright.com> -----BEGIN PGP SIGNED MESSAGE----- The Digital Commerce Society of Boston Presents Carl Ellison CyberCash, Inc. Identity and Certification for Electronic Commerce Tuesday, November 4, 1997 12 - 2 PM The Downtown Harvard Club of Boston One Federal Street, Boston, MA It is a common belief that you can not trust someone on the net unless/until you establish his "identity" via an interactive protocol in which the other person establishes proof of ownership of a given private key and a transfer of certificates which establish a binding between that key and a person's "identity" (in the form of a common name plus enough information to make it unique in some global hierarchy of names). This talk will establish that the proof of key ownership is the primary value obtained from this process and that the global hierarchy of names is effectively useless. It will propose certificates for electronic commerce which use a person's public key to identify him, avoiding the hierarchy of names. Carl Ellison is a cryptographic engineer with CyberCash, Inc., of Reston VA. He has been involved in cryptography since about 1978 and seriously involved since doing his first cryptanalysis in 1986. With the introduction of PEM in the early 1990's, he found the PEM certification process to be a killing roadblock and has studied certification and the establishment of identity since that time. This meeting of the Digital Commerce Society of Boston will be held on Tuesday, November 4, 1997, from 12pm - 2pm at the Downtown Branch of the Harvard Club of Boston, on One Federal Street. The price for lunch is $30.00. This price includes lunch, room rental, various A/V hardware, and the speaker's lunch. ;-). The Harvard Club *does* have dress code: jackets and ties for men (and no sneakers or jeans), and "appropriate business attire" (whatever that means), for women. Fair warning: since we purchase these luncheons in advance, we will be unable to refund the price of your lunch if the Club finds you in violation of the dress code. We will attempt to record this meeting and put it on the web in RealAudio format at some future date We need to receive a company check, or money order, (or, if we *really* know you, a personal check) payable to "The Harvard Club of Boston", by Saturday, November 1, or you won't be on the list for lunch. Checks payable to anyone else but The Harvard Club of Boston will have to be sent back. Checks should be sent to Robert Hettinga, 44 Farquhar Street, Boston, Massachusetts, 02131. Again, they *must* be made payable to "The Harvard Club of Boston", in the amount of $30.00. Please include your e-mail address, so that we can send you a confirmation If anyone has questions, or has a problem with these arrangements (We've had to work with glacial A/P departments more than once, for instance), please let us know via e-mail, and we'll see if we can work something out. Upcoming speakers for DCSB are: December James O'Toole Internet Coupons January Joseph Reagle "Social Protocols": Meta-data and Negotiation in Digital Commerce February Donald Eastlake SET We are actively searching for future speakers. If you are in Boston on the first Tuesday of the month, and you would like to make a presentation to the Society, please send e-mail to the DCSB Program Commmittee, care of Robert Hettinga, <mailto: rah(a)shipwright.com> . For more information about the Digital Commerce Society of Boston, send "info dcsb" in the body of a message to <mailto: majordomo(a)ai.mit.edu> . If you want to subscribe to the DCSB e-mail list, send "subscribe dcsb" in the body of a message to <mailto: majordomo(a)ai.mit.edu> . We look forward to seeing you there! Cheers, Robert Hettinga Moderator, The Digital Commerce Society of Boston -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBNEJRn8UCGwxmWcHhAQGICggAoRXxsE1E2LsAxMX0jeg0nWbBxTKV5u6k riMP3EGN1UC/niyJu5rz8cB98y+YpdhfMBcw/qvgPvqt8h/ep897KMNKvVtYGloE 8Uyb6xf8czX3cD2VQ/M5c+eTEcjlorojUYSeo3d2eyc2e1aX+g23ydVkfawZPDBa f5DCUs5hN1s+ehThV9QpsyN31lpuc4YgUiSpWZCscbkrpXPM0zY2m/GhMdgNXw97 sHs2P3Pmnkgt61Yfkf6u1pMdxt3hpmgv78LLuFaZcsyIAk2Aur2yku53FqarFomo 55Qu1BnrRYH21+RE757wLzic4fXreYnkfNCo2bz/RXLkO7piVwqGsQ== =E24t -----END PGP SIGNATURE----- ----------------- 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/> For help on using this list (especially unsubscribing), send a message to "dcsb-request(a)ai.mit.edu" with one line of text: "help". --- 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

attn bianca@dev.null
by bureau42 Anonymous Remailer 17 Dec '03

17 Dec '03

1 0

Re: Defeating MITM with Eric's Secure Phone
by John Kelsey 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- [ To: Cryptography, cypherpunks ## Date: 10/10/97 ## Subject: Re: Defeating MITM with Eric's Secure Phone ] >Date: Thu, 9 Oct 1997 21:02:53 -0700 >From: Bill Frantz <frantz(a)netcom.com> >Subject: Re: Defeating MITM with Eric's Secure Phone >Cc: cryptography(a)c2.net, cypherpunks(a)Algebra.COM I wrote (and Bill commented on): >> 1. Exchange PGP-encrypted e-mail establishing a set of >> sixteen different words, labeled for 0..f in each direction. >> Thus: >> >> 0. Dilbert 1. Alpha 2. Cable 3. Swordsman ... f. Marxist >> >> Now, the checksum reading is very hard to spoof. Suppose I >> get 0x33f. I say ``My checksum is Swordsman Swordsman >> Marxist, or 33f.'' Bill responded with some nice reasoning: >Assume that the contents of the paper are secret between >Alice and Bob. When Alice calls Bob, she reads the word >coresponding to the first digit of the checksum. Either >Mallory is in the middle or he isn't. If he isn't, no >problem. The word list remains secure. >If he is in the middle, he has 15 chances in 16 of being >caught on the first exchange. He only survives if the first >digit of the Alice-Mallory connection is the same as the >first digit of the Mallory-Bob connection. He now knows the >word for one value and can continue to play 1 out of 16 >times. This is *almost* right. We need to add one more thing, though: 1. Alice calls Mallory, thinking she's calling Bob. She reads the first three digits to him. He makes the connection fall apart. At the same time, Mallory calls Bob, pretending to be Alice, and causes the connection to fall apart at the same time. 2. Alice calls Bob again, re-establishes their connection, and talks to him. Both seem to have had the same thing happen, so it's believeable that it was just noise on the line. (Where I am, this isn't so uncommon that it would imply an active attack.) 3. Mallory now knows three of these words in the dictionary. He lies low for the next few calls before trying the same trick again, until he learns most or all the dictionary entries. This implies a couple of things: First, Alice and Bob ought to be suspiscious of line noise that conveniently clobbers them during reading of checksums. Second, Alice and Bob shouldn't keep the same 16-word dictionary forever. If they change it once a week, this may be enough to make the attack I describe above unworkable. Note that this all works only when the phones/dictionaries are used only by single users. I also made a poorly-thought-through comment about using 6-digit hex secrets, and adding or XORing them into the checksums. This is vulnerable to a trivial attack, of course. The thing is, this doesn't need to be as complex or cryptographically secure as a hash function or MAC, because of the way it's used. We can probably also expect one-day-only keys for this application. I can think of dozens of things that *ought* to work here, and still be strong enough to resist the limited possible attacks, but I can't seem to convince myself of the security of any that are simple enough to use with a calculator. If I settled on one, it would be New checksum = (((old checksum * C0) mod P)+ C1) mod 2^{64}. where P is a random 64-bit prime, C0 is a random 64-bit number between 0 and P-1 inclusive, and C1 is a random 64-bit number. If P,C0, and C1 are all unknown, I *think* that's secure. An attacker given the high-order half of this doesn't seem to have the information needed to guess its low-order half on a different checksum, nor to reliably learn the value of P. This is essentially the IBC-Hash message authentication code, which is provably secure if the key is used once. I can't see a way that this could be attacked in this application, given one-time use of the keys. Can anyone else? (I may be missing something obvious again.) >BTW - I really like John's idea of doing another exchange >later in the conversation. Perhaps something like, "You >know, I was dancing the Foxtrot with my wife 9 days ago at >5AM." I wish I could claim this, but it's been around for a while. Didn't some of the PGPphone people come up with this idea? (Or was it users of older, government-issued secure phones?) >Bill Frantz | Internal surveillance | Periwinkle -- Consulting >(408)356-8506 | helped make the USSR the | 16345 Englewood Ave. >frantz(a)netcom.com | nation it is today. | Los Gatos, CA 95032, USA --John Kelsey, Counterpane Systems, kelsey(a)counterpane.com PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBND8+LUHx57Ag8goBAQHgCAQA1a6JjY0CMymvvXkWC8L8xOkyy2oosmQU rJAGtN9pYOdv+fyxSwEu4Mh03jjbcmQ1YBKkkD5CVfrhIYN93FGMZq9tVT+hIVCE 04/ki48Os1AitU/vZI94GlJlajhssSPy0R9fcPbFtR96KAw8csuFICtX2quwBK6a +SkkfLZgaKc= =vGOh -----END PGP SIGNATURE----- --John Kelsey, Counterpane Systems, kelsey(a)counterpane.com PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36

2 1

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