December 2003 - cypherpunks-legacy

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

CJR returned to sender
by Raph Levien 17 Dec '03

17 Dec '03

I got the CJR back today, envelope unopened (although the corner was torn so you could see there were t-shirts inside). "Returned to sender", it said, "Refused___, Unclaimed___". The address on the envelope reads: ATTN: Samuel L. Capino - 15 day CJR Defense Trade Analyst U.S. Dept. of State Office of Defense Trade Controls PM/DTC SA-6 Room 200 1701 N. Fort Meyer Drive Arlington, CA 22209-3113 Did I do something wrong, or did the Dept. of State decide it didn't want to deal with this CJR? Raph

2 1

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

RE: Netscape Logic Bomb detailed by IETF
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 books. Thanks. ahg3 ---------- From: perry[SMTP:perry@piermont.com] Sent: Tuesday, October 24, 1995 6:00 PM To: cypherpunks Subject: Re: Netscape Logic Bomb detailed by IETF anonymous-remailer(a)shell.portal.com writes: > I see that Perry is as charming as ever? And I see that you don't know what you are talking about. > Perry, I just don't think that it is wise to stick your head in the sand > and ignore a severe flaw in your algorithm, while actively misrepresenting > matters to those people who are not intimately familiar with the IETF. I wonder if you even know what the IETF is, since you seem to be waving around an organization I work in like it was a mass of chicken entrails. > Postscript isn't like any other language around. Operator names have no > special significance to the interpreter. You can't just "strip out" > dangerous commands. They aren't "reserved" in the sense that operator > names are in other languages, like COBOL or BASIC. > > In Postscript, operator names are simply keys into a LIFO dictionary. If, Mr. Anonymous, you can get a postscript interpreter to do I/O after you have stripped all the system calls that do file I/O out of the C code for the interpreter merely by invoking the names of the I/O commands in the postscript books, you have managed a feat beyond mere spoon bending and ought to be studied by the parapsychologists. In any case, Netscape doesn't write the postscript interpreters and doesn't have built in support for postscript and doesn't ship mailcap files that deal with postscript, so I'd say you are a crank worth ignoring. Perry

1 0

RE: USA Today Against ITAR & GAK
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: Cypherpunks Mailing List[SMTP:cypherpunks@toad.com] Sent: Tuesday, October 24, 1995 4:51 PM To: Cypherpunks Mailing List Subject: USA Today Against ITAR & GAK I'm pleased to report that USA Today editorializes today (Tuesday, Oct. 24, 1995) against both ITAR and GAK. They get the chronology of the SSL brute-forcing and PRNG seed prediction attacks on Netscape Navigator backwards, but they get many other things right in a fairly short editorial. I am certainly encouraged by this development. Someone at USA Today definitely got the message that the ITAR are a large obstacle to net security in the U.S. Some particularly apropos quotations (from pg. 12A): On ITAR: "[After the Netscape hacks] the perception of the Internet as insecure was indelible. That needn't be. Encryption software available right now is exponentially more powerful and could make code breaking virtually impossible. Its use is blocked by government export regulations that make the programs difficult if not impossible to market, even for domestic purposes." 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.... "The [GAK] system -- which the FBI and the Commerce Department declined to defend in an opposing view to this editorial [...]" Now I find that surprising. Since when does the FBI not even try to justify Clipper and its descendants in the newspapers ? For foreign readers, I'll note that USA Today has easily the largest national circulation of any daily newspaper in the U.S. [Letters to the editor can be emailed to usatoday(a)clark.net; they want you to give your snail-mail address and home and work phone numbers so they can check your identity.] -Futplex <futplex(a)pseudonym.com>

1 0