- cypherpunks-legacy - lists.cpunks.org

how do i do this with pgp?
by Erich von Hollander 17 Dec '03

17 Dec '03

i'm writing a lot of perl scripts that need to interact with pgp. however, i have not found an easy way of getting a passphrase to pgp from a script. i realize of course that this is for security; pgp only wants things typed in from a keyboard. however, there are plenty of times when automated processing is desired, and security of the key does not need to be perfect. in these cases, the only way (it seems to me) to get pgp to work is to setenv PGPPASS, which is really terrible security. is there a better way to do this? will there be some easier way in future versions of pgp, like being able to read the passphrase from stdin? e

2 1

Re: Warrantless searches -- A sign of things to come?
by Jim Sewell - KD4CKQ 17 Dec '03

17 Dec '03

<My computer told me that Evidence Inc. said:> > The easiest solution is to include a provision in the rental agreement [... that allows searches and agrees to no-firearms ...] > I'm not sure that all states would permit searches even under these > circumstances ... > Comments? Are there any lawyers that can comment with certainty? I'm not qualified to answer this point. (I did post since it was my original point that is being referred to. My opinion is that a landlord can not further limit that which the state laws protect... but that is opinion) This topic may have merit here since it started as (forgive the paraphrase) "We want to make cyber laws and here is the stupidity that is happening in the real world... we have a lot of work ahead of us." Anyone care to offer an opinion on this discussion's merit here? Jim -- Tantalus Inc. Bringing people together Jim Sewell-KD4CKQ 2407 N. Roosevelt Blvd. to have a little fun. Internet: jims(a)mpgn.com Key West, FL 33041 CIS: 71061,1027 (305) 293-8100 "We keep coding and coding and coding..."

1 0

Re: BEST Inc.
by Bill Garland 17 Dec '03

17 Dec '03

To: SGT=DARREN=S.=HARLOW%ISB%MCTSSA(a)nwsfallbrook3.nwac.sea06.navy.mil >> >> 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. What is not clear here is whether the information that comes up on the point-of-sale terminal is encoded on the card or is in their "neat little database" on the network into which they are tuned. I don't know, but I guess this might mean that the paper driver's licences we use here in the back woods are soon to go the way of the buggy whip. The military ID should have been enough - I would assume that, especially in the largest armed force ever assembled by man, it is easier to fake a drivers licence than a military id. But I've been wrong before... If the info is on the card, follow the refrigerator magnet idea if you don't want them to cash your cheque. Or do as the Sarge did. Then, instead of having a record that you purchased Pentouse Letters on April 14 at 10:33 pm in Mac's Milk on the corner of Broadway and 110th, they have a record of your withdrawal of 50 bucks from the atm and a picture in their video database as you did the withdrawal. Six of one, half a dozen of the other. If the info is in the database, and it is (even though _this_ pos terminal may not have access to it) then - well, if you object to this, keep up with cp and other fora, get yourself some fake or anonymous id's (?), write code, use pgp, become judgement proof, move and don't set up forwarding addresses, have your id killed, etc. Bill Garland, whose .sig just vanished

2 1

Dr Dobb's Info Way
by John Young 17 Dec '03

17 Dec '03

Dr. Dobb's has a special Winter issue on the "Information Highway" which includes a good long article on the economics of the system, past, present and future, and another fine piece on e-mail security by Bruce Schneier. That's Winter 1994, Volume 19, Issue 14.

1 0

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: Sgt Russell
by SGT=DARREN=S.=HARLOW%ISB%MCTSSA＠nwsfallbrook3.nwac.sea06.navy.mil 17 Dec '03

17 Dec '03

Wayne, 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. My job is important to me. Learning about cryptography is going to help me protect my systems and my messages. I have no desire to eavesdrop on what you or anyone else is doing on this list. I merely want to learn, and possibly contribute to the threads on the list. I have received several responses from people on the list and really appreciate that. I hope this helps to clarify my position on this list. 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..."

4 5

re: Sgt Russell
by joshua geller 17 Dec '03

17 Dec '03

Sgt Darren Harlow writes: > Wayne, > 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. > My job is important to me. Learning about cryptography is going to > help me protect my systems and my messages. I have no desire to eavesdrop on > what you or anyone else is doing on this list. I merely want to learn, and > possibly contribute to the threads on the list. I have received several > responses from people on the list and really appreciate that. I hope this > helps to clarify my position on this list. I don't see any reason why sgt. harlow shouldn't be as welcome as anyone else on the list. there are a large number of people in the military, and any generalization drawn about them is likely to be false (of course all generalizations are false, but that is another matter). for those who enjoy paranoia, I would point out that sgt. harlow is not the only person on this list with past or present military associations. josh

3 2

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

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