December 2003 - cypherpunks-legacy

Re: Stronghold
by John Young 17 Dec '03

17 Dec '03

Dimitri wrote: >Give me your fax # and and I'll fax it to you. Ask c2Net to verify >whether it's authentic. Okay. That's a deal. Send it under the river, and I'll put it on our site. Fax: 212-799-4003. Don't give up if it's busy, the line's also used for losing bets. My credibility went south years ago, sent packing by disbelieving housemates and offspring. Inflated baby jesus loves me, though. John

1 0

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

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

James A. Michner [non-crypto]
by Jim Choate 17 Dec '03

17 Dec '03

Hi, 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. ____________________________________________________________________ | | | The financial policy of the welfare state requires that there | | be no way for the owners of wealth to protect themselves. | | | | -Alan Greenspan- | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http:// www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

2 1

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

17 Dec '03

1 0

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

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

Re: Encryption Program
by semprini＠theschool.com 17 Dec '03

17 Dec '03

Hello. I just posted an encryption program on the web. It uses a key- generated pseudorandom stream of characters that get XORed with the plaintext to produce the cyphertext. For decryption, the same stream is run against the cyphertext. (Such is the nature of the XOR operation.) You can download the program at: http://www.brigadoon.com/~semprini/3dmx I am interested in other people's views, comments, questions, etc. on this program. Any questions, comments, etc. can be sent to me at "semprini(a)theschool.com". Thanks, Dylan

2 1

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