December 2003 - cypherpunks-legacy

Elementrix's so-called "Power One Time Pad"
by Flame Remailer 17 Dec '03

17 Dec '03

Essentially what these guys are selling is a secret key algorithm in which the key for any given message is a function of some initial seed value, and of hashes of all previous messages transmitted between the two parties. So in theory, to break the code, one would need to know not only their initial key, but also all of the messages trasmitted between them so far. A similar result can be achieved by encrypting with PCBC, or other feedback mode involving plaintext, and carrying the IV from the end of one session to the beginning of the next. This is not, of course, a one-time pad, and hardly "groundbreaking" or "revolutionary". While such a system could be designed securely in theory, the folks at Elementrix appear to have little experience at designing secure cryptographic systems. Cryptographic systems designed by such novices frequently have bugs in the implementation which weaken the security offered, or have statistical weaknesses which allow cryptanalytic attack. Elementrix has offered no assurances that they have tested their system for either. Beware of snake oil.

1 0

CRYPTO '96 CFP
by Matt Blaze 17 Dec '03

17 Dec '03

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

Pointer to article on ex parte search & sezure
by Rich Graves 17 Dec '03

17 Dec '03

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: textbooks
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

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 | \___________________________________________________________\)__________/

2 1

80 bits from 40 bits -- NOT
by baldwin 17 Dec '03

17 Dec '03

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: How can e-cash, even on-line cleared, protect payee identity?
by Hal 17 Dec '03

17 Dec '03

1 0

What is needed for S/MIME remailer ?
by baldwin 17 Dec '03

17 Dec '03

The other day I was wondering what it would take to make an anonymous remailer for an S/MIME client. Implementing S/MIME from scratch is a lot of work given the lack of a public domain implementation, but it seems that a remailer could be built on top of a commercial email product that supported S/MIME. The question is: What features should a commercial S/MIME email product have to make it easy to support a remailer? Are there a small set of command line options that would greatly simplify a remailer implementation? --Bob Baldwin

4 3

Re: Verification of Registration
by Lynne L. Harrison 17 Dec '03

17 Dec '03

At 11:02 AM 10/24/95 -0500, you wrote: >Everybody who receives mail from cypherpunks(a)toad.com received this >message becuase the message was addressed to >cypherpunks(a)toad.com. Apparently someone may have >joined this 'group' or service and used the cypherpunks address as >the e-mail address. Mayhap the cypherpunks(a)toad.com / cypherpunks >userid/password. > >This would be my guess, of course. > >Does anybody know what this service does? > Makes sense given the numbers that also received the message. C|Net has a web site and a weekly program on cable about the Net. I saw it {the show) once. Nothing to recommend - silly stuff like URL's for the weather. Regards - Lynne ******************************************************************** Lynne L. Harrison, Esq. Poughkeepsie, New York lharrison(a)mhv.net "Say not, 'I have found the truth', but rather, 'I have found a truth.'" - Kahlil Gibran from "The Prophet" ********************************************************************

1 0

BlackNet Meets Stanford Law School
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 8:51 PM 10/24/95, Futplex wrote: >On GAK: > "[...] key escrow [...] may sound reasonable, but apply that > reasoning to more mundane areas of life. What the government > is saying is yes, you can put bars on your windows, locks on > your doors and put your jewelry in a safe, but you have to > give us the keys and the combination because you might be a > crook." > >That phrasing sounds rather familiar.... Hmmmhhh...yes, doesn't it though? By the way, I gave a talk at Stanford Law School last week, to Professor Margaret Radin's seminar on "Cyberspace and the Law." They had been reading a bunch of papers and reprints on Clipper, PGP, and crypto policy, including pieces by both me and Michael Froomkin (whose long paper is apparently becoming widely read for crypto-legal discussions). I was using the "curtain" metaphor for key escrow, describing a situation where the government might insist people only install curtains that have a secret invisibility mode, where the curtains become transparent to them only. It's more than just becoming transparent completely, as with key escrow one does not know that one's communications have been rendered readable...unless they eventually tell you, as they are _supposed_ to do with some classes of wiretaps (but not others, as in foreign intelligence surveillance). One of the students came up with a nice extension of this metaphor: using one's own system inside a key escrow wrapper (also called "superencryption") is like adding a second set of curtains inside the first set. An obvious point, but a nice metaphor that makes the point to one and all: the mandatory key escrow system, if adopted, would mandate the use of transparent-mode curtains and would ban (or try to) the use of additional sets of curtains. (What about internal room dividers which obscure the view into one's house that the cops want? The crypto parallels to this are interesting.) By the way, Professor Radin made an interesting comment at the end of the class. I'm paraphrasing, and any loss of her actual intended meaning may be my fault, so don't take this as gospel. She said she had previously thought that the implications of strong crypto would be "handled normally" within the context of markets and courts, but that after hearing my description of many issues (*) she now has doubts that the conventional legal system and conventional market system will be able to handle normally the implications of strong crypto. (By handle normally, I took her to mean in the way that several other recent technological advances have been handled without significant disruptions, in an evolutionary way.) (* The issues are the usual suspects: anonymous digital cash, remailers, information markets, copyrights, markets that benefit from untraceable communication, the BlackNet experience, the utter unbreakability of long-enough keys, and so on.) --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

2 1

Get rid of this stuff, please...
by an370736＠anon.penet.fi 17 Dec '03

17 Dec '03

To: cypherpunks(a)toad.com Subject: Re: Welcome to c|net From: anon-remailer(a)utopia.hacktic.nl (Name Withheld by Request) Date: Tue, 24 Oct 1995 20:10:07 +0100 > From cypherpunks(a)toad.com Tue Oct 24 09:03:00 1995 > Received: from cnet.com (central.cnet.com [204.188.123.10]) by > orpheum.cnet.com (8.6.12/8.6.12) with ESMTP id JAA10708 for > <verify(a)orpheum.cnet.com>; Tue, 24 Oct 1995 09:03:00 -0700 > Received: from longs.lance.colostate.edu by cnet.com via ESMTP > (8.6.12/940518.SGI.central) > for <verify(a)cnet.com> id OAA10916; Tue, 24 Oct 1995 14:53:01 GMT > Received: from [204.131.233.49] (p49.Denver1.dialup.csn.net > [204.131.233.49]) by longs.lance.colostate.edu (8.6.12/8.6.5a (LANCE > Revision: 1.3)) with SMTP id KAA07689 for <verify(a)cnet.com>; Tue, 24 Oct > 1995 10:02:06 -0600 To Someone in charge. Please UNSUBSCRIBE to this stuff for us, please.

1 0