- cypherpunks-legacy@lists.ogf.org

NEW CP REMAILER
by nobody＠indirect.com 18 Aug '93

18 Aug '93

Well, after two days or so of missed mail and a lot of headache and missed sleep, I think I've got this working ok. The remailer address is <cdodhner(a)indirect.com>, and so far it is a vanilla remailer, nothing special at all. I have not tested it with encrypted messages yet, the public key, however, is below. Consider the remailer in 'test mode' for the next few days, and if all goes well I'll turn off the logging etc. by the 25th. Until then the remailer should be considered unsecured and all messages are subject to being inadvertantly read by myself in the process of debugging. If it works as well as it looks like it works, at that point I will turn off all logging, debugging, and archiveing, and generaly keep my nose out of it. Send any questions to me at cdodhner(a)indirect.com. Happy Hunting, -Chris -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAixwXwsAAAEEAMMN+Y9tRX5V/cYEroALiE/2pW1289kK9NCpPjaG+ExuNn0E lJOX4l0Yy6wqNCW7J4ZJEeZ7OQPUaZ6Ig4KUm2O3D8stg+YEuGPvO3TCrEpQ4faf lCZB6+qaalOyuyfGXIcgjQRl026KeYmMJkOGCcc4dFgKfp2tvJJSqYY5uHDxAAUR tClpbmRpcmVjdCByZW1haWxlciA8Y2RvZGhuZXJAaW5kaXJlY3QuY29tPg== =77gB -----END PGP PUBLIC KEY BLOCK-----

1 0

[ari@ISI.EDU: New paper on electronic currency]
by hfinney＠shell.portal.com 18 Aug '93

18 Aug '93

I just ftp'd, printed, and read the paper which Derek mentioned: NetCash: A design for practical electronic currency on the Internet by Gennady Medvinsky and Clifford Neuman I didn't think it was any good. They have an incredibly simplistic model, and their "protocols" are of the order, A sends the bank some paper money, and B sends A some electronic cash in return. They don't even do blinding of the cash. Each piece of cash has a unique serial number which is known to the currency provider. This would of course allow matching of withdrawn and deposited coins. "In particular, at the point that a client purchases coins from a currency server by check, or cashes in coins, it is possible for the currency server to record which coins have been issued to a particular client. It is expected that currency servers will not do so, and it is likely that the agreement with clients will specifically preclude it." Right. It is expected that they will not do so. I feel so much better now. These guys seem to have read the work in the field (they reference it) but they don't appear to have understood it. Hal Finney hfinney(a)shell.portal.com

1 0

Digital cash references
by hfinney＠shell.portal.com 18 Aug '93

18 Aug '93

I got asked what would be good survey articles on digital cash. Two good ones that are widely available are both by David Chaum: Scientific American, August 1992, p. 96; and Communications of the ACM, October 1985, p. 1030. Unfortunately, neither of these really describes the mathematics, instead discussing things in terms of analogies. To get more details you have to read the conference proceedings. Many of the recent Eurocrypt and Crypto conferences have discussed implementations of digital cash. Hal Finney hfinney(a)shell.portal.com

1 0

Private legal tender
by nobody＠eli-remailer 18 Aug '93

18 Aug '93

A simpler variation on what was suggested would go like this: Customer sends cash or money order to digital bank, along with a floppy with an anonymous email address (via a remailer) and a public key. The bank emails the customer encrypted digital cash corresponding to the amount he sent in (minus any service charges). If Chaum blinding is used, the needed data can be included on the floppy. Alternatives to sending a floppy would be for the customer to email the same information when he mailed his money, including some secret information with both which would tie them together. Customers spend money using the appropriate protocols. When a customer wants, he can send his digital cash to the bank to get it exchanged for new digital cash; or he can include with the digital cash instructions to tell the bank to mail a check or money order to a specified address. Here is where he could use a postal mail drop if he doesn't want to reveal his own identity (assuming he is mailing to himself); or he may request mailing to some other business which doesn't accept digital cash but from which he wants to purchase something. --------- Sugarplum ---------

1 0

No Subject
by remailer＠merde.dis.org 18 Aug '93

18 Aug '93

> From: pmetzger(a)lehman.com ("Perry E. Metzger") > To: "L. Detweiler" <ld231782(a)longs.lance.colostate.edu> > *we* *are* our government. How can it not be more obvious? What does it > say about our character if we are resigned to deprivation? > WE ARE NOT OUR GOVERNMENT. > I have an interesting fact for you, Mr. Detweiler. I did not choose > the government I live under. I chose none of its parts, agreed to none > of its actions, selected none of its members (not one person I've ever > voted for has been elected, and I only vote in self defense, not as an > endorsement of the system), and I agree with virtually none of its > actions. Sadly, this is the best country I know of to live in, so > leaving is not an option. However, don't for one minute claim that > this is *my* government. It is the government that rules me, to be > sure, but it is my master, not my servant. I would not choose to have > it operate as it does were I given the choice. It is not mine. Yes, absolutely. This discussion may be considered tangential, but the issue here is at the core of the cypherpunks raison d'etre. Detweiller seems to be tremendously confused about the source of government and unaware of the emergence of the American State. I personally feel that I have zero representation in what passes for our "democratic" government for the reasons you mention, exactly. I find myself amazed to encounter the numbers of "mainstream Americans" who have gradually come to the same conclusion, independent of outside prompting. My only hope, personally, is to fight vigorously (perhaps literally, in due course) for the maintenance of the Bill of Rights as protection against the tyranny of _both_ the mob and the State. I personally see the prospect of an electronic so-called democracy to be terrifying, a mechanism whose technical subversion would be trivial for the State's assets, say the NSA. Simple manipulation by propaganda would be even easier. Read Orwell. Read Zamyatin. Cypherpunks are providing the basis for long-range, (relatively) secure communication between those activists and thinkers who may have the power to bring down the State and restore the individual autonomy this nation was originally devised to foster. In the past year I have had the privilege to see a de facto cadre of brilliant men and women develop from formerly isolated individuals, all thanks to computer networks and the emergence of secure communication. I have found answers to questions I have been asking for twenty-five years, and provided information that answered similar questions for others. I have seen the product of these private communications develop into public statements that have demonstrably influenced the political outlooks of hundreds, perhaps thousands, of casual computer network users. The ability of computer networks and secure communication has in itself empowered and radicalized an otherwise disenfranchised body of valuable and vital Americans. Really, this is heady stuff. It gives me reason to stick around and watch this country for a few more years.

1 0

NIST call for Comments on "Key-Escrow" (fwd)
by fergp＠sytex.com 18 Aug '93

18 Aug '93

From: Dave Banisar <uunet!washofc.cpsr.org!banisar> Date: Tue, 17 Aug 1993 14:23:16 EST Subject: Call for Clipper Comments Call for Clipper Comments The National Institute of Standards and Technology (NIST) has issued a request for public comments on its proposal to establish the "Skipjack" key-escrow system as a Federal Information Processing Standard (FIPS). The deadline for the submission of comments is September 28, 1993. The full text of the NIST notice follows. CPSR is urging all interested individuals and organizations to express their views on the proposal and to submit comments directly to NIST. Comments need not be lengthy or very detailed; all thoughtful statements addressing a particular concern will likely contribute to NIST's evaluation of the key-escrow proposal. The following points could be raised about the NIST proposal (additional materials on Clipper and the key escrow proposal may be found at the CPSR ftp site, cpsr.org) * The potential risks of the proposal have not been assessed and many questions about the implementation remain unanswered. The NIST notice states that the current proposal "does not include identification of key escrow agents who will hold the keys for the key escrow microcircuits or the procedures for access to the keys." The key escrow configuration may also create a dangerous vulnerability in a communications network. The risks of misuse of this feature should be weighed against any perceived benefit. * The classification of the Skipjack algorithm as a "national security" matter is inappropriate for technology that will be used primarily in civilian and commercial applications. Classification of technical information also limits the computing community's ability to evaluate fully the proposal and the general public's right to know about the activities of government. * The proposal was not developed in response to a public concern or a business request. It was put forward by the National Security Agency and the Federal Bureau of Investigation so that these two agencies could continue surveillance of electronic communications. It has not been established that is necessary for crime prevention. The number of arrests resulting from wiretaps has remained essentially unchanged since the federal wiretap law was enacted in 1968. * The NIST proposal states that the escrow agents will provide the key components to a government agency that "properly demonstrates legal authorization to conduct electronic surveillance of communications which are encrypted." The crucial term "legal authorization" has not been defined. The vagueness of the term "legal authorization" leaves open the possibility that court- issued warrants may not be required in some circumstances. This issue must be squarely addressed and clarified. * Adoption of the proposed key escrow standard may have an adverse impact upon the ability of U.S. manufacturers to market cryptographic products abroad. It is unlikely that non-U.S. users would purchase communication security products to which the U.S. government holds keys. Comments on the NIST proposal should be sent to: Director, Computer Systems Laboratory ATTN: Proposed FIPS for Escrowed Encryption Standard Technology Building, Room B-154 National Institute of Standards and Technology Gaithersburg, MD 20899 Submissions must be received by September 28, 1993. CPSR has asked NIST that provisions be made to allow for electronic submission of comments. Please also send copies of your comments on the key escrow proposal to CPSR for inclusion in the CPSR Internet Library, our ftp site. Copies should be sent to <clipper(a)washofc.cpsr.org>. ================================================================= FEDERAL REGISTER VOL. 58, No. 145 DEPARTMENT OF COMMERCE (DOC) National Institute of Standards and Technology (NIST) Docket No. 930659-3159 RIN 0693-AB19 A Proposed Federal Information Processing Standard for an Escrowed Encryption Standard (EES) 58 FR 40791 Friday, July 30, 1993 Notice; request for comments. SUMMARY: A Federal Information Processing Standard (FIPS) for an Escrowed Encryption Standard (EES) is being proposed. This proposed standard specifies use of a symmetric-key encryption/decryption algorithm and a key escrowing method which are to be implemented in electronic devices and used for protecting certain unclassified government communications when such protection is required. The algorithm and the key escrowing method are classified and are referenced, but not specified, in the standard. This proposed standard adopts encryption technology developed by the Federal government to provide strong protection for unclassified information and to enable the keys used in the encryption and decryption processes to be escrowed. This latter feature will assist law enforcement and other government agencies, under the proper legal authority, in the collection and decryption of electronically transmitted information. This proposed standard does not include identification of key escrow agents who will hold the keys for the key escrow microcircuits or the procedures for access to the keys. These issues will be addressed by the Department of Justice. The purpose of this notice is to solicit views from the public, manufacturers, and Federal, state, and local government users so that their needs can be considered prior to submission of this proposed standard to the Secretary of Commerce for review and approval. The proposed standard contains two sections: (1) An announcement section, which provides information concerning the applicability, implementation, and maintenance of the standard; and (2) a specifications section which deals with the technical aspects of the standard. Both sections are provided in this notice. DATES: Comments on this proposed standard must be received on or before September 28, 1993. ADDRESSES: Written comments concerning the proposed standard should be sent to: Director, Computer Systems Laboratory, ATTN: Proposed FIPS for Escrowed Encryption Standard, Technology Building, room B-154, National Institute of Standards and Technology, Gaithersburg, MD 20899. Written comments received in response to this notice will be made part of the public record and will be made available for inspection and copying in the Central Reference and Records Inspection Facility, room 6020, Herbert C. Hoover Building, 14th Street between Pennsylvania and Constitution Avenues, NW., Washington, DC 20230. FOR FURTHER INFORMATION CONTACT: Dr. Dennis Branstad, National Institute of Standards and Technology, Gaithersburg, MD 20899, telephone (301) 975-2913. SUPPLEMENTARY INFORMATION: This proposed FIPS implements the initiative announced by the White House Office of the Press Secretary on April 16, 1993. The President of the U.S. approved a Public Encryption Management directive, which among other actions, called for standards to facilitate the procurement and use of encryption devices fitted with key-escrow microcircuits in Federal communication systems that process sensitive, but unclassified information. Dated: July 26, 1993. Arati Prabhakar, Director.(NIST) ---------------------------------------------------- Federal Information Processing Standards Publication XX 1993 XX Announcing the Escrowed Encryption Standard (EES) Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant to section 111(d) of the Federal Property and Administrative Services Act of 1949 as amended by the Computer Security Act of 1987, Public Law 100-235. Name of Standard: Escrowed Encryption Standard (EES). Category of Standard: Telecommunications Security. Explanation: This Standard specifies use of a symmetric-key encryption (and decryption) algorithm and a Law Enforcement Access Field (LEAF) creation method (one part of a key escrow system) which provide for decryption of encrypted telecommunications when interception of the telecommunications is lawfully authorized. Both the algorithm and the LEAF creation method are to be implemented in electronic devices (e.g., very large scale integration chips). The devices may be incorporated in security equipment used to encrypt (and decrypt) sensitive unclassified telecommunications data. Decryption of lawfully intercepted telecommunications may be achieved through the acquisition and use of the LEAF, the decryption algorithm and escrowed key components. To escrow something (e.g., a document, an encryption key) means that it is "delivered to a third person to be given to the grantee only upon the fulfillment of a condition" (Webster's Seventh New Collegiate Dictionary). A key escrow system is one that entrusts components of a key used to encrypt telecommunications to third persons, called key component escrow agents. In accordance with the common definition of "escrow", the key component escrow agents provide the key components to a "grantee" (i.e., a government agency) only upon fulfillment of the condition that the grantee properly demonstrates legal authorization to conduct electronic surveillance of communications which are encrypted using the specific device whose key component is requested. The key components obtained through this process are then used by the grantee to reconstruct the device unique key and obtain the session key (contained in the LEAF) which is used to decrypt the telecommunications that are encrypted with that device. The term, "escrow", for purposes of this standard, is restricted to the dictionary definition. The encryption/decryption algorithm has been approved for government applications requiring encryption of sensitive unclassified telecommunications of data as defined herein. The specific operations of the algorithm and the LEAF creation method are classified and hence are referenced, but not specified, in this standard. Data, for purposes of this standard, includes voice, facsimile and computer information communicated in a telephone system. Telephone system, for purposes of this standard, is limited to systems circuit-switched up to no more than 14.4 kbs or which use basic-rate ISDN, or to a similar grade wireless service. Data that is considered sensitive by a responsible authority should be encrypted if it is vulnerable to unauthorized disclosure during telecommunications. A risk analysis should be performed under the direction of a responsible authority to determine potential threats and risks. The costs of providing encryption using this standard as well as alternative methods and their respective costs should be projected. A responsible authority should then make a decision, based on the risk and cost analyses, whether or not to use encryption and then whether or not to use this standard. Approving Authority: Secretary of Commerce. Maintenance Agency: Department of Commerce, National Institute of Standards and Technology. Applicability: This standard is applicable to all Federal departments and agencies and their contractors under the conditions specified below. This standard may be used in designing and implementing security products and systems which Federal departments and agencies use or operate or which are operated for them under contract. These products may be used when replacing Type II and Type III (DES) encryption devices and products owned by the government and government contractors. This standard may be used when the following conditions apply: 1. An authorized official or manager responsible for data security or the security of a computer system decides that encryption is required and cost justified as per OMB Circular A- 130; and 2. The data is not classified according to the National Security Act of 1947, as amended, or the Atomic Energy Act of 1954, as amended. However, Federal departments or agencies which use encryption devices for protecting data that is classified according to either of these acts may use those devices also for protecting unclassified data in lieu of this standard. In addition, this standard may be adopted and used by non- Federal Government organizations. Such use is encouraged when it provides the desired security. Applications: Devices conforming to this standard may be used for protecting unclassified communications. Implementations: The encryption/decryption algorithm and the LEAF creation method shall be implemented in electronic devices (e.g., electronic chip packages) that can be physically protected against unauthorized entry, modification and reverse engineering. Implementations which are tested and validated by NIST will be considered as complying with this standard. An electronic device shall be incorporated into a cyptographic module in accordance with FIPS 140-1. NIST will test for conformance with FIPS 140-1. Cryptographic modules can then be integrated into security equipment for sale and use in an application. Information about devices that have been validated, procedures for testing equipment for conformance with NIST standards, and information about obtaining approval of security equipment are available from the Computer Systems Laboratory, NIST, Gaithersburg, MD 20899. Export Control: Implementations of this standard are subject to Federal Government export controls as specified in title 22, Code of Federal Regulations, parts 120 through 131 (International Traffic of Arms Regulations -ITAR). Exporters of encryption devices, equipment and technical data are advised to contact the U.S. Department of State, Office of Defense Trade Controls for more information. Patents: Implementations of this standard may be covered by U.S. and foreign patents. Implementation Schedule: This standard becomes effective thirty days following publication of this FIPS PUB. Specifications: Federal Information Processing Standard (FIPS XXX)(affixed). Cross Index: a. FIPS PUB 46-2, Data Encryption Standard. b. FIPS PUB 81, Modes of Operation of the DES c. FIPS PUB 140-1, Security Requirements for Cryptographic Modules. Glossary: The following terms are used as defined below for purposes of this standard: Data-Voice, facsimile and computer information communicated in a telephone system. Decryption-Conversion of ciphertext to plaintext through the use of a cryptographic algorithm. Device (cryptographic)-An electronic implementation of the encryption/decryption algorithm and the LEAF creation method as specified in this standard. Digital data-Data that have been converted to a binary representation. Encryption-Conversion of plaintext to ciphertext through the use of a cryptographic algorithm. Key components-The values from which a key can be derived (e.g., KU sub 1 + KU sub 2). Key escrow -A process involving transferring one or more components of a cryptographic key to one or more trusted key component escrow agents for storage and later use by government agencies to decrypt ciphertext if access to the plaintext is lawfully authorized. LEAF Creation Method 1-A part of a key escrow system that is implemented in a cryptographic device and creates a Law Enforcement Access Field. Type I cryptography-A cryptographic algorithm or device approved by the National Security Agency for protecting classified information. Type II cryptography-A cryptographic algorithm or device approved by the National Security Agency for protecting sensitive unclassified information in systems as specified in section 2315 of Title 10 United State Code, or section 3502(2) of Title 44, United States Code. Type III cryptography-A cryptographic algorithm or device approved as a Federal Information Processing Standard. Type III(E) cryptography-A Type III algorithm or device that is approved for export from the United States. Qualifications. The protection provided by a security product or system is dependent on several factors. The protection provided by this standard against key search attacks is greater than that provided by the DES (e.g., the cryptographic key is longer). However, provisions of this standard are intended to ensure that information encrypted through use of devices implementing this standard can be decrypted by a legally authorized entity. Where to Obtain Copies of the Standard: Copies of this publication are for sale by the National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. When ordering, refer to Federal Information Processing Standards Publication XX (FIPS PUB XX), and identify the title. When microfiche is desired, this should be specified. Prices are published by NTIS in current catalogs and other issuances. Payment may be made by check, money order, deposit account or charged to a credit card accepted by NTIS. Specifications for the Escrowed Encryption Standard 1. Introduction This publication specifies Escrowed Encryption Standard (EES) functions and parameters. 2. General This standard specifies use of the SKIPJACK cryptographic algorithm and the LEAF Creation Method 1 (LCM-1) to be implemented in an approved electronic device (e.g., a very large scale integration electronic chip). The device is contained in a logical cryptographic module which is then integrated in a security product for encrypting and decrypting telecommunications. Approved implementations may be procured by authorized organizations for integration into security equipment. Devices must be tested and validated by NIST for conformance to this standard. Cryptographic modules must be tested and validated by NIST for conformance to FIPS 140-1. 3. Algorithm Specifications The specifications of the encryption/decryption algorithm (SKIPJACK) and the LEAF Creation Method 1 (LCM-1) are classified. The National Security Agency maintains these classified specifications and approves the manufacture of devices which implement the specifications. NIST tests for conformance of the devices implementing this standard in cryptographic modules to FIPS 140-1 and FIPS 81. 4. Functions and Parameters 4.1 Functions The following functions, at a minimum, shall be implemented: 1. Data Encryption: A session key (80 bits) shall be used to encrypt plaintext information in one or more of the following modes of operation as specified in FIPS 81: ECB, CBC, OFB (64) CFB (1, 8, 16, 32, 64). 2. Data Decryption: The session key (80 bits) used to encrypt the data shall be used to decrypt resulting ciphertext to obtain the data. 3. Key Escrow: The Family Key (KF) shall be used to create the Law Enforcement Access Field (LEAF) in accordance with the LEAF Creation Method 1 (LCM-1). The Session Key shall be encrypted with the Device Unique Key and transmitted as part of the LEAF. The security equipment shall ensure that the LEAF is transmitted in such a manner that the LEAF and ciphertext may be decrypted with legal authorization. No additional encryption or modification of the LEAF is permitted. 4.2 Parameters The following parameters shall be used in performing the prescribed functions: 1. Device Identifier (DID): The identifier unique to a particular device and used by the Key Escrow System. 2. Device Unique Key (KU): The cryptographic key unique to a particular device and used by the Key Escrow System. 3. Cryptographic Protocol Field (CPF): The field identifying the registered cryptographic protocol used by a particular application and used by the Key Escrow System (reserved for future specification and use). 4. Escrow Authenticator (EA): A binary pattern that is inserted in the LEAF to ensure that the LEAF is transmitted and received properly and has not been modified, deleted or replaced in an unauthorized manner. 5. Initialization Vector (IV): A mode and application dependent vector of bytes used to initialize, synchronize and verify the encryption, decryption and key escrow functions. 6. Family Key (KF): The cryptographic key stored in all devices designated as a family that is used to create the LEAF. 7. Session Key (KS): The cryptographic key used by a device to encrypt and decrypt data during a session. 8. Law Enforcement Access Field (LEAF): The field containing the encrypted session key and the device identifier and the escrow authenticator. 5. Implementation The Cryptographic Algorithm and the LEAF Creation Method shall be implemented in an electronic device (e.g., VLSI chip) which is highly resistant to reverse engineering (destructive or non- destructive) to obtain or modify the cryptographic algorithms, the DID, the KF, the KU, the EA, the CPF, the operational KS, or any other security or Key Escrow System relevant information. The device shall be able to be programmed/personalized (i.e., made unique) after mass production in such a manner that the DID, KU (or its components), KF (or its components) and EA fixed pattern can be entered once (and only once) and maintained without external electrical power. The LEAF and the IV shall be transmitted with the ciphertext. The specifics of the protocols used to create and transmit the LEAF, IV, and encrypted data shall be registered and a CPF assigned. The CPF shall then be transmitted in accordance with the registered specifications. The specific electric, physical and logical interface will vary with the implementation. Each approved, registered implementation shall have an unclassified electrical, physical and logical interface specification sufficient for an equipment manufacturer to understand the general requirements for using the device. Some of the requirements may be classified and therefore would not be specified in the unclassified interface specification. Paul Ferguson | "Government, even in its best state, Network Integrator | is but a necessary evil; in its worst Centreville, Virginia USA | state, an intolerable one." fergp(a)sytex.com | - Thomas Paine, Common Sense Type bits/keyID Date User ID pub 1024/1CC04D 1993/03/15 Paul Ferguson <fergp(a)sytex.com> Key fingerprint = EE D2 93 7D 04 6D C6 05 AC 36 AD 9D 8E 4F 41 58

1 0

[DEC] U.S. Computer May Have Violated Export Regulations
by gnu 18 Aug '93

18 Aug '93

a0600 r abx ^U.S. Computer May Have Violated Export Regulations< ^By PAUL RAEBURN= ^AP Science Editor= NEW YORK (AP) _ The Digital Equipment Corp. abruptly pulled two powerful new computers off a global computer network out of concerns about possible export violations, even though the computers never left the country. The result of Digital's action was to deny U.S. computer users access to U.S. computers operating in the United States. Critics said the episode demonstrates how export laws intended to regulate weapons technology are not only infringing on American civil liberties but also stifling innovation and hurting American businesses. Digital said its concern was that foreigners could connect to the computers from abroad, generate data, and illegally export it over the Internet computer network, which carries data and electronic mail around the world. The computers were reconnected to the computer network on July 7, but access is now limited to people who are screened by the company, Mark Fredrickson, a Digital spokesman, said Friday. The computers are not what industry would call supercomputers, but they do fit the government definition of a supercomputer. A former Commerce Department official who is now a trade consultant in Washington said the connection of a supercomputer to a global network could lead to violations of federal export regulations. ``If it was available overseas and they allowed people overseas to use it, then technically they were allowing access to a supercomputer to people they didn't know,'' said Paul Freedenberg, who was the Commerce Department's undersecretary for export administration at the end of the Reagan administration. Freedenberg is an international trade consultant at Baker and Botts in Washington, the law firm of former Secretary of State James Baker. He emphasized that he had no personal knowledge of the Digital computer hookup and that he was speaking of the regulations generally. ``I can't say Digital violated the law, because I don't know what Digital did,'' he said. Lee Mercer, Digital's corporate export manager, said making the computer available was not a violation. A Commerce Department official, speaking on condition his name not be used, agreed that making the computer available was not a violation, but that export of data generated on the computer would be a violation of regulations. The computer hookup was in place for five weeks in April and May, said Fredrickson. It was intended to give potential customers the opportunity to test-drive the computers. It was terminated by company executives who wanted to avoid any appearance of violating export regulations, he said. ``None of this has been motivated by anyone from the government suggesting that we do anything here,'' said Fredrickson. ``This was simply our own internal people raising the possibility of concern.'' In a separate incident last year, a Digital computer ``bulletin board,'' offered access to programs for encoding computer data. Exporting such software is a violation of federal regulations, Freedenberg said. ``It's a technical data transfer'' that falls under the State Department's control of munitions export, he said. Frederickson said the company shut the bulletin board down to ensure that the software would not be exported illegally. ``Nothing was found that was thought to be a concern even meriting informing the government about it,'' he said. Digital, the nation's No. 2 computer maker after IBM, said that 65 percent of its $14 billion in annual sales are overseas. In December 1991, the Commerce Department charged the company with 62 violations of export laws and fined it $2.4 million. It was the largest fine the department had imposed for export violations. Digital agreed to pay it without admitting or denying guilt. The Digital computers connected to the network were two of Digital's new AXP 4000 computers, operating in a Digital laboratory in Palo Alto, Calif. The computers, which cost from $77,000 to $100,000, are considered midsized computers by industry standards. Freedenberg said that the government would probably soon revise its outmoded standards that define those models as supercomputers and bring them under export regulations. Robert Kaylor, a spokesman for the Commerce Department, said the department was prohibited by law from discussing the details of a specific case. Critics called for speedy revision of the export laws, which date from the Cold War. ``Export control policies are shutting us directly out of certain markets,'' costing U.S. businesses at least $10 billion a year in lost exports, said Howard Lewis, vice president of the National Association of Manufacturers. ``It's harmful to innovation, but we think it's also very harmful to the privacy interests of American citizens,'' said Daniel Weitzner, an attorney with the Electronic Frontier Foundation, a group concerned with computers and civil-liberties issues.

1 0

Re: encrypted anonymous traffic
by lazylion＠netcom.com 18 Aug '93

18 Aug '93

Hmm. Very interesting. I observe two not completely diametrically opposed viewpoints here. Consider: On one hand, there has been a lot of (IMHO government generated) hype lately about the very real possibility of justice department "legal" reprisals against individuals running what I consider to be common carrier messaging services (BBS's, remailers, hosts, etc.) based on the content of messages passing through those services (porn GIF's, etc). While it is clear to me that in this environment of obvious government oppression of expression through terror tactics against common carriers, it is certainly true that a responsible indvidual in this environment must do what they think is appropriate to protect themselves from government harassment. We are not all in situations where we can be arrested and thrown in jail (even for an appropriate cause) and simply ignore responsibilities to loved ones and employees (or even customers) who may be relying on us to provide for them. Each of us must make an individual choice weather and how much to fight the oppressive atmosphere by refusing to subscribe to the justice department's hillarious misreading of the Bill of Rights. It behooves us all to respect the positions of those who for whatever reason do not wish to put themselves in further danger by taking the firm stand that we all know is appropriate against these government hoodlums. I support and respect the right of any concered operator of a BBS, host or anonomous remailer to responsibly (and concentually!) refraim from entering this battle. While it is true that I believe that it does further slightly damage our cause, it is a necessary evil to support the wishes of others. It is, of course, necessary, to completely disclose policies like this to all perspective users (within reason) and it would be most convinient for those users if an actual policy were developped and published, but I can see that since we are in a state of controversy about this very issue, any attempt to define what is or is not appropriate will always be met with great discontent (probably on both sides :)) Live & Let Live (but INFORM!) "Just Say KNno!" <Insert whitty remark here> --- Ben D. Weiss --- Packet Radio: WB5QAL(a)N6EEG.#NOCAL.CA.US Internet: LazyLion(a)Netcom.com Telephone: (510) 841-5709 ---------------------------------------

1 0

Why cypherpunks are 'stalled', IMHO
by jet＠netcom.com 18 Aug '93

18 Aug '93

I just got a 15k mail message from one Dave Banisar that consisted of wire news clippings, only one of which had anything even vaguely related to cryptogrophy. *This* is why pepole drop off the list so often. (Or don't show up at meetings, thinking they'll be as noisy?). If it's just more of the general computer geek/privacy/libertarian stuff all over again, the same crud that flows in such volumes on the libertarian list, and a couple of other lists I've had the misfortune to be on, people will go away. (In particular, evoting, pranks to prove points, general ranting.) Let's try a little self-restraint, perhaps? Or take discussions off-list, or to the appropriate list? Maybe if the list were more hard-core crypto (and less noisy), more people would be on the list, and more research types might be willing to be on the list. mp-render, the massively parallel rendering list, has high content, low volume, and some of the top folks in the biz on the list available for discussion. I'm sure if myself and a few other starting going on at length about how cool Pixar's juice-box commercial was, there'd be a lot of people unsubscribing... Luckly, I have a mailer that supports 'kill', so I can easily blast through multiple rounds of whether evoting is the End of the World. :-) But I've worked with plenty of researchers (and been in the position myself) where getting more than a few email messages a day is a big pain in the ass. Lots of people *doing* things don't put the effort into making 'the net' as much a part of their lives as some of the people here. Hell, my boss at NASA was still reading their mail with /bin/mail until I pointed them at elm. Can you imagine getting 30-40 messages a day, and having to wade through them with /bin/mail? (I watch my gf do this, I think she's nutz and on about a dozen too many mailing lists.) Granted, I've only made on c-punk meeting (travel and illness have interfered with my other attempts), and the code I'm working on will only be able to run on a machine with limited numbers (only 50 or so built), so maybe I'm in the 'not doing so much' part. (I'm not immune to Off-Topic disease, either. :-) -- jet(a)netcom.com -- J. Eric Townsend -- '92 R100R: "CLACKER" "Either what you've said is so vague that it's meaningless or I disagreee with you completely." -- Tom Maddox

1 0

Private, legal-tender billing & refunding for online services
by nobody＠alumni.cco.caltech.edu 17 Aug '93

17 Aug '93

In "Twain" and other Internet business concepts there is a big problem with establishing methods of payments and refunds that is convenient for both the customer and the business, while insuring the privacy of the customer. AMIX, netcom, et. al. ask for credit card number, keep names and addresses of customers online, probably keep dossiers of services customers have bought, etc. (Even if not purposefully, they frequently do system backups). Just about every business has to have a way of recieving payment and distributing refunds to customers, in legal tender. I'm interested in how to set up a physical mail drop/ATM protocol to allow customers to exchange legal tender for digital postage (or coupons, or greenstamps, or cash, or whatever we want to call it. Digicash is ideal, but the nomenclature might have to depend on what is legal in various jurisdictions). Here's my first cut: Customer signs up by sending legal tender (physical cash or money order) in mail, with anon physical mail drop to which the stamp vendor replies with a floppy containing: * N digital stamps * other tools to connect to vendor (eg software to handle digital stamps, e-mail utilities, client software, etc.) Vendor also sets up a "bearer" offshore bank account or credit union account with ATM card. A PIN and password are sent to customer, needed to activate the card and digital stamps respectively. Customer pays up front for N digital stamps and the sign-up fee. Digistamps obtained from various vendors (in the S&H greenstamp scenario) can be deposited at will. For refunds, these stamps can be removed from the account, digitally converting to legal tender in the bearer bank account, where customer can remove at a max rate of (typically) $300/day via ATM. Some problems: mail drops and bearer bank accounts may be a major hassle for customers of most service businesses. Also for "normal" businesses many customers will be turned off by the "shady" nature of the billing scheme. (Cf. Cindy's recent response to Tim May's post on her bartering scheme). There are major legal issues here: is a formal "bearer bank account" legal? Are digital S&H greenstamps legal? In what jurisdictions?

1 0