December 2003 - cypherpunks-legacy

RE: MD5 weakness ? [was Re: Netscape Log
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: hallam[SMTP:hallam@w3.org] Sent: Tuesday, October 24, 1995 1:14 PM To: Dr. Frederick B. Cohen; cypherpunks Cc: hallam Subject: Re: MD5 weakness ? [was Re: Netscape Logic Bomb detailed by IETF] Precedence: bulk >As to weaknesses, I seem to remember that someone managed to forge a >modification to a program used to observe networks on a Sun so that it >had the same MD5 checksum as the official trusted version. But whether >this is real is not strictly the issue. Ron has not mentioned such an event to me and if that were the case I would seriously doubt that he would not have been told about it. The only comment he generally makes is that he wrote MD5 because "MD4 was making me nervous". >In the case of the trust being placed in MD5 by Netscape, the assumption >being made (without adequate support as far as I can tell) is that an >MD5 checksum cannot be forced, through a chosen plaintext attack, to Netscape do not simply use the MD5 of the message, they are using (as I understand it) the PKCS#1 standard for makoing the signature. If not they probably have severe problems. >There has been no limit given by anyone on this list to the level of >trust they place in MD5. Several people have posted (without >contention) that MD5 is sufficiently trustworthy to trust billions of >dollars in commerce to it's being able to prevent a selected plaintext >attack as eluded to above. NIST and the NSA trusted MD4 sufficiently to base SHA upon it. SHA is preferable in many ways to MD5, it has a different approach to extending the scheduling and resist differential cryptanalysis. There is a problem with the compressor function of MD5 which I dislike. This is fairly irrelevant though since SSL allows other digests to be used. Phill

1 0

IT View of Worldwide Electronic Commerce Conference
by guthery＠austin.sar.slb.com 17 Dec '03

17 Dec '03

Robert Hettinga wonders ... >Did anyone go to the > >"Worldwide Electronic Commerce Law, Policy, Security and Controls Conference" ? > >It was in Bethesda October 18 - 20. > >Just curious. Sponsored by a lot of Big Cheese (ABA, HLS, NIST, UNCITL, >SPA, ETC, ETC, ETC). I did and here's a view from IT; i.e. not law or marketing. The conference was two-track so by definition I only attended 1/2 the sessions. The high points ... - the Web will support commerce next year from modest (multi-$1,000) down to micro (sub-penny) transactions - the U.S. Government is trying to trade 64-bit keys for escrow but folks aren't buying it; Dorthy Denning gave a very weak "the sky is falling" talk. - Intel is building systems and secure infrastructure software; Microsoft may start to feel trapped between Intel and Netscape. - current copyright law seems up to the task of handling the Web but contract law may need some updating - iris scanning seems to be the leading biometric; there is a PCMCIA card that does fingerprints including pores which I learned are better than ridges for identification - nobody had any insight on transnational data flow, encrypted or otherwise - Verisign (a spin-off of RSA) is selling Digital IDs and running a Certification Authority; see http://www.verisign.com - the Swedes have a very aggressive Digital ID system on the air; see http://www.cost.se - X.509 seems to be the de facto and de jure certificate standard; current work is at ftp://NC-17.MA02.Bull.com in /pub/OSIdirectory/Certificates - RSA for encryption and DSA for signatures were the encryption technologies of preference; PGP was occassionally acknowledged to be one of the best available but strangely went undiscussed. Good quote: "Commercial DES (for export) with 40 bit keys is a joke. Don't even think about it." - other relevant URLs: www.ms.com www.terisa.com www.ssa.gov Most of the security focus of the conference was on authentication.

1 0

Re: Anonymity: A Modest Proposal
by edgar＠highnrg.sbay.org 17 Dec '03

17 Dec '03

Herb Sutter comments on Modemac's proposal, At 04:58 10.18.1995 -0700, Modemac wrote: > 1) A person writes a message and encrypts it with PGP. Using a set public key? Which would mean the remailers all share the same pub/pri key pair (or pieces thereof)? You'll have to come up with a good way of maintaining this secret, since if you're not careful it could be compromised by something as simple as an attacker's trying to attach a new remailer to the remailer group or physically attack any existing remailer. But using a shared key isn't necessary. Each remailer can have it's own key. The message can be encrypted using PGP's function of encrypting with multiple public keys. PGP versions 2.63ui and 2.6.3i, now under development, will even have the ability to encrypt to a whole -file- of keys, one key per line. Message senders can use all the scanning remailer keys, or some subset. Scanners will either skip over or forward msgs they can't decrypt. Also keep in mind that under this first layer of encryption is just the address of another remailer, which could, in turn, either forward to another remailer, or back to the anon newsgroup. --- edgar(a)HighNRG.sbay.org Keep Freestyle Alive!

1 0

Re: IT View of Worldwide Electronic Commerce Conference
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 4:20 AM 10/25/95, guthery(a)austin.sar.slb.com wrote: >I did and here's a view from IT; i.e. not law or marketing. The conference >was two-track so by definition I only attended 1/2 the sessions. I *love* this place! Thanks, very much. Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

Re: CJR returned to sender
by liberty＠gate.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Sameer writes: <snip> >Unless the crypto export laws and the laws surrouding CJRs have a >provision for 'jokes', then the return of Raph's properly formed CJR >request seems to me rather, um, illegal? This may open up some interesting Freedom Of Information Act possibilities for Raph, (but IANAL). A FOIA request usually isn't very fast, but they can be interesting, and even (occasionally) funny. Raph's situation sounds promising, if my hypothetical FOIA isn't squelched by the "national security" exception. This seems unlikely, if Tim is correct about the shirt's machine-unreadability. > The law, in my opinion, is a joke. Does that mean I can ignore >it? Members of the legal community, including judges, are sometimes known as "humor-impaired" regarding the many laws that clearly *are* jokes to many people. Generally the "crimes" mentioned in these laws have no individual victims -- see Abe Lincoln .sig quote below. JMR -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Freedom isn't Freeh iQCVAwUBMI443W1lp8bpvW01AQElyQP+N1oVVp8GImGbLF4v8cqHNFAmHSC8tmHW F5+JCQZgFMX8YKI5ToiuCFQotL6V3fbv/cqz5Fzb0jLvmCr6cRIsGx3CvC9Q8X8U u42i/3WRCXauxN+eqywaMvGftV6YiFf7LMx2PAAXJ17HUlajnA5aQ9/h4NeH8yJC kaClkbaUiog= =WZyO -----END PGP SIGNATURE----- Regards, Jim Ray "A prohibition law strikes a blow at the very principles upon which our government was founded" -- Abraham Lincoln ----------------------------------------------------------------------- PGP key Fingerprint 51 5D A2 C3 92 2C 56 BE 53 2D 9C A1 B3 50 C9 C8 Key id. # E9BD6D35 James Milton Ray <liberty(a)gate.net> IANAL ----------------------------------------------------------------------- Help Phil! email zldf(a)clark.net or see http://www.netresponse.com/zldf _______________________________________________________________________

1 0

RE: 80 bits from 40 bits -- NOT
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: baldwin[SMTP:baldwin@RSA.COM] Sent: Tuesday, October 24, 1995 2:39 PM To: cypherpunks Subject: 80 bits from 40 bits -- NOT Well, let me eat my words. Unless all layers turn on encryption at the same time, and there is not predictable text that passes from one layer to the next, adding encryption at each layer cannot substantially improve the size of the key space. Consider two layers each of which has a verifiable header and a body of encrypted text. By "verifyable", I mean that it contains enough redundancy to recognize a correct decryption of the cipher added by the lower layer. For example, a header that included a content type field and a length field could be examined to see if it looked reasonable, and thus confirm a guess at the lower level's cipher. Plaintext-Body-1 | Layer-1-cipher | Header-1, Encrypted-Body-1 | Layer-2-cipher | Header-2, Encrypted-Body-2 To crack this system, an attacker does brute force search of the keyspace for the layer-2-cipher, for each key check the decrypted Header-1 value to see if it looks OK, if not, continue, otherwise start searching the keyspace for the Layer-1-cipher given the candidate for the Encrypted-Body-1 produced by the guess at the Layer-2-cipher key. Clearly, if you have several layer 2 blocks and they all have good looking values for the Header-1, then the Layer-2-cipher key is correct. The summary is that two layers of 40 bit ciphers with the first layer adding some verifiable information, has the effect of adding at most one bit to the effective keysize (doubling the amount of work). It DOES NOT increase the keysize to 80 bits. --Bob Baldwin ______________________________ Reply Separator _________________________________ Subject: 80 bit security from 40 bit exportable products Author: "baldwin" <baldwin(a)RSA.COM (Robert W. Baldwin)> at INTERNET Date: 10/24/95 10:52 AM Long ago vendors should have put encryption into network layer products, but for a variety of reasons that effort was delayed or discouraged. One effect of this lack is that almost every layer of the network stack is adding its own encryption. For example, the HTTP session layer added S-HTTP and the TCP transport layer added SSL. Soon we will have network layer encryption with IPsec. The vendors for each layer can export a product that uses ciphers with 40 bit keys. A user can then combine multiple products to get more than 40 bits worth of security. For example, a web client might fetch an S-HTTP page over an SSL protected link via a firewall that supports IPsec tunnels. That's three 40 bit keys protecting the data over the internet link (of course, this may not be equivalent to a 120 bit cipher, that depends on the details of the cipher systems and independence of the key setups). Interesting possibilities. --Bob Baldwin

1 0

RE: textbooks
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Patrick Horgan[SMTP:patrick@Verity.COM] Sent: Tuesday, October 24, 1995 2:21 PM To: sandoval Cc: cypherpunks Subject: Re: textbooks I'm Cc:ing this to cypherpunks since I've gotten a lot of requests for this information. > From: sandoval(a)cic.teleco.ulpgc.es (Juan Domingo Sandoval Gonzalez) > > Dear Patrick, > Thanks for yor info about "Network Security Private Communication > in a PUBLIC World" by Kaufman, Perlman and Speciner. > To buy it I need to know Who published it. > Do you know the Editor house? > "Network Security - PRIVATE Communication in a PUBLIC World", 1995, Prentice Hall PTR, ISBN 0-13-061466-1, by Charlie Kaufman, Radia Perlman, and Mike Speciner. This book is amazing. It explains hard concepts in ways that make them seem obvious. I can't state this too emphatically. The style of the book is conversational, approachable and a fun read, while at the same time maintaining technical exactness to the point that you can implement algorithms from the discussions in this book, (and understand how they work.) 17.6.2 Coping with Export Controls is very interesting, detailing the weird hoops that Lotus jumped through to retain as much security as possible while still meeting export requirements. The authors make the point that what happens to you when you go through this process is almost random depending on the times as well as the individual person you deal with. The ANS.1 section is blunt about the space problems, and indeed much of the book is refreshingly blunt about the stupidities involved in a lot of this stuff. The quick proof of why the initial and final permutations add nothing to the security of DES is presented in an informal and quite obvious sidebar. The comment is made that by the same argument the permutation of the key in the generating of per-round keys also adds nothing to security. It also includes homework and would be a wonderful textbook. Here's an abbreviated version of the TOC. Note that the real index is much richer than this. I've given the complete version of section 3.3 to illustrate. All typos are mine. I think we can no longer refer to Bruce's book as the Bible, but must refer to the two books as the Scriptures;) Could someone refer me to some good crypto oriented math books? Preferably something as readable as this:) Chapter 1 Introduction 1.1 Roadmap to the book 1.2 What type of book is this 1.3 Terminology 1.4 Notation 1.5 Primer on Networking 1.6 Tempest 1.7 Firewalls/Security Gateways 1.8 Key Escrow for Law Enforcement 1.9 Key Escrow for Careless Users 1.10 Viruses, Worms, Trojan Horses 1.11 The Military Model of Security 1.12 Legal Issues Chapter 2 Introduction to Cryptography 2.1 What is Cryptography 2.2 Breaking an Encryption Scheme 2.3 Types of Cryptographic Functions 2.4 Secret Key Cryptography 2.5 Public Key Cryptography 2.6 Hash Alogorithms 2.7 Homework Chapter 3 Secret Key Cryptography 3.1 Introduction 3.2 Generic Block Encryption 3.3 Data Encryption Standard (DES) 3.3.1 DES Overview 3.3.2 The Permutations of the Data 3.3.3 Generating the Per-Round Keys 3.3.4 A DES Round 3.3.5 The Mangler Function 3.3.6 Weak and Semi-Weak Keys 3.3.7 What's So Special About DES? 3.4 International Data Encryption Algorithm (IDEA) 3.5 Using Secret Key Cryptography in Protocols 3.6 Encrypting a Large Message 3.7 Generating MICs 3.8 Multiple Encryption DES 3.9 Homework Chapter 4 Hashes and Message Digests 4.1 Introduction 4.2 Nifty Things to Do with a Hash 4.3 MD2 4.4 MD4 4.5 MD5 4.6 SHS 4.7 Homework Chapter 5 Public Key Algorithms 5.1 Introduction 5.2 Modular Arithmatic 5.3 RSA 5.4 Diffie-Hellman 5.5 Digital Signature Standard (DSS) 5.6 Zero Knowledge Proof Systems 5.7 Homework Problems Chapter 6 Number Theory 6.1 Introduction 6.2 Modular Arithmatic 6.3 Primes 6.4 Euclid's Algorithm 6.5 Chinese Remainder Theorem 6.6 Zn* 6.7 Euler's Totient Function 6.8 Euler's Theorem 6.9 Homework Problems Chapter 7 Authentication Problems 7.1 Password-Based Authentication 7.2 Address-Based Authentication 7.3 Cryptographic Authentication Protocols 7.4 Who is Being Authenticated 7.5 Passwords as Cryptographic Keys 7.6 Eavesdropping and Server Database Reading 7.7 Trusted Intermediaries 7.8 Session Key Establishment 7.9 Authorization 7.10 Delegation 7.11 Homework Chapter 8 Authentication of People 8.1 Passwords 8.2 On-Line Password Guessing 8.3 Off-Line Password Guessing 8.4 How Big Should a Secret Be? 8.5 Eavesdropping 8.6 Passwords and Careless Users 8.7 Initial Password Distribution 8.8 Authentication Tokens 8.9 Physical Access 8.10 Biometrics 8.11 Homework Chapter 9 Security Handshake Pitfalls 9.1 Login Only 9.2 Mutual Authentication 9.3 Integrity/Encryption for Data 9.4 Mediated Authentication (with KDC) 9.5 Bellovin-Merritt 9.6 Network Login and Password Guessing 9.7 Nonce Types 9.8 Picking Random Numbers 9.9 X.509 Problem 9.10 Performance Considerations 9.11 Authentication Protocol Checklist 9.12 Homework Chapter 10 Kerberos V4 10.1 Introduction 10.2 Tickets and Ticket-Granting Tickets 10.3 Configuration 10.4 Logging Into the Network 10.5 Replicated KDCs 10.6 Realms 10.7 Interrealm Authentication 10.8 Key Version Numbers 10.9 Encryption for Privacy and Integrity 10.10 Encryption for Integrity Only 10.11 Network Layer Addresses in Tickets 10.12 Message Formats 10.13 Homework Chapter 11 Kerberos V5 11.1 ASN.1 11.2 Names 11.3 Delegation of Rights 11.4 Ticket Lifetimes 11.5 Key Versions 11.6 Making Master Keys in Different Realms Different 11.7 Optimizations 11.8 Cryptographic Algorithms 11.9 Hierarchy of Realms 11.10 Evading Password-Guessing Attacks 11.11 Key Inside Authenticator 11.12 Double TGT Authentication 11.13 KDC Database 11.14 Kerberos V5 Messages 11.15 Homework Chapter 12 Electronic Mail Security 12.1 Distribution Lists 12.2 Store and Forward 12.3 Security Services for Electronic Mail 12.4 Establishing Keys 12.5 Privacy 12.6 Authentication of the Source 12.7 Message Integrity 12.8 Non-Repudiation 12.9 Proof of Submission 12.10 Proof of Delivery 12.11 Message Flow Confidentiality 12.12 Anonymity 12.13 Containment 12.14 Annoying Text Format Issues 12.15 Names and Addresses 12.16 Old Messages 12.17 Homework Chapter 13 Privacy Enhanced Mail (PEM) 13.1 Introduction 13.2 Establishing Keys 13.3 Some PEM History 13.4 Certificate Hierarchy 13.5 Certificate Revocation Lists (CRLs) 13.6 X.509 Certificates and CRLs 13.7 Reformatting Data to Get Through Mailers 13.8 General Structure of a PEM Message 13.9 Encryption 13.10 Source Authentication and Integrity Protection 13.11 Multiple Recipients 13.12 Bracketing PEM Messages 13.13 Remote Distribution List Exploders 13.14 Forwarding and Enclosures 13.15 Canonicalization 13.16 Unprotected Information 13.17 Message Formats 13.18 DES-CBC as MIC Doesn't Work 13.19 Homework Chapter 14 PGP (Pretty Good Privacy) 14.1 Introduction 14.2 Overview 14.3 Key Distribution 14.4 Efficient Encoding 14.5 Certificate and Key Revocation 14.6 Signature Types 14.7 Your Private Key 14.8 Key Rings 14.9 Anomalies 14.10 Object Formats Chapter 15 X.400 15.1 Overview of X.400 15.2 Security Functions Possible with X.400 15.3 Structure of an X.400 Message Chapter 16 A Comparison of PEM, PGP, and X.400 16.1 Introduction 16.2 Certificate Hierarchy 16.3 Certificate Distribution 16.4 Encryption 16.5 Encoding of Transmitted Messages 16.6 Cryptographic Algorithms Supported 16.7 Recipients with Multiple Keys 16.8 Mail-Intermediary-Provided Functions Chapter 17 More Security Systems 17.1 NetWare V3 17.2 NetWare V4 17.3 KryptoKnight 17.4 SNMP 17.5 DASS/SPX 17.6 Lotus Notes Security 17.7 DCE Security 17.8 Microsoft Security 17.9 Network Denial of Service 17.10 Clipper 17.11 Homework Bibliography Glossary Index _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________ /

1 0

RE: Pointer to article on ex parte searc
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Rich Graves[SMTP:llurch@networking.stanford.edu] Sent: Tuesday, October 24, 1995 2:21 PM To: cypherpunks Subject: Pointer to article on ex parte search & sezure That's where somebody, e.g. Microsoft or the Church of Scientology, gets US Federal Marshals to seize your computer. Article <46j4t6$6od(a)newsbf02.news.aol.com> in alt.religion.scientology is a good article by Adam S. Bauman of the Los Angeles Times. You might find it interesting, but not quite relevant enough to post the whole thing here. -rich

1 0

RE: MD5 concerns, was Re: Netscape Logic
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Patrick Horgan[SMTP:patrick@Verity.COM] Sent: Tuesday, October 24, 1995 1:08 PM To: fc Cc: cypherpunks Subject: MD5 concerns, was Re: Netscape Logic Bomb detailed by IETF > channel. I think that Netscape uses an MD5 checksum which the members > of this list seem to place unlimited trust in (incorrectly in my view, This is the second time you've implied that an MD5 checksum might not be as secure as we think. Could you share your thinking on this? I had believed from reading the algorithm that it's not possible to predict how a change in the input will affect the checksum. Given a modified version of netscape for example, how would you change some non-critical portion of the code to get the same checksum that the original should have. I suppose that give n bits of non-critical space in the code, (non-critical meaning that changing them will have no effect on the execution of the code, and assuming that you don't want to change the length of the code), that you could try all possible combinations of those bits, or 2^n trials and see if you get the correct MD5 checksum. If you do, then on average you'd actually only have to try 2^(n-1) trials. What if you don't? What would you do then? MD5 produces a 128 bit output, and it would seem likely that this would be hard. As far as I know there are no known attacks for any MDx algorithms in spite of Ron's worries about MD4. It's a subject of on-going research though, and it is only "conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any messages having a given prespecified target message digest." (RFC 1321) So, if you have newer information, or pointers to any papers, (other than the ben Boer and Bosselaers papers), could you let me know? Thanks, Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________ /

1 0

RE: CRYPTO '96 CFP
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Matt Blaze[SMTP:mab@research.att.com] Sent: Tuesday, October 24, 1995 5:22 PM To: cypherpunks Subject: CRYPTO '96 CFP Sender: owner-cypherpunks(a)toad.com Precedence: bulk CRYPTO '96 August 18-22, 1996, Santa Barbara, California, USA CALL FOR PAPERS General Information: Crypto '96, the Sixteenth Annual Crypto Conference, is organized by the International Association for Cryptologic Research (IACR), in cooperation with the IEEE Computer Society Technical Committee on Security and Privacy, and the Computer Science Department of the University of California, Santa Barbara. Original papers are solicited on all technical aspects of cryptology. Instructions for Authors: Please send a cover letter, one title page and 16 copies of an extended abstract. They must be received by the Program Chair at the address given below no later than February 14, 1996 (or postmarked by February 4, 1996 and sent via airmail). The cover letter must state: "This paper does not substantially duplicate work that any of the authors have published elsewhere or have submitted in parallel to any other conference or workshop that has proceedings." The title page should contain the title, the names of the authors, their postal and e-mail addresses and the short abstract; it should be made clear who is the author to whom correspondence should be sent. The first page of the extended abstract should be an informal one-page statement (that will not be published in the Proceedings) describing the content of the oral presentation that will be given at Crypto '96 in the event the paper is accepted (this statement is expected to be different from the short abstract of the paper). This page and the extended abstract must be ANONYMOUS, i.e., they must contain no indication whatsoever of the identity of the author(s). The main body of the extended abstract should start with the title, short abstract, and list of keywords. This should be followed by a succinct statement appropriate for a non-specialist reader specifying the subject addressed, its background, the main achievements, and their significance to cryptology. Technical details directed to the specialist should then follow. Submissions are limited to 10 single-spaced pages of 11pt type, not counting the bibliography and clearly marked appendices. Since referees are not required to read the appendices, the paper should be intelligible without them. The paper including bibliography and appendices must run to no more than 15 pages. These limits will be strictly enforced. Unfortunately, because of the burdens on the Program Committee and the need to keep strictly to the time schedule, we will have to summarily reject any submission not in keeping with the above instructions. Authors are encouraged to make 2-sided copies if possible. Please send submissions by post; unfortunately, we cannot accept submissions by e-mail or fax. Notification of acceptance or rejection will be sent to authors on April 22, 1996. Conference Proceedings: Proceedings will be available at the meeting. They will be published in the Springer-Verlag Lecture Notes in Computer Science. Clear instructions about the final copy will be sent to authors of accepted papers. The final copies of the accepted papers will be due on June 1, 1996. Final papers arriving too late will be removed from the main program. Authors of accepted papers must guarantee that their paper will be presented at the conference. Stipends: A limited number of stipends are available to those unable to obtain funding to attend the conference. Students whose papers are accepted and who will present the paper themselves are encouraged to apply if such assistance is needed. Requests for stipends should be addressed to the general chair. Send submissions to: Neal Koblitz, Program Chair, Crypto '96 Dept. of Mathematics, Box 354350 University of Washington Seattle, WA 98195 U.S.A. Internet: koblitz(a)math.washington.edu Phone: 1-206-543-4386 For other information contact: Richard Graveman, General Chair, Crypto '96 Bellcore 444 Hoes Lane RM 1K-221 Piscataway, NJ 08854 U.S.A. Internet: rfg(a)ctt.bellcore.com Phone: 1-908-699-4611 Program Committee: Neal Koblitz, Chair (Mathematics, University of Washington, USA) Mihir Bellare (Computer Science, University of California at San Diego, USA) Josh Benaloh (Microsoft, USA) Matt Blaze (AT&T Bell Laboratories, USA) Johannes Buchmann (Computer Science, Universitaet des Saarlandes, Germany) Don Coppersmith (IBM Research, USA) Joan Feigenbaum (AT&T Bell Laboratories, USA) Andrew Klapper (Computer Science, University of Kentucky, USA) Lars Knudsen (Computer Science, Ecole Normale Superieure, France) Peter Landrock (Mathematics, Aarhus University, Denmark) Tsutomu Matsumoto (Electrical & Computer Engineering, Yokohama National University, Japan) Chris Mitchell (Computer Science, University of London, UK) Paul Van Oorschot (Bell-Northern Research, Canada) Bart Preneel (Catholic University at Leuven, Belgium) Rainer Rueppel (R3 Security Engineering, Switzerland) Jacques Stern (Computer Science, Ecole Normale Superieure, France)

1 0