December 2003 - cypherpunks-legacy

Secure HTTP/Mosaic
by VACCINIA＠UNCVX1.OIT.UNC.EDU 17 Dec '03

17 Dec '03

This is the info I got back after inquiring about S-HTTP from EIT/NCSA, skip the press release at the end if you have already seen it. I note, that PGP is one of the cryptographic message formats supported. Cool. Vaccinia(a)uncvx1.oit.unc.edu Thank you for your inquiry regarding Secure HTTP. This message provides some details on the protocol and the status of its implementation. The April 12th joint EIT/NCSA/RSA press release regarding Secure Mosaic is included at the end of the message. OVERVIEW OF S-HTTP We have developed a new protocol for dealing with a wide range of cryptographic modes and algorithms in the context of the World-Wide Web, based on the Web's existing HyperText Transfer Protocol (HTTP). We call this protocol "Secure HTTP" or "S-HTTP". This protocol has been designed to enable incorporation of various cryptographic message format standards into Web clients and servers, including, but not limited to PKCS-7, PEM, and PGP. S-HTTP supports interoperation among a variety of implementations, and is backwards compatible with HTTP. S-HTTP aware clients can talk to S-HTTP oblivious servers and vice-versa, although such transactions obviously would not use S-HTTP security features. IMPLEMENTATIONS AND LICENSING EIT will make available freely usable source code for implementing S-HTTP in both clients and servers. These reference implementations of "Secure NCSA Mosaic" and "Secure NCSA HTTPD" will support two crypto engine implementations: via an integrated TIPEM library (offering PKCS-7 support) and via an "outboard" RIPEM application. RSA has agreed to permit the distribution of their TIPEM library, in binary form, without charge in conjunction with the non-commercial distribution of NCSA Mosaic. Implementors of non-commercial clients or servers may wish to use the already available RIPEM system (which is itself based on RSA's RSAREF library). Commercial implementors or distributors of WWW clients and servers are encouraged to pursue licencing arrangements with RSA or their licencees. FEATURES OF S-HTTP S-HTTP does not require client-side public key certificates (or public keys), supporting a symmetric session key operation mode. This is significant because it means that secure, spontaneous transactions can occur without requiring individual users to have an established public key. While S-HTTP will be able to take advantage of a ubiquitious certification infrastructure, its deployment does not require it. S-HTTP supports end-to-end secure transactions, in contrast with current usage of the existing HTTP authorization protocol which requires the client to attempt access and be denied before the security mechanism is employed. Clients may be "primed" to initiate a secure transaction (typically using information supplied in an HTML anchor); this is used to support encryption of fill-out forms, for example. In S-HTTP, no sensitive data need ever be sent over the network in the clear. S-HTTP provides full flexibility of cryptographic algorithms, modes and parameters. Option negotiation is used to allow clients and servers to agree on transaction modes (should the the request be signed? encrypted? both? what about the reply?); cryptographic algorithms (RSA vs. DSA for signing, DES vs. RC4 for encrypting, etc.); and certificate selection (please sign with your "Mastercard certificate"). ABOUT PKCS-7 PKCS-7 is a cryptographic message syntax standard developed by a consortium of companies lead by RSA. PKCS-7 is compatible with the Internet standards for Privacy Enhanced Mail (PEM) in that signed-data and signed-and-enveloped-data content, constructed in a PEM-compatible mode, can be converted into PEM messages without any cryptographic operations. PEM messages can similarly be converted into the PKCS-7 signed-data and signed-and-enveloped-data content types. In other words, PKCS-7 and PEM implementations can interoperate. PKCS-7 has the following advantages: a) PKCS-7 permits transport of 8-bit data (contrast with PEM, which requires Base-64 encoding). b) PKCS-7 can have a signature-less mode of operation. This permits secure messages to be sent from senders who do not have RSA key pairs. Signature is mandatory under PEM. c) PKCS-7 permits more flexibility in certificate format and trust models. d) PKCS-7 is explicitly designed for algorithmic flexibility. New cryptosystems, message digest algorithms and signature schemes can be added just by defining new types. SCHEDULE An "alpha quality" implementation of Secure Mosaic and HTTPD was demonstrated in public on April 12th. The protocol document is to be sent for external review (to RSA, NCSA and TIS) at the end of April. After revision, we plan to submit it as an "experimental protocol" RFC -- by late May, we expect. The reference implementation will be supplied to beta testers (to the protocol reviewers, and selected CommerceNet sponsors). Public release (to CommerceNet participants) is scheduled for September. CommerceNet will operate a certification authority, suitable for operators of S-HTTP servers (open to CommerceNet participants), beginning at that time. We expect that NCSA will make the reference implementation available to the Internet community soon after. Periodic progress reports will be reported to Internet mailing lists (such as PEM-DEV), and available on the EIT and CommerceNet Web servers (URL's http://www.commerce.net/ and http://www.eit.com/) ORIGINAL PRESS RELEASE Secure NCSA Mosaic Establishes Necessary Framework for Electronic Commerce on the Internet PALO ALTO, Calif., April 12, 1994 -- Enterprise Integration Technologies (EIT), the National Center for Supercomputing Applications (NCSA) at the University of Illinois and RSA Data Security today announced agreements to jointly develop and distribute a secure version of NCSA Mosaic, the popular point-and-click interface that enables easy access to thousands of multimedia information services on the Internet. The announcement was made in conjunction with the launch of CommerceNet, a large-scale market trial of electronic commerce on the Internet. Under the agreements, EIT will integrate its Secure-HTTP software with public key cryptography from RSA into NCSA Mosaic Clients and World Wide Web (WWW) servers. WWW is a general-purpose architecture for information retrieval comprised of thousands of computers and servers that is available to anyone on Internet. The enhancements will then be made available to NCSA for widespread public distribution and commercial licensing. Jay M. Tenenbaum, chief executive officer of EIT, believes secure NCSA Mosaic will help unleash the commercial potential of the Internet by enabling buyers and sellers to meet spontaneously and transact business. "While NCSA Mosaic makes it possible to browse multimedia catalogs, view product videos, and fill out order forms, there is currently no commercially safe way to consummate a sale," said Tenenbaum. "With public key cryptography, however, one can authenticate the identity of trading partners so that access to sensitive information can be properly accounted for." This secure version of NCSA Mosaic allows users to affix digital signatures which cannot be repudiated and time stamps to contracts so that they become legally binding and auditable. In addition, sensitive information such as credit card numbers and bid amounts can be securely exchanged under encryption. Together, these capabilities provide the foundation for a broad range of financial services, including the network equivalents of credit and debit cards, letters of credit and checks. In short, such secure WWW software enables all users to safely transact day-to-day business involving even their most valuable information on the Internet. According to Joseph Hardin, director of the NCSA group that developed NCSA Mosaic, over 50,000 copies of the interface software are being downloaded monthly from NCSA's public server -- with over 300,000 copies to date. Moreover, five companies have signed license agreements with NCSA and announced plans to release commercial products based on NCSA Mosaic. "This large and rapidly growing installed base represents a vast, untapped marketplace," says Hardin. The availability of a secure version of NCSA Mosaic establishes a valid framework for companies to immediately begin large-scale commerce on the Internet." Jim Bidzos, president of RSA, sees the agreement as the beginning of a new era in electronic commerce, where companies routinely transact business over public networks. "RSA is proud to provide the enabling public key software technology and will make it available on a royalty-free basis for inclusion in NCSA's public distribution of NCSA Mosaic," said Bidzos. RSA and EIT will work together to develop attractive licensing programs for commercial use of public key technology in WWW servers." At the CommerceNet launch, Allan M. Schiffman, chief technical officer of EIT, demonstrated a working prototype of secure NCSA Mosaic, along with a companion product that provides for a secure WWW server. The prototype was implemented using RSA's TIPEM toolkit. "In integrating public key cryptography into NCSA Mosaic, we took great pains to hide the intricacies and preserve the simplicity and intuitive nature of NCSA Mosaic," explained Schiffman. Any user that is familiar with NCSA Mosaic should be able to understand and use the software's new security features. Immediately to the left of NCSA's familiar spinning globe icon, a second icon has been inserted that is designed to resemble a piece of yellow paper. When a document is signed, a red seal appears at the bottom of the paper, which the user can click on to see the public key certificates of the signer and issuing agencies. When an arriving document is encrypted, the paper folds into a closed envelope, signifying that its information is hidden from prying eyes. When the user fills out a form containing sensitive information, there is a 'secure send' button that will encrypt it prior to transmission. Distribution of Public Keys To effectively employ public-key cryptography, an infrastructure must be created to certify and standardize the usage of public key certificates. CommerceNet will certify public keys on behalf of member companies, and will also authorize third parties such as banks, public agencies, industry consortia to issue keys. Such keys will often serve as credentials, for example, identifying someone as a customer of a bank, with a guaranteed credit line. Significantly, all of the transactions involved in doing routine purchases from a catalog can be accomplished without requiring buyers to obtain public keys. Using only the server's public key, the buyer can authenticate the identity of the seller, and transmit credit card information securely by encrypting it under the seller's public key. Because there are far fewer servers than clients, public key administration issues are greatly simplified. Easy Access to Strong Security To successfully combine simplicity of operation and key administration functions with a high level of security that can be accessible to even non-sophisticated users, significant changes were necessary for existing WWW security protocols. EIT developed a new protocol called Secure-HTTP for dealing with a full range of modern cryptographic algorithms and systems in the Web. Secure-HTTP enables incorporation of a variety of cryptographic standards, including, but not limited to, RSA's PKCS-7, and Internet Privacy Enhanced Mail (PEM), and supports maximal interoperation between clients and servers using different cryptographic algorithms. Cryptosystem and signature system interoperation is particularly useful between U.S. residents and non-U.S. residents, where the non-U.S. residents may have to use weaker 40-bit keys in conjunction with RSA's RC2 (TM) and RC4 (TM) variable keysize ciphers. EIT intends to publish Secure-HTTP as an Internet standard, and work with others in the WWW community to create a standard that will encourage using the Web for a wide variety of commercial transactions. Availability EIT will make Secure NCSA Mosaic software available at no charge to CommerceNet members in September and NCSA will incorporate these secure features in future NCSA Mosaic releases. Enterprise Integration Technologies Corp., of Palo Alto, Calif., (EIT) is an R&D and consulting organization, developing software and services that help companies do business on the Internet. EIT is also project manager of CommerceNet. The National Center for Supercomputer Applications (NCSA), developer of the Mosaic hypermedia browser based at the University of Illinois in Champaign, Ill., is pursuing a wide variety of software projects aimed at making the Internet more useful and easier to use. RSA Data Security, Inc., Redwood City, Calif., invented Public Key Cryptography and performs basic research and development in the cryptographic sciences. RSA markets software that facilitates the integration of their technology into applications. Information on Secure NCSA Mosaic can be obtained by sending e-mail to shttp-info(a)eit.com. Press Contact: Nancy Teater Hamilton Communications Phone: (415) 321-0252 Fax: (415) 327-4660 Internet: nrt(a)hamilton.com

1 0

Talk on privacy this weekend in Boulder
by nates＠netcom.com 17 Dec '03

17 Dec '03

I caught this one and though there might be some takers... ------------------------------------------------------------------------ Date: Fri, 15 Apr 1994 11:37:39 +22305931 (MDT) From: Virnoche Mary <virnoche(a)taweret.Colorado.EDU> To: Tim Schoechle <schoechl(a)ucsu.Colorado.EDU> Subject: Privacy Program/Please forward to anyone interested The 18th Regional Conference on the History and Philosophy of Science PRIVACY AND NEW INFORMATION TECHNOLOGIES April 21 - 23, 1994 University of Colorado at Boulder Hale Science Building Thursday _____________________________________________________________ April 21 7:00 - 9:00 p.m. Images in Popular Culture I: "The Conversation" Hale 270 Feature film with Gene Hackman, John Cazale, Cindy Williams, Teri Garr, Harrison Ford and Robert Duvall Friday _________________________________________________________________ April 22 2:30 - 4:00 p.m. Welcome: Dean Charles R. Middleton Hale 230 Arts and Sciences Keynote Windows into the Soul: Privacy in Address: an Age of High Technology Dr. Gary T. Marx University of Colorado, Sociology 4:00 - 5:30 p.m. Session I Libraries, Privacy, and Hale 230 New Information Technology Panelists: David Fagerstrom Science Library "Security and Database Searches" Debbie Hollis Government Documents "Altering Government Text" Scott Seaman Circulation "Circulation and Patron Confidentiality" Moderator: Jen Owen University of Colorado, Sociology 5:30 - 7:00 p.m. Dinner Break 7:00 - 8:45 p.m. Images in Popular Culture II: "Sliver" Hale 270 Feature film with Sharon Stone, William Baldwin, and Tom Berenger 8:45 - 9:45 p.m. Refreshments and Discussion of films Hale 270 Discussion Leader: Charlotte Kunkel University of Colorado, Sociology Saturday ________________________________________________________________ April 23 9:00 - 9:55 a.m. Session II Medical Records: Hale 270 Are They Really Private? Speaker: Sheri Alpert George Mason University, Public Policy Discussants: Linda Fox, J.D. Associate Counsel, Eleanor Roosevelt Institute Mary Virnoche University of Colorado, Sociology Moderator: Mary Cornell, RRA President,Colorado Health Information Management Association 10:00 - 10:55 a.m. Session III Coming Soon Hale 270 to a Society Near You? Panelists: Tim Schoechle University of Colorado, Telecommunications "Smart Homes" Dave Hunter President, BI Inc. "Electronic Location Monitoring" Professor Omar K. Moore Responsive Environment Foundation Inc. "Interactive Multi-Dimensional Technologies" Don Eberle, J.D. Attorney in private practice 11:00 - 12:15 p.m. Session IV Newer Media Technologies, Hale 270 Privacy, and Media Practitioners Speaker: Professor Jerome Aumente Rutgers University Journalism Resources Institute Discussants: Professor Michael Tracey University of Colorado Journalism and Mass Communication Roger Fidler Knight-Ridder Director of New Media and the Information Design Lab Martin Taschdjian US West Moderator: Professor Brenda J. Allen University of Colorado, Communications 12:15 - 1:30 p.m. Lunch 1:30 - 2:45 p.m. Session V Electronic Media and the Hale 270 Transformation of Law Speaker: Professor Ethan Katsh University of Amherst Discussants: Professor Michael Strine University of Colorado, Political Science Professor Barbara Bintliff, J.D. University of Colorado Law Library Director Moderator: Professor Cal Jillson University of Colorado, Political Science 2:45 - 4:00 p.m. Session VI Cryptography and the Clipper Chip Hale 270 Speaker: Dr. Dorothy Denning Georgetown, Computer Science Discussants: Ken Klingenstein Director, Computer Network Services University of Colorado Phil Zimmerman Software Consultant, Boulder Moderator: Dr. William Moninger National Oceanic and Atmospheric Administration (NOAA) 4:15 - 5:30 p.m. Session VII What is to be Done? Hale 270 Reflections from the Front Line. Marc Rotenberg, J.D. Computer Professionals for Social Responsibility (CPSR) Former counsel to the Senate Judiciary, Washington, D.C. Discussants: Professor Robert Trager University of Colorado Journalism and Mass Communication Sandra McCray, J.D., L.L.M. University of Colorado, Telecommunications Moderator: Scott Allman University of Colorado, Philosophy Sponsors: The Department of Sociology and its Center for the Social Study of Information Technology, The School of Journalism and Mass Communication, The Keller Center for the Study of the First Amendment, The Telecommunications Interdisciplinary Program Committee, and the Center for Values and Social Policy. Contacts: Professor Gary T. Marx Mary Virnoche Department of Sociology Department of Sociology 492-6427 492-3312 ------------------------------------------------------------------------ -nate -- +--------- | Nate Sammons <nates(a)netcom.com> PGP Key and fingerprint via finger. | Clipper == Big Brother Inside. Question Authority. Encrypt everything. +---------

1 0

Re: Warrantless searches -- A sign of things to come?
by f_griffith＠ccsvax.sfasu.edu 17 Dec '03

17 Dec '03

> >The easiest solution is to include a provision in the rental agreement >stating that you won't possess firearms in the apartment. In addition, >include a provision that indicates that the tenant wil consent to any >search requested by the landlord. You could even make these provision >optional, such that any tenant can decline to agree to them by checking >the appropriate box. > >(Most tenants in such projects probably won't bother to read them anyway). > I thought the administration had backed off the original proposal because of the uproar and had gone to the search waiver provision in the rental agreement (don't know if they included the firearms part). It appears that we're still at a point where enough protest from the informed part of the populace can have an effect.

1 0

re: Sgt Russell
by lefty＠apple.com 17 Dec '03

17 Dec '03

> I am sorry that my being on this list is offensive to you. I joined >this list to learn about cryptography. If anything, I would think that you >would want to help a new person get up to speed. If you can't grow up and >treat other people like human beings, maybe you ought to take yourself off of >the list and go play with your private key by yourself. I wouldn't worry about Wayne: other than an annoying propensity to toss around TLAs in such a way as to make it fairly clear that he doesn't really know what he's talking about, and a strong case of inappropriate paranoia, I suspect he's generally harmless. Annoying, tedious and occasionally laughable; but generally harmless. -- Lefty (lefty(a)apple.com) C:.M:.C:., D:.O:.D:.

2 1

re: Intolerance on the list (was Re: Sgt Russell)
by SGT=DARREN=S.=HARLOW%ISB%MCTSSA＠nwsfallbrook3.nwac.sea06.navy.mil 17 Dec '03

17 Dec '03

Forwarded to: inet[cypherpunks%toad.com(a)pucc.princeton.edu] cc: Comments by: SGT DARREN S. HARLOW@ISB@MCTSSA -------------------------- [Original Message] ------------------------- Russell, I appreciate your letter to me. My political views are very conservative. I know that this puts off a number of people, but we are each entitled to our own opinion. I feel that we do need a government in power, but that they have a limited role in our society. If we didn't have at some ruling power in control, the country would be in total anarchy and we would be taken over by some intolerate country. The beauty of our system of government protects our rights. We need a military to protect everyone's ass in this country. I feel that the government infringes to much on other peoples rights in this country as it is, especially with the current president. At least with a conservative government in control, they want to keep the money and the power in the hands of the people. The use of cryptography within our system, IMHO, is to allow us a right to privacy. Personally I feel that the Clipper chip, is a severe infringement upon our rights, and I do NOT support its use. Notice that I use PGP and not PEM or DES. If someone is smart enough to use RSA, then they deserve to be able to talk in privacy. I know that it can be used for alterior motives, but that is the risk with any tool that is available for use. I hope this helps to explain my opinions a bit better. I welcome you comments. BTW, where are those political pieces that people have written. I would like to look at them, to further educate myself. Sgt Darren Harlow - Computer Security MCTSSA, Camp Pendleton, USMC Internet: harlow%isb%mctssa(a)nwsfallbrook3.nwac.sea06.navy.mil or another less reliable & slower: harlow(a)mqg1.usmc.mil Voice: Comm: (619) 725-2970 DSN (Autovon): 365-2970 Fax: Comm: (619) 725-9512 DSN (Autovon): 365-9512 PGP Public key available upon request "The views expressed are my own, and always will be..."

1 0

Re: Press Release on Secure NCSA Mosiac
by hfinney＠shell.portal.com 17 Dec '03

17 Dec '03

> This secure version of NCSA Mosaic allows users to affix digital signatures > which cannot be repudiated and time stamps to contracts so that they become > legally binding and auditable. In addition, sensitive information such as > credit card numbers and bid amounts can be securely exchanged under > encryption. Together, these capabilities provide the foundation for a broad > range of financial services, including the network equivalents of credit and > debit cards, letters of credit and checks. I doubt that these electronic financial instruments will be designed to offer new protections to individual privacy. As more commerce moves onto the net, opportunities for database linking will multiply drastically. In such an environment, electronic dossiers of buying and spending habits will be far easier to develop. > To effectively employ public-key cryptography, an infrastructure must be > created to certify and standardize the usage of public key certificates. > CommerceNet will certify public keys on behalf of member companies, and will > also authorize third parties such as banks, public agencies and industry > consortia to issue keys. So once again we have the command-and-control style key certificate hierarchy. Everyone is neatly ordered and positioned in the structure. A place for everyone and everyone in his place. > Such keys will often serve as credentials, for > example, identifying someone as a customer of a bank, with a guaranteed > credit line. I suppose it goes without saying that the kinds of privacy-protecting credentials we have been discussing are not what is being discussed here. Rather, we have more authentication, more registration, more tracking of every electronic financial move we make. > Significantly, all of the transactions involved in doing routine purchases > from a catalog can be accomplished without requiring buyers to obtain public > keys. Using only the server's public key, the buyer can authenticate the > identity of the seller, and transmit credit card information securely by > encrypting it under the seller's public key. Because there are fewer servers > than clients, public key administration issues are greatly simplified. Evidently the "commerce" that is being planned here does not anticipate much demand for encryption of messages from sellers to buyers; rather, the important thing is encryption in the opposite direction to protect those credit card numbers. This also, of course, limits RSA's financial commitment in making its technology available; my reading is that end-users get only the ability to validate signatures for free, and that getting to use their own keys will involve royalty payments. > Secure-HTTP enables incorporation of a variety of cryptographic standards, > including, but not limited to, RSA's PKCS-7, and Internet Privacy Enhanced > Mail (PEM), and supports maximal interoperation between clients and servers > using different cryptographic algorithms. I was pleased to see that in their later message they added support for PGP to this list, although it seems that they are still thinking mostly in terms of "officially sanctioned" systems: > Cryptosystem and signature system > interoperation is particularly useful between U.S. residents and non-U.S. > residents, where the non-U.S. residents may have to use weaker 40-bit keys in > conjunction with RSA's RC2 and RC4 variable keysize ciphers. This is outrageous! Where on earth did they get the idea that non-U.S. residents have access only to 40 bit keys and RC2/RC4? As though the only encryption the rest of the world has is whatever the U.S. government deigns to let cross its borders? What an insult to the rest of the world. And what an attempt at self-deception to pretend that these export controls are effective. I sincerely doubt that the international network community will accept such a limitation in what claims to be an international standard. The one good thing that may come from this initiative is that more people will be using and relying on encryption. Given the widespread skepticism about the government in this country, it will be that much harder to get a Clipper-like program into place. But the initiative does clearly show the pernicious effects of the combined restrictions of the RSA patents and the NSA export controls. Together [RN]SA provides a structured, ordered system which provides the minimal possible privacy necessary for electronic commerce. Far more is possible, but is un- likely under the current legal regime. Hal

1 0

CRYPTO: Money laundering and traceability
by hfinney＠shell.portal.com 17 Dec '03

17 Dec '03

(In honor of the Extropians list discussion elsewhere in this thread I include an Extropians-style message prefix.) An issue related to money laundering is money traceability. I posted something on this a couple of weeks ago but I have a little more information now. We are inclined to believe that with cryptographically anonymous digital cash, "money laundering" will be trivial. A simply sends the cash to B, and there is no way for the bank or anyone else to link the two together. While this is basically true with existing digital cash proposals, there is one kind of linkage that is possible. A knows and can recognize the cash which B holds. A and the bank could cooperate so that if B goes to the bank to deposit his cash (or deposits it electronically into an account linked to his True Name), B's anonymity can be broken. This has good aspects and bad aspects. On the good side, it should make robbery and extortion harder. If you are forced at gunpoint to enter your PIN into your cash smartcard, transferring cash to the robber's "electronic purse" (love that name), then later you can call the bank and report the numbers of the stolen cash. When the robber tries to deposit it, he can be caught. Similarly, this could be a boon to law enforcement "sting" operations. When the feds pay off the anonymous assassin-for-hire or kidnapper, and he goes to deposit the cash, again he can be caught. The other side of the coin, though, is that despotic governments can use these tools to control and restrict what their people can do. If the revolutionaries try to use cryptography to isolate and protect each cell from the others, traceable cryptocash may expose them. Keith Henson posted the start of an interesting story he was writing last year, about some eco-activists using cryptography for protection as they worked to sabotage some polluter. This kind of dramatic scenario might become less possible with traceable cash. (It's possible that some banks would allow truly anonymous accounts, so that even if the cash were recognized as it was turned in, the robber would not be caught. Still, the bank could refuse to honor the money in this case, preventing the criminal from profiting by his misdeeds.) The new information I mentioned comes from a paper by David Chaum in the Eurocrypt 92 proceedings: "Transferred Cash Grows in Size," by Chaum and Torben Pryds Pederson. Chaum considers off-line cash systems where the money does not necessarily have to be returned to the bank after each transaction. His main conclusion is, as the title suggests, that the cash must grow in size at each step. But a secondary conclusion is that under the right circumstances a payor can always recognize his cash at a later point, even after it has passed through many hands. Chaum describes these circumstances as the case where the payor has infinite computing power, but it appears that the same effect would be possible if the bank cooperated with the payor, as would be likely in the kinds of cases I mentioned earlier. The fundamental problem is the impossibility of having the cash be "re-blinded" as it passes from Alice to Bob (after it was "blinded" as Alice withdrew it from the bank). If this kind of multiple blinding were possible, so that neither Alice nor the Bank could recognize the money that Bob holds, multiple-spending could not be detected. Chaum's arguments appear to apply to virtually any electronic cash system which can prevent double-spending. They suggest that traceable cash will be the rule in any digicash system. People planning their future lives of crime under the new regime will need to take this into account. Hal

2 1

Another invasion of privacy
by Mike Markley 17 Dec '03

17 Dec '03

There was an AP story yesterday about how several states are using prisoners to input data about traffic accidents and such into databases. I believe the state that they focused on was Arkansas. An attorney received a phone call that his SSN was being sold by prisoners that had gotten it from an accident report. The state allows people to use their SSN as their drivers license number. This prisoners also have access to everything else on the report, your license number, your home address and potentially your work and home phone number. Does anybody know what other states are using prisoners for this type of work? I'm about ready to cut up all my credit cards and start paying cash for everything that I buy. Mike. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mike Markley || The opinions here do not represent the mmarkley(a)microsoft.com || opinions of my employer. Attempts to || associate the two are pointless. "I want to look at life, In the available light" - Neil Peart -

1 0

Re: Laundering money through commodity futures
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

One problem with using bet-doubling systems to pay bribes with, whether it's in the futures market or in the casino, is that you not only have to convince the bribee to accept the bribe and participate in a money-laundering process, you have to get him to be willing to accept a few powers of two losses before receiving the bribe. If the bribe is small relative to the liquidity of the bribee, that's fine, as long as you've got enough trust between you that the bribee isn't worried about you walking away when you've won n*2**4 and she's lost it. But if you're trying to bribe, say, an enterprising southern lawyer whose husband's a politician, with a high fraction of her net worth, she's *not* going to be in a position to cover your bets for n*16 even if she *does* trust you. On the other hand, finding an enterprising broker to switch owners of futures contracts for a small extra commission may not be so hard.

1 0

Re: BEST Inc.
by GERSTEIN＠SCSUD.CTSTATEU.EDU 17 Dec '03

17 Dec '03

-------------- On Tue, 19 Apr 1994 04:15:01 Thomas Riggley <jester(a)grex.cyberspace.org> wrote: >On Mon, 18 Apr 1994, Jeremy Cooper wrote: > >> > >> > I was in a BEST store yesterday, and attempted to pay by check. They >> > asked for ID to verify the check and when I handed them my military ID, they >> > asked for my driver's license instead. I gave them my driver's license and >> > they used it and the magnetic strip on the back of it to verify my check. I >> >> [stuff deleted] >> >> >From what I know, there is no law that says you have to keep that >> magnetic strip up to date. Just have a little meeting between it and Mr. >> Refridgerator magnet and you could end up with some surprising results. > > Is this true? I am a NY state resident. I am under the impression that >altering either the bar code or the mag strip on the back of my license >would be as illegal as say changing the picture (Not that this is possible >in with the new NY licenses). I do not know the legality behind this but >I am aware that altering a license in ANYWAY is illegal. Although what >you are suggesting is VERY difficult to prove, it is still I would think >illegal. Unless anyone has any legal information to the contrary.... > > I would also guess that these states that have the mag strips on >their license also have fines for non-oprative strips. If they do not, I >am sure the law will be created so enough! > -Tom For what it's worth, you can de-magnetize anything you want just by going to the store. I work at a pharmacy, and they have "inventory control tags" on some of the "hotter" items. When someone wants to buy one of these items, we put the tag (actually just a magnetized strip) on a special pad that demagnetizes it (and ATM and credit cards that are put on it too :)) Also, since I live on a university campus in New Haven, security is a big thing here. We now must use ADT keycards as well as physical keys to get into the buildings. The first semester they were used, I blitzed three of them just by carying it with me all the time. We never found the reason, but I think it has something to do with the fact that I'm around computers all day. (Incidentally, there were reports of peoples credit cards being wiped by these things as well as them setting off theft detectors at record stores). Just another 0.02¢ for the pot..... adam "After this, nothing will shock me." ---------- "In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two-thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it." - Philip Elmer-Dewitt, "Who Should Keep the Keys", TIME, Mar. 4, 1994

1 0

Key Servers
by fhalper＠pilot.njin.net 17 Dec '03

17 Dec '03

Does anyone have a current list of Key Servers. I have tried several and all are either "temporarily" shut down or it is an unknown address. I just need an address for one. Thanks, Reuben Halper Montclair High -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQCPAi16KosAAAEEAMUwRni4a9+GbuAhHDLcBWK60hCJUYxhr2hYokpELAhx0ejp 2fq61Tu9Hjn051CN8Xy5nu6sv2ODfG/t59l4DJSb5pirQaII3zaX0rMX0ydwGDoW YakL4ow1lNY+d/k14KpIuUW404+fNuNhIGSkdVLQIfbOgh0preK7/P44AKvdABEB AAG0JlJldWJlbiBIYWxwZXIgPGZoYWxwZXJAcGlsb3Qubmppbi5uZXQ+iQCVAgUQ Lam+x9xF3PzIgw7tAQHPogP/VmoF5AHJNBFlpxl1tvHAzrMLE8nkpengs94Y8zmF 1r5+hk0TaYeEEUzYf1QNfflya5md3WKeXnI3WhO2SRpdH953AD/tNmxw2LLEegat 5sI1XNPuNqxeompiHFRnCz4dI14qjDvRwnPay187/Q5q2F3m0nP8qA6wgl59mDq3 FuCJAJUCBRAteitx4rv8/jgAq90BARTHBACh99OJtGXATm01BUa+u6WHU5CBc2FN F5z29RpTA/JTrgUhn4qeZ19iCIlhe1wi0D3QQH0wN7FrMp6onMw49KFU05/KLDLb JSWdCzjbl/wPEG8z//O6+Pqzj+ZcNM9Rm0b08/QdVoQZMljXkl19Gq2P/D4ceewe WAKePQ2ciFdNbw== =K4ez -----END PGP PUBLIC KEY BLOCK-----

1 0

Re: Sgt Russell
by tim werner 17 Dec '03

17 Dec '03

>Date: Tue, 19 Apr 1994 12:29:25 -0400 >From: "Perry E. Metzger" <perry(a)snark.imsi.com> > >Strikingly, these people feel gravely insulted >when one points out the fact that their posts read like random text >generators driven off of markov chains, the statistics for which were >derived from bad xeroxes handed out by drooling individuals on the >streetcorner who rave about the aliens who are remote controlling us >through our shoelaces. It's not our shoelaces, it's invisible wires in our heads, that's how they put the thoughts there, they couldn't possibly be doing it through our shoelaces, get real. tw

1 0

Cypherpunks change bytes!
by greg＠ideath.goldenbear.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I ought to be studying, but goofing off is more fun. I generated a test key with the binary distribution of PGP 2.3a for DOS. I then changed the byte at offset 2F688 in PGP.EXE from 0x33 (ASCII "3") to 0x34 (ASCII "4"), and the byte at offset 2F689 from 0x61 (ASCII "a") to 0x00 (null). The patched PGP.EXE identifies itself as "Version 2.4" in ASCII armor blocks and otherwise; the key generated with the "2.3a" version extracts as a "2.4" key after the patch. ViaCrypt PGP 2.4 for DOS can successfully read files encrypted with the patched PGP.EXE, and add keys generated under "2.3a" but labelled as "2.4" keys. I haven't done a lot of testing, but spot checks make it look like everything's fine. I don't see the point in forcing everyone to patch their binaries or recompile from source - does anyone else? Bidzos & Co. are certainly smart enough to anticipate this step. What's the catch? -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLclzd33YhjZY3fMNAQGiDwP9HjSYfNfn4q/9L/BOqXluH06015x3YmDM gNPfg5T2lWcsYJyyx/tMnVWdtAnFENAFUB7zK5vNq+Y/tquKaE6kEuZeUzZz1o+k sOofUAR1Y+sUii4Fu8R2J7scNCDL2pjl/hIqAAfT0voHiexxOTR9uxCDeiWxz9w0 xpyuvJBLQq8= =G5Oq -----END PGP SIGNATURE-----

3 2

What the IRS is up to
by johnl＠iecc.com 17 Dec '03

17 Dec '03

Here's some excerpts from a speech by Coleta Brueck, Project Manager, Document Processing system, at the Internal Revenue Service, that she gave at the Computer Press Association Awards luncheon in New York on April 15th. I was at the lunch, but the transcript of the speech just arrived today. The ellipses are mine, but I think I'm not distorting what she said. She started by explaining that their current systems are functionally based on punch card systems from the 1950s, and they want to get more stuff on-line so that when you call with a question, the person at the IRS can retrieve a copy of your records while you're still on the phone. But then: "We should be able to provide you on-line access to that information. ... You will have the availability to know what your current account information is, very much like if most of us who have an American Express Card, you can call -- you don't really know where that 800 number goes, but what you do know is when that person answers your call, they have your complete account information. ... They can give you information on your account, they can update your account, or they can provide you futuristic looks into your account as to where you might be next year, even, for filing tax returns. We've often talked about, and this is the terminology that I used when I was in on a task group, we've talked about the "golden eagle" return. This is the golden -- or gold American Express Card return. At the end of each year, if you have an American Express Card, you get a gold account summary of what you've done for the year. ... Basically, what I say is that if I know what you've made during the year, if I know what your withholding is, if I know what your spending pattern is, I should be able to generate for you a tax return so that I only come to you and tell you, 'This is what I think you should file for the next year, and if you agree to that, then don't bother sending me a piece of paper.' ... But I am an excellent advocate of return-free filing. We know everything about you that we need to know. Your employer tells us everything about you that we need to know. Your activity records on your credit cards tell us everything about you that we need to know. Through interface with Social Security, with the DMV, with your banking institutions, we really have a lot of information, so why would you, at the end of the year or on April 15th, today, do we ask the post office to encumber themselves with massive numbers of people out there, picking up pieves of paper that you are required to file? ... We could literally file a return for you. This is the future that we'd like to go to." Lest there be any doubt, she was entirely serious, and she clearly expected that that we'd all think this is as wonderful as she does. Regards, John Levine, johnl(a)iecc.com, jlevine(a)delphi.com, 1037498(a)mcimail.com

1 0

Chill out.... was Re: Keyserver service outRAGE
by Pat Farrell 17 Dec '03

17 Dec '03

"Perry E. Metzger" <perry(a)snark.imsi.com> writes: > Rather than everyone freaking out about 2.5, why not just wait a few > hours until the FTP site is announced and look at the thing for > ourselves? > > Myself, I'm running on the assumption that this is a good thing, > because now PGP is completely legal in the U.S., and doubtless a PGP > thats legal overseas using a library compatible with RSAREF will > appear within days of release. Amen to this! Wait a week, and this might be a great thing. If not, keep using 2.3a. I know that Jim Bidzos was interested in having a "pgp compatible" program that started with rsaref and was legal and free. I know because I asked him about liscensing last spring. He pointed me to an effort that professor Jeffery Schiller (pgp key 0C4EE1 (jis@mit) on the usual servers) was coordinating. I exchanged a few messages with a student up there, then got lost in GMU work and lost track. I think the student did something else, like crack RSA-129. But there are lots of students at schools like MIT and GMU. I sure hope this can provide a cloud free PGP for broke students. Lets drop this thread for while, ok? Pat Pat Farrell Grad Student pfarrell(a)cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

2 1

MIT keyserver: don't panic...
by Mike Ingle 17 Dec '03

17 Dec '03

Take a look at pgformat.doc, which is included in the source or doc releases of pgp23a. Both the public key and signature packets have only a single-byte version number, which is always equal to 2. So there is no way to tell by looking at your key which minor version (2.xx) it was created by. You can tell which version was used to extract it to ascii armor by looking at the "Version: 2.xx" line in the ascii armored message. So get a text editor. Big deal. You will not have to regenerate your keys and get new signatures on them. If we have a no-doubts legal PGP, with source code, and free, that's good! If something sucks about it, PGP23a is not going to disappear. This can only be a positive development. As for why the keyserver crippling was imposed, RSA can lose its patent rights if it can't show in court that it made an effort to prevent its patents from being infringed. --- Mike

1 0

DefenseServices
by Peter Murphy 17 Dec '03

17 Dec '03

From: "Perry E. Metzger" <perry(a)snark.imsi.com> Sender: owner-cypherpunks(a)toad.com Precedence: bulk Status: R _______ MESSAGE BEGINS ___________ Jim Miller says: > Section #120.9 of the ITAR defines "Defense Service" as: > > (1) The furnishing of assistance (including training) to foreign > persons, whether in the United States or abroad in the design, > development, engineering, manufacture, production, assembly, testing, > repair, maintenance, modification, operation, demilitarization, > destruction, processing, or use of defense articles; or > (2) The furnishing to foreign persons of any technical data > controlled under this subchapter (see #120.10), whether in the United > States or abroad. This is sick. According to this, I cannot teach foreigners about cryptography in the U.S. -- even about the open literature. This is a grotesque denial of my first amendment rights. I wonder if I should hold an open enrollment cryptography class for the sake of civil disobediance. Perry ______ MESSAGE ENDS _________________________________________ That's interesting..... My cryptology lecturer seems to have an American Mid-West accent (not Canadian - I can generally tell), and seems to be commiting the "heinous" crime of teaching such matters to mainly Australian people. He seems to be on conference somewhere overseas. Well, I hope he doesn't get arrested if he crosses any U.S. border posts. It would certainly piss me off. (For one thing, it would fuck up my syllabus :-[.) Seriously, I don't think it is an offense to teach cryptology to non-NAFTA nationals. All of the stuff is non-classified, and he seems pretty aware of the legal issue of cryptology. That is, he wouldn't do anything that he could be nabbed for (discounting any warped interprepation of the legal statutes...;-( .) ======================================================= | Peter Murphy. <pkm(a)maths.uq.oz.au>. Department of | | Mathematics - University of Queensland, Australia. | ------------------------------------------------------- | "What will you do? What will you do? When a hundred | | thousand Morriseys come rushing over the hill?" | | - Mr. Floppy. | =======================================================

1 0

PGP.....
by lile＠netcom.com 17 Dec '03

17 Dec '03

The MBone session "Cyberstation:audio feed" is going to have Jeffrey Schiller talk about the new public PGP V2.5 release.... Cygnus has a mbone connection.... -lile ps. You can also see info at http://www.media.org/pgp.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lile Elam | "Remember... No matter where you go, there you are." lile(a)netcom.com | Un*x Admin / Artist | Buckaroo Banzai ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Marked_Money
by remailer＠merde.dis.org 17 Dec '03

17 Dec '03

Is there a way of marking digital coins, so the depositor can be identified?

3 2

MBone - where to get the software...
by lile＠netcom.com 17 Dec '03

17 Dec '03

Hi folks, You need to get software to see the MBone encapsulated packets. You will also need a tunnel to your site (and you might already have one). So where to get the software... I am looking for it on a ftp site but have not found it. Some of the program names are sd (for session director) vat wb ( for whiteboarding) nv Hey! I just heard from van Jacobson. He wrote alot of this software... >From van(a)ee.lbl.gov Thu May 5 18:12 PDT 1994 To: Lile.Elam@Eng (Lile Elam) Subject: Re: mbone software... Date: Thu, 05 May 94 18:13:30 PDT From: Van Jacobson <van(a)ee.lbl.gov> Content-Type: text Content-Length: 218 The audio (vat), whiteboard (wb) & session directory (sd) tools are on ftp.ee.lbl.gov in conferencing/{vat,wb,sd}/*. The most widely used video tool (nv) is available on parcftp.xerox.com in pub/net-research. - Van Cygnus has a tunnel and so does Sun. I wish I could help more. I am still awaiting the PGP - Jeff broadcast. -lile ps. If you do get it up, the session is "Cyberstation: audio feed" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lile Elam | "Remember... No matter where you go, there you are." lile(a)netcom.com | Un*x Admin / Artist | Buckaroo Banzai ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

The MBone talk....
by lile＠netcom.com 17 Dec '03

17 Dec '03

You are not going to beleave this, but I missed it!!!! Argh!!!!!!! I had run down the hall to tell someone about it and once we got it up (which was only a few minutes) Jeff had already spoken... I heard from Van that Jeff Schiller just read the text that the MIT legal gave him and that is the same text that is on the www.media.org web server... So, wonder why there is so much darkness about this release... Why can't they just be up front with what it is and what's goin on? hum......... -lile ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lile Elam | "Remember... No matter where you go, there you are." lile(a)netcom.com | Un*x Admin / Artist | Buckaroo Banzai ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

No Subject
by anonymous＠extropia.wimsey.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hello everyone! This is a preliminary document which I hope will stir discussion. I didn't write it in order to dictate rules to anyone, so please don't flame me. Hopefully the members of the list will supply lots of feedback! -Lady Ada - ---------------------------------------------------------- Introducting The Cypherpunk Standard For Encrypted Phones (CSEP) Purpose: Encryption software is a form of communication tool. Like other communication systems, it is useless without someone to talk to who shares the same protocol. It appears likely that various forms of encrypted phones will spring up in the near future, ranging from PC and SoundBlaster-based software to simple hardware phones. Now is the time for us to agree on protocols, so that all cypherpunk-built phones can talk to each other. Disclaimer: "But," you say, "Phil Z. is already working on VoicePGP. Why not wait until he releases it and let that be the standard?" Well, I'm not trying to undercut Phil, and I certainly hope that we will be incorporating his protocols into a future version. But I don't think we should let a single product drive all future design. Let's think about the future now. Isn't it better to hash out potential problems in a public forum? Basic Standard - -------------- - -- Diffie-Hellman for key exchange - -- Triple DES for data encryption - -- RSA for digital signatures/identity verification Rationale: Unlike encryption protocols designed for email, a phone system will need to exchange public keys bidirectonally at the beginning of every call, and the existance of an insecure two-directional link can be assumed. Diffie-Hellman is perfect for this application. The alternative, RSA, would require either generation of new keypairs at call time, which is very slow, or the long-term association of a keypair with a specific phone, which provides no benefit to the user and opens a possible path of attack (though not a major one) to eavesdroppers. Also, the patent on Diffie-Hellman expires in 1997, well before the 2000 expiration date of RSA. The information available to me appears to indicate that Triple DES is not significantly more vulnerable than IDEA or other popular algorithms, and it has the advantage of not being patented. I would like to see this standard keep possible future commercialization in mind. I suggest that the TDES implementation should use three different independent keys. IDEA might be offered as an option for those who prefer it. Compression - ----------- It's probably wise to standardize on a particular compression scheme. I have no opinions on this subject and welcome input. The most important feature is speed, not efficiency of compression. Other Features Required for Secure Phones - ----------------------------------------- Each phone shall have a button (hard or soft) which can be pressed by the caller at any time. Pressing it will cause a new TDES key to be generated and exchanged. [Should it generate a new n and g for D-H, or just create a new x and demand a new Y?] Paranoid users can press this button every few seconds if they wish. (In my humble opinion, even a single-DES phone is quite secure if it has this feature.) Other possible options - ---------------------- In some cases it may be desirable to confirm that the call recipient is really the person you wish to speak to. This could be implemented by allowing the phone to store RSA private keys (one for each user) and public keys (to test for other users). These signature keys should be independent of the encryption keys. The phone would require the user to enter a code [of what length?] which would act like the passphrase of PGP, preventing anyone from impersonating another user even if the would-be impersonator had access to the victim's key and phone. Control Codes - ------------- A number of control codes are needed for commands passing between the two phones. Not only the definitions of the codes but the values must be agreed upon by all users. Each of these will be associated with a defined packet that contains the appropriate data. GENNEWKEY [send x, request Y] DATA [send actual packet of data, request ACK] DATAACK [acknowledge data packet with checksum] - -------------------------------------------------------- OK, I admit it, this is pretty minimal, but hey, it's a beginning. Please send comments to the list. Phil Z, if you're out there reading this, I'd particularly like your input. -Lady Ada -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLclivqXNQdJx1hMZAQGq2wP/fcq5gp8unZhy/cog3jpdI8wA3hJORzME ul4qdnu5dOP7ON3LmlsWPeymUlagI1oUtJOUxb5LQ9lAlQMWv7u3TJDj3tqftcu3 il8fVmdIxrf8FYDbhs5GppCcfsMaz2/ervsw9cICspFPQJOKTOWzzTMuUYyoqcYa hWH/OJhMmPw= =coxy -----END PGP SIGNATURE-----

1 0

Anybody else see eye-to-eye with Connie Chung tonight?
by rjc＠gnu.ai.mit.edu 17 Dec '03

17 Dec '03

They had a segment on a "digital stalker" on Prodigy. Basically, a guy who kept getting anonymous Prodigy accounts with fake credit cards and then used the accounts to harass people almost like Detweiler. The reporter's attitude was disturbing however. His attitude almost seemed to be that Prodigy should read each and every private message to protect users from harassment. The whole segment is a foreshadow of how society will react when anonymous remailing becomes widespread. One more thing. The narrator seemed to imply that what we know as "flaming" should be controlled. For instance, the phrase "check your thorazine dosage" could be viewed as digital harrasment. It's a brave new world out there. Coming to your local cyberspace soon. -ray

2 1

List Deletion
by broitman＠koala.bu.edu 17 Dec '03

17 Dec '03

How does one get removed from this mailing list? Please respond privately...so not to clutter up the conf. -jZb

1 0

Re: Why Digital Cash is Not Being Used
by Blanc Weber 17 Dec '03

17 Dec '03

Just thinking: since it keeps being repeated that it is a mistake to think of digital cash as currency, rather than a mere transaction mechanism, then it should not be called "cash", as this does not describe what it is. Then it would not be so easy to think in those terms. Digital Exchange Digital Transactions Digital Transfers Digital Fungi (bility) Blanc

1 0