- cypherpunks-legacy - lists.cpunks.org

Re: ANON: remailer list
by remail＠tamsun.tamu.edu 19 Aug '93

19 Aug '93

> >11: remail(a)tamsun.tamu.edu > >12: remail(a)tamaix.tamu.edu > These last two seem to remail from the same address. Are there really two, > with one automatically feeding into the other as a two-tier? What's the > deal? tamsun and tamaix are two different machines which share, NFS-ed, user directories; hence, any mail sent to tamsun or tamaix goes through the same bit of remailing script. They both work independantly, however, and I decided to keep both in case one of the machines goes down for some reason. > I'll send this message to remail(a)tamaix.tamu.edu to illustrate. I tried to, > and this message bounced. This is the second try, to > remail(a)tamsun.tamu.edu. Let me know via email to remail(a)tamsun.tamu.edu if you still can't get your message through. It should work though. -- [ Carlos Macedo Gomes ][ Quis Custodiet ][: .8. :]------ [ gomes(a)tamu.edu ][ Ipsos Custodes? ][ . ooo . ]000000 [ cmghelp(a)tamsun.tamu.edu ][ ][ : =o(Y)o= : ]000000 [ My views- not TAMU's ][30 37 40 N, 96 20 03 W][oo .ooooo. oo]------

1 0

Re: ANON: remailer list
by remail＠tamsun.tamu.edu 19 Aug '93

19 Aug '93

At 3:42 PM 8/17/93 -0500, Karl Lui Barrus wrote: >Q1: What cypherpunk remailers exist? > >A1: > > 1: nowhere(a)bsu-cs.bsu.edu > 2: hh(a)cicada.berkeley.edu > 3: hh(a)pmantis.berkeley.edu > 4: hh(a)soda.berkeley.edu > 5: 00x(a)uclink.berkeley.edu I've never gotten a response from this one. Has anyone? > 6: hal(a)alumni.caltech.edu > 7: ebrandt(a)jarthur.claremont.edu > 8: remailer(a)rebma.mn.org > 9: elee7h5(a)rosebud.ee.uh.edu >10: hfinney(a)shell.portal.com >11: remail(a)tamsun.tamu.edu >12: remail(a)tamaix.tamu.edu These last two seem to remail from the same address. Are there really two, with one automatically feeding into the other as a two-tier? What's the deal? I'll send this message to remail(a)tamaix.tamu.edu to illustrate. I tried to, and this message bounced. This is the second try, to remail(a)tamsun.tamu.edu.

1 0

No Subject
by koontzd＠lrcs.loral.com 19 Aug '93

19 Aug '93

>From: "Perry E. Metzger" <pmetzger(a)lehman.com> >>From: plmoses(a)emoryu1.cc.emory.edu >Paul L. Moses says: >> >> This may be a semantic point, but it should be made.... David >> Koontz sez: "Avoiding the appearance of endorsing the violent >> overthrow of government is prudent policy..." Um...I think I know >> what you mean, but isn't it better to just say outright that >> violence really is not the way to reform government at all, save in >> truly historical, exceptional cases (American Revolution, French >> Revolution...) >I'm not sure either of those cases truly succeeded, either. >Myself, I feel that no good can be accomplished by initiating force >against others, no matter what the cause. Violent revolutions go >completely against my grain. Any sorts of reforms that will stick are >going to have to arise peacefully. This is not to say, of course, that >they will necessarily arise via the "democratic process". The >government may simply find itself outflanked, for instance. (Imagine >as an example if the government realized tomorrow that allowing >citizens to know how to read would be dangerous -- its a little late >to stop it, so they will never do anything about that.) Two points of clarification: 1) I do not now, nor have I in the past advocated the violent overthrow of any domestic government. I am also opposed to the overthrow of foreign governments on moral grounds. 2) The necessity to distance ones self or organization (as may have occured in the case of the Libertarian Party) from what should be in effect an expression of free speech, smacks of McCarthyistic opression. (this was what was hidden beneath the cynicism and 'waffle') Thanks for rising to the occasion. ---- A country that can have a McCarthy Era has no business giving more power to its government.

3 2

Re: World record in password checking
by smb＠research.att.com 18 Aug '93

18 Aug '93

Perhaps because internal communication between those 1024 machines will be significantly more difficult than running on a machine that is optimized for parallel operations, RPC just doesn't cut it. You would probably lose a number of your hosts off the top just to coordinate the activity of the remaining machines. But DES-cracking and password-cracking are almost completely decomposable; no co-ordination is necessary after you've sent the ciphertext string and the starting point for the search. Besides, if you really want to do this spend your one or two million (approx cost of your 1000PC site) on seriously dedicated DES-cracking parallel hardware. Do the cracking in hardware, not software. Sure -- if you want a machine that does nothing but. Either way, I could think of more fun things to do with those 1024 PCs:) Well, there's been an interesting thread on rec.woodworking about hurling strange things with medieval siege engines...

1 0

my aps
by T. William Wells 18 Aug '93

18 Aug '93

There are several issues I want to address in this message. One is communication style, another is the nature of my anonymous service, and finally, what I think about the whole thing. On communication style: some people have this delusion that they can write to others and expect or even demand a reply. Well, it isn't so. If someone writes to me, I'm under no a priori obligation to read, to try to understand, or to spend effort replying. This is irrespective of the style *or* the content of their message. In general, the only thing that obligates one to answer another is the prior respect that one should have for others -- which has to be lived up to in *their* actions. Mr. Detweiler simply blew it. His original message was full of insults and insinuations and, quite frankly, he should consider himself honored that I bothered to tell him where he went wrong. _Of course_, any legitimate issues he brought up in the same message weren't addressed. He demanded of me that I address those issues -- and that I deal with hus abusiveness. As you may guess, I really have no interest in addressing Mr. Detweiler directly; I figure he's got a few years of mental development to go through before I'll consider him fit for carrying out any sort of rational conversation with. However, others have been more reasonable and I'll try to address some of their concerns and to point out some of the relevant circumstances surrounding my service. The first thing you need to understand is that my anonymous service is integral to a specific community of people who have suffered through childhood abuse and adult sexual abuse. (In fact, essentially everyone on the group who is dealing with adult sexual abuse is also dealing with childhood abuse.) It is intended only for the users of a specific set of newsgroups, alt.sexual.abuse.recovery and its .d group. On the newsgroup, there are usually several individuals who are "that close" to committing suicide. Some will be shortly, or have been recently, in psychiatric wards. Most have been in, or are contemplating, psychological therapy of one sort or another. Quite a few are taking medication for various psychiatric conditions. This is neither the time nor the place to discuss the wherefors and whys of abuse recovery; you'll just have to take it as a given that the rules used for understanding people in general won't work so well when applied to this newsgroup, or to my anonymous service. I provide a service to people who, at least in specific areas, are not rational, who are definitely irrational. I know of, for example, one person who went into convulsions simply because they received e-mail from a person who, many years ago, had abused a child. In line with that, my service differs from the standard anonymous services. One is that it *is* integrated into the community. I am a survivor myself, I offer personal assistance (in computer matters) to people in the group, I forward the newsgroup via e-mail to those who can't get it otherwise, and so on. These are all part of what I do, not just running the anonymous service. (In fact, I have to occasionally correct the erroneous belief that I am responsible for the newsgroup; not surprising when you realize that over half the newsgroup goes through my server.) My service has things like being able to turn on and off e-mail forwarding. People can remove themselves from the server automatically. Shortly, people will be able to specify by id who they do or do not get e-mail from. The other area where my service differs is that the others provide two distinct functions, confidentiality and privacy, but there is no attempt, or reason, to protect their users from any sort of e-mail. It's enough to deal with harassment claims when they arise. In mine, I've chosen a different direction. I've decided to make the attempt to keep out specific types of e-mail, with the cost that I cannot guarantee privacy from me. Also, I probably have a higher standard of confidentiality than the other two services. (This is not intending to suggest that there's anything wrong with their standards, just that I suspect mine are a bit tighter.) People on the newsgroup post their innermost secrets and fears and many have a need to believe that those won't then be used against them. (And, for that reason, the default for e-mail forwarding is "off".) Public posting is one thing but it is quite easy for one skilled in the art of abusing (and, yes, there are such people and they do read the newsgroup, getting a kick out of the pain of others) to manipulate people behind the scenes into abusive situations and in such a way as to keep the victim from being able to speak of what is going on. *That*, and similar things, are what this is all about. As to my thoughts on the relevant principles. As I mentioned, I am an Objectivist. That may clue you as to where I'm coming from. But in case not, the primary fact is that I'm offering a *private* service. I run it out of my home, using my phone lines, and paid for with my money. While I offer it to all on the newsgroup, it *is* *not* intended for the general public. Only survivors and their supporters are legitimate users. (Though I tend to be lax on that. Just as I am with my encryption proscription. There are users who send encrypted e-mail through my service but they have recieved my prior permission to do so.) No one, other than myself, has any right to specify what I do with this, beyond the minimum of respecting their rights. Their rights do not extend to arbitrary protection of their confidentiality or privacy. Those who use my anonymous service have an implicit right to protection of their anonymity *and that is all*. (And even that is only up to a point.) Any other protections I offer beyond that are mine to choose; they are not implicit in an anonymous server. In addition to confidentiality, I offer privacy in two ways: from others, because it is necessary to protect confidentiality, and from myself, because no one likes their innermost thoughts gratuitously pawed over by one who is essentially a complete stranger. But that latter privacy is only with respect to *gratuitous* invasion by myself. Beyond that, I offer a watchful eye to keep abuses in hand. The bottom line is this: I provide a useful service to over half of the newsgroup. Most of its users are happy with it. Most people who have communicated with me, who are or are potentially legitimate users of my service, have been either neutral or positive about my policies. (Yes, most people who have expressed dislike for my policies are outsiders.) As things are, they work well. No change is *necessary* though some may be *desirable*. Careful thought and respectful dialog may convince me of desirable changes. Logicless rhetoric and verbal abuse, however, will, at best, cause me to ignore both the speaker and his message.

2 2

Re: mailing list <-> newsgroup ?
by peter honeyman 18 Aug '93

18 Aug '93

> Yeah. Gene Spafford often says ... it is odd that you quote gene spafford in a group that is anathema to his avowed goals. peter

2 1

Call for Clipper Comments
by Dave Banisar 18 Aug '93

18 Aug '93

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.

3 3

fyi: forward from cert-tools-request mailing list.
by Peter shipley 18 Aug '93

18 Aug '93

------- Forwarded Message >From cert-tools-request(a)cert.org Wed Aug 18 13:05:55 1993 To: cert-tools(a)cert.org Originally-From: Jorgen Bo Madsen <Jorgen.Bo.Madsen(a)uni-c.dk> Subject: World record in password checking A NEW WORLD RECORD IN PASSWORD CHECKING HAS BEEN SET: - - - - ----------------------------------------------------- Roch Bourbonnais, a Thinking Machines Corporation engineer, has ported and optimized the CM/2 port of the UFC-crypt to a CM/5 system. The UFC-crypt (Ultra Fast Crypt) implementation on the CM/2 Connection Machine (parallel computer) is a UNIX password checking routine (crypt()) ported by Michael Glad at UNI-C. The port, that is written in CM-fortran, utilizes the CM/5 vector units and is partly programmed in cdpeac (vector unit assembly language). The package achieves 1560 encryptions/second/vector unit. This scales to 6,4 million encryptions per second on a large 1024 node machine. 800,000 - - - - - small 128 - - With this impressive performance, all combinations of 6 letters can be tried in less than an hour and all combinations of 6 lower-case letters can be tried in less than one minute. Congratulations, Jorgen Bo Madsen +-----------------------------------------------------------------------+ ! Jorgen Bo Madsen, Security Consultant ! ! UNI-C Lyngby, Danish Computing Centre for Research and Education ! ! DTH, Building 305, DK - 2800 Lyngby, ! ! Phone : +45-45-938355 ! ! Telefax: +45-45-930220 ! ! E-Mail : Jorgen.Bo.Madsen(a)uni-c.dk ! +-----------------------------------------------------------------------+ ------- End of Forwarded Message

1 0

encrypted anonymous traffic
by L. Detweiler 18 Aug '93

18 Aug '93

Mr. Wells: I strongly am against your policy of prohibiting encrypted traffic through your server, and your apparent monitoring of existing plaintext information. I believe you should make this severe & oppressive restriction (the former) and breach of privacy, confidentiality, and trust (the latter) clear in your introductory statements to your server. While providing this service of anonymity is commendable, it is worthless without minimum levels of functionality and assurance, and IMHO outlawing encrypted traffic is bordering on that line. You `defuse' J. Helsingius's suggestion of comparing your service with the post office by comparing it with the exchange of bombs in parcels, saying that `analogies are slippery'. Indeed, you have slipped out of this one and away from the crucial point. No one can send any `bomb' through mere text, and to compare harassing mail (which is definitely not to be condoned) to it is to expose your naive and self-serving view of the matter. I have a theory that one major motivation toward running such a server is a somewhat paternalistic desire to `monitor' traffic through one's server to one's `family'. Far better to do this with your own family than through a public service, where it is inappropriate, deplorable, and voyeristic. That you arbitrarily restrict traffic to that which you can read is a rather embarrassing indictment of your intentions, despite your lame protestations that just the `capability' is relevant. Anonymity and encryption are as interlinked as two sides of a hand. Who are you to shear one half away? Sincerely, L. Detweiler

7 6

Re: `Stalled' Progress
by remail＠tamsun.tamu.edu 18 Aug '93

18 Aug '93

At 2:36 AM 8/16/93 +0000, an12070(a)anon.penet.fi wrote: >building up all these things on student accounts is >commendable but a foundation of quicksand in the long run. Quicksand is fine if you use pontoons. We *are* a guerrilla operation, aren't we? Let me pay homage to those who have endured the risk of offering their student accounts for use as remailers, etc. We need more like you. I could get some bootleg student accounts, but I think the annoyance factor might outweigh the benefit of more resouces. And, as my anonymous posting implies, I'm not entirely sure I want to be out of the closet as a cypherpunk yet. >rumor has it >even soda.berkeley.edu ftp site (perhaps the most critical cypherpunk >element other than the mailing list) is being run off a student >account. This is indeed our great vulnerable point. We should attempt to decentralize it (at least have more backup). UNIX gurus- if I put PGP in my home directory, how do I make it available netwide? Does my sysadmin Another possibility - spring some real cash and get cycles and ftp support on netcom or something like it. How much would it cost? Is it cycles, space and access we need, money, or just someone to take charge? Once we got digital cash working, things have a better chance to become self-supporting and less at the mercy of university system administrators. How difficult would it be to get some resources (cycles, disk space, code) from Chaum's company Digicash? We could do an academic research project studying the feasibility of trade over internet, funded primarily by in-kind donations. Can we piggy-back on the netcash effort? >* the `i thought you were doing that' factor. Is this really a problem? I'm always pleasantly surprised when something gets done, even if I'm working on it. > >* to a large degree, despite the commandment `cypherpunks write code', >the `cypherpunks' have always gained their cohesion more from political >ideology than implementing tangible systems. I don't know about anyone else, but the tangibility did it for me. I used to be fatalistic about privacy etc. The tangible achievements of the cypherpunks have given me hope that there *is* a soft underbelly on that beast. Not that ideology isn't fun!

3 2