December 2003 - cypherpunks-legacy

Re: US Fascist Dictatorship?
by snyderra＠dunx1.ocs.drexel.edu 17 Dec '03

17 Dec '03

At 4:21 PM 9/14/94, Duncan Frissell wrote: >So is the US about to grab all the guns, seal the borders, make foreign >trade a crime, and change the color of the money? And the link to cryptography is what? Bob -- Bob Snyder N2KGO MIME, PGP, RIPEM mail accepted snyderra(a)post.drexel.edu PGP & RIPEM keys on key servers When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.

1 0

RC4 Legal Issues
by Patrick G. Bridges 17 Dec '03

17 Dec '03

So what does the publication of the reverse engineering of RC4 mean legally? AT&T claimed trade sevret and copyright protection over code that was pretty well known in the BSDI case... Can RC4 still be construed as a trade secret or proprirtary to RSADS and Bizdos or are, as I understand from previous messages, we free to use RC4 now (ignoring the submarine patent issue)?

6 8

ANNOUNCEMENT: Bionomics 2nd Annual Conference, "The Next Economy- An Evolving Information Ecosystem"
by conference94/Bionomics 17 Dec '03

17 Dec '03

CONFERENCE ANNOUNCEMENT * * * * * * * * * * * * * * * * * * * * * * * * * * "World class... I found the spontaneous cross-pollination of ideas extremely valuable." (Gilbert F. Amelio, President and CEO, National Semiconductor) How is NEW TECHNOLOGY transforming the economy? How will IT alter the fundamental qualities of economic life? Come explore the truths and consequences of the infoweb with us. Because 19th Century answers can't solve 21st Century problems. You are invited to attend the Bionomics Institute's 2nd Annual Conference: The Next Economy - An Evolving Information Ecosystem October 21-22,1994 San Francisco Marriott "It will rock your world." (Bill Melton, Founder & Former Chairman, Verifone) This two day event brings together leading-edge thinkers and doers from a remarkable variety of disciplines for fresh insights into the technological, economic, and political implications of the epochal shift from the Machine Age to the Information Age. Who We Are * * * * * * * * * * * * * * * * * * * * * * * * * * "Outstanding!" (Irwin Glenn, Principal Technologist, Massively Parallel Processing, Oracle Corporation) At The Bionomics Institute, we provide new ways to envision the emerging Information Age economy and the changes it will bring to our personal lives, business strategies and public policy. We'll help you comprehend what is happening and navigate the uncharted territory ahead. Please join keynote speakers >>>Walter Williams, leading free-market thinker, economist and defender of personal liberty. Prof. Williams has a nationally syndicated newspaper column and is regularly featured on *Nightline*, *Face the Nation*, *Crossfire*, *Nightly Business Report*, *Wall St. Week* and *MacNeil-Lehrer*. >>>Tom Ray, artificial life pioneer, evolutionary biologist, and creator of the first Internet reserve for the evolution of digital organisms. Prof. Ray's groundbreaking work has been featured in *Newsweek*, *Science*, *Wired*, *The Economist* and many other publications. as well as >>John Perry Barlow, co-founder, Electronic Frontier Foundation, leading defender of Information Age privacy >>Admiral John Donegan (ret.), Commander, Naval Command, Control and Ocean Surveillance Center >>James Dowe, President, Excalibur Technologies >>Jeffrey Eisenach, President, Progress and Freedom Foundation >>Dee Hock, founder and CEO emeritus, VISA >>Bernardo Huberman, Area Manager, Dynamics of Computation Group, Xerox Palo Alto Research Center >>Brewster Kahle, Pres. WAIS Inc., premier Internet navigation technology >>Joel Kotkin, author of *TRIBES: How Race, Religion & Identity Determine Success in the New Global Economy* >>Don Lavoie, Director, Program on Social & Org'l Learning, George Mason Univ. >>Axel Leijonhufvud, Director, Center for Computable Economics, UCLA >>Randal O'Toole, Director & forest economist, Cascade Holistic Economic Consultants >>Virginia Postrel, Editor, *Reason* magazine- "Free Minds & Free Markets" >>Michael Rothschild, author of Bionomics, columnist for *Forbes ASAP* and *Upside* and some of the smartest people you've never heard of. For those who still need convincing * * * * * * * * * * * * * * * * * * * * * * * * * * If you weren't there last year, you already missed one conference that "Is the second best conference I attend each year." (Dan Lynch, Chairman and Founder, INTEROP conference, Sante Fe Institute Trustee) "Provided more info in five minutes than seven days of a standard business conference." (Dave Padden, Founder, Heartland Institute, and Board Member, Cato Institute) "Taught us lessons we use every day." (Leo Linbeck, Jr., Chairman & CEO, Linbeck Corporation, and former Chairman, Federal Reserve Bank of Dallas) "Was one of the most well organized and exciting programs I have ever attended." (John Baden, Chairman, Foundation for Research on Economics & the Environment) Has a "high-powered exchange of ideas...during two intense days." (Robert Poole, Jr., President, Reason Foundation) Don't miss another. SIGN ME UP! * * * * * * * * * * * * * * * * * * * * * * * * * * San Francisco Marriott October 21-22, 1994 Become a sponsor and receive an invitation to the VIP speakers' reception before the conference and a special mention in the program, as well as your conference attendance (and The Bionomics Institute's deepest gratitude). $1,000 Sponsor $ 345 Regular $ 295 Early (by 9/15) $ 100 Student/Non-Profit Register by 9/15 (VISA/Mastercard/Checks) and receive $50 off plus a copy of "Pre-existing Condition" -- a bionomic analysis of health care policy The Bionomics Institute 415/454-1000 (voice) 415/454-7460 (fax) Conference94(a)Bionomics.org Please email, fax or phone the following information Name: Title: Organization: Address1: Address2: Address3: Voice: Fax: Credit Card: Expiration: TOTAL AMOUNT ($): * * * * * * * * * * * * * * * * * * * * * * * * * * The Economy: It's Alive!

1 0

Re: US Fascist Dictatorship?
by frissell＠panix.com 17 Dec '03

17 Dec '03

>Just wait until you become a target of the DoJ Forfieture Superfund... Unsiezable assets can't be siezed. Since each person represents a unique nexus of relationships, it is easier for that person to exercise control over those relationships than it is for an outside party to penetrate the nexus. >It may not be exactly like the prediction but there are lots of things that >Huxley simply did not think about or didn't exist when the book was written. Not Brave New World -- 1984. >The road to Hell is paved with good intentions. Not to mention the National Defense Highways Act of 1956. DCF

1 0

(fwd) A new PGP
by paul＠hawksbill.sprintmrn.com 17 Dec '03

17 Dec '03

For those of you who haven't already seen this -- my apologies for the post if you already have.... Forwarded message: > From: pgut1(a)cs.aukuni.ac.nz (Peter Gutmann) > Newsgroups: alt.security.pgp,sci.crypt,talk.politics.crypto > Subject: A new PGP > Followup-To: alt.security.pgp > Date: 13 Sep 1994 16:01:08 GMT > Organization: University of Auckland > Lines: 263 > Sender: pgut1(a)cs.aukuni.ac.nz (Peter Gutmann) > Message-ID: <354ic4$t54(a)ccu2.auckland.ac.nz> > NNTP-Posting-Host: cs13.cs.aukuni.ac.nz > X-Newsreader: NN version 6.5.0 #7 (NOV) > Xref: news.sprintlink.net alt.security.pgp:18448 sci.crypt:31730 talk.politics.crypto:7169 > > > > [NB: Followups redirected to alt.security.pgp] > > This posting is a call for participation in a complete rehash of PGP to > parallel the existing PGP effort in the US. All contributions are welcome, > although any cryptographic material from the US won't be usable by anyone else, > so it'd be best if all crypto work was done outside the US. I believe Phil is > aware of this project but can't comment on it due to legal advice - please > don't pester him (or me) about this. > > The following sections are a preliminary sketch of what's to be done, see the > end of this message for more information on how to participate. > > Design goals for the new PGP: > > - Proper key database for fast lookup of keys. > - Something like DER-encoded ASN.1 keys and data, PKCS/X.509 compatible with > extensions for PGP's trust model and also i18n features not found in X.509 > (exact details still under debate). > - Ability to plug in alternative routines, eg RSAREF instead of independant > RSA code. > - Backwards compatibility with 2.x. > - MIME security extension compliant encoding of messages. > - Flexible, planned message/key format which allows easy expandability. > > The universal PGP rewrite emphasizes flexibility of design, modularity and > Chinese-wall seperation for ease of development, and abstraction of messy > details like low-level I/O. Some rules to go by: > > - All functional units are kept in seperate modules. There is one header file > giving the interface to that module. Only the interface given in the header > file is available to the outside world. All non-public information should be > in header files which are private to that module. This should vastly simplfy > development by multiple people since all the content-coupling of the existing > code is eliminated. > > The whole of PGP is too big for one person to get an overview of, by > enforcing modularity with a preset interface we can allow independant teams > to work on the parts they're best at, as well as allow independant developers > to user the libraries they want in PGP support software without having to > worry about all the API's breaking every time there's a new release. > > - None of the library routines perform any user I/O. This is all handled by > higher-level code, using callbacks if really necessary. The libraries should > be usable in any CLI or GUI environment without needing changes made for > different operating environments. > > - All routines return an integer status with well-defined codes. Status values > are defined in the module interface header and are of the form <3-char module > name>ERR_<error type>, eg DBXERR_READ would indicate a read error in the > database access code. No mysterious constants buried seven nesting levesl > down in routines somewhere! > > The basic modules are: > > > Streams > ------- > > A generalized stream I/O library. A stream can be a block of memory, a FILE *, > a file-descriptor-based file, a TCP socket, an X.25 virtual circuit, or > whatever. The use of memory streams does away with PGP2's overuse of temporary > files. > > int newStream( STREAM *stream ); > int attachStream( STREAM *stream, ??? ); > int ioctlStream( STREAM *stream, ??? ); > int readStream( STREAM *stream, void *buffer, size_t length ); > int writeStream( STREAM *stream, void *buffer, size_t length ); > int lengthStream( STREAM *stream ); > int deleteStream( STREAM *stream ); > > The attachStream() and ioctlStream() attach a stream to an interface, eg a > block of memory, a file, or a network connection, and change its > characteristics. The end user is never aware of any difference, or of the fact > that, for example, for a small message they might be R/W memory, but for a > larger one they might be R/W a temporary file. Perhaps an existing PD streams > library can be adapted to the task. > > Error codes: STMERR_xxx > > > PKC > --- > > A PKC library. > > int rsaEncrypt( PUBKEY *pubKey, STREAM *stream ); > int rsaDecrypt( PRIVKEY *privKey, STREAM *stream ); > int rsaKeyGen( ??? ); > > Error codes: PKCERR_xxx > > > Crypto > ------ > > A conventional-key crypto library. > > int encrypt( CRYPTINFO *cryptInfo, STREAM *stream ); > int decrypt( CRYPTINFO *cryptInfo, STREAM *stream ); > > The CRYPTINFO struct contains all the information you need to specify > encryption algorithms and modes, so you'd have something like: > > cryptInfo->algorithm = CRYPT_ALGO_IDEA; > cryptInfo->mode = CRYPT_MODE_CFB; > encrypt( cryptInfo, stream ); > > This fixes another complaint with PGP, that for every job you do there are 15 > different functions to do it, all with slightly different parameters and > options. With the unified interface, the call to encrypt data is *always* > called encrypt() (rather than encryptIdeaCfb(), encryptFooBar(), > encryptThisThatAndTheOther(), etc), and the CRYPT_INFO struct contains all the > parameters you need. A library could then implement a number of different > algorithms and you choose which one you want without having to know that the > function name for that option is encryptQwertyFoo(). You could even have a > getCryptInfo() call which queries a library as to which algorithms and modes it > implements, or the call could return CRYERR_ALGO_UNAVAIL (algorithm > unavailable) or CRYERR_MODE_UNAVAIL (encryption mode unavailable). > > Error codes: CRYERR_xxx > > > Configuration > ------------- > > Get configuration information for PGP routines. Use a proper grammar > definition, perhaps lex+yacc (tcl has also been suggested), read into (private) > vars, make available to outside world via getXXX() calls. NO GLOBAL CONFIG > VARS! > > int readConfigFiles( void ); > int getFooInfo( char *fooPtr ); > int getBarInfo( int *barPtr ); > > Error codes: CFGERR_xxx > > > Random Number Handling > ---------------------- > > A random number management library. > > int openRandomStream( STREAM *stream ); > int readRandomStream( STREAM *stream, void *buffer, size_t count ); > int closeRandomStream( STREAM *stream ); > > This could use the existing keystroke latency method, or connect the stream to > custom hardware, or whatever. > > Error codes: RNDERR_xxx > > > Key Database Management > ----------------------- > > All keys can (and should be) stored in a database, which encapsulate the full > DER-encoded keys inside a database allowing fast lookup. The general format > will be: > > { keyID, userID, encapsulated key } > > The keyID is a hash of the key (making it independant of the key itself and not > prone to denial-of-service attacks), the userID is simply the user > ID/address/whatever, the encapsulated key contains the full key. Lookup is > done on the keyID and userID which locate the required key. Details of the > exact mechanism to be decided by the database experts - need to define message > format, kludges like storage of encapsulated keys in XMS for peecee's, etc etc. > > > En/decoding > ----------- > > ASN.1 DER-encoding of keys/data, MIME en/decoding. Needs to be discussed. > > > Compatibility > ------------- > > Backwards-compatibility code to handle old PGP keys and messages. Presumably > keys will only need to be converted once, then we need to read old messages and > (possibly) write them. > > > Low-Level > --------- > > Low-level OS interface code. All OS-specific code is hidden in this module. > > > I18n > ---- > > A proper i18n system which reads the appropriate messages from a database once > and then keeps them in memory. > > int readInternationalizationDatabase( void ); > > All user I/O then uses strings from the i18n database. The database is > generated by a precompiler from some user-friendly input format, so that a > group of seperate language scripts for eg English, French, German, Russian, etc > are fed into one and, and the output is the full i18n database. Adding a new > language to PGP then involves simply creating a new script in that language and > running the database compiler on it. > > > Installation > ------------ > > Not part of PGP, but we need someone to do a decent install script which > removes from end users the need to fiddle makefiles and options. > > > Others > ------ > > Other routines as required. For example, we each library should have an init > call which registers an exit handler with a function called by atexit() to > allow a clean shutdown no matter how we exit the program. This does away with > the current need for PGP to explicitly perform exit handling all over the > place, and hides the messy details from the end user (who may not even think > about things like this). > > > What we need: > > - A well-connected site outside the US to run mailing lists, one per developers > group: > > pgp-streams - streams interface for I/O > pgp-crypto - public and private-key encryption, random number management > pgp-dbx - key database management > pgp-compat - PGP 2.x backwards-compatibility management > pgp-protocol - PGP data/key format and protocol redesign > pgp-lowlevel - low-level OS-specific glue code > pgp-misc - everything else, eg config code, i18n, installation > > There may also be a need for a seperate group to handle key-related routines > such as trust-level checks and whatnot, which is a fairly complex task. The > idea is to mimimze the amount of unnecessary traffic people will need to read > in order to get their job done. > > The only communication which should be necessary between these groups is the > header file which defines the data structures and interface and/or a written > specification of the interface to a module. This means that the PKC group > can work on the PKC code without having to worry about what the streams, > database, crypto, and os-specific groups are doing. > > An attached FTP site for distribution of code would also be nice. > > - Groups of developers with expertise in PKC crypto, conventional crypto, > database management, low-level OS-specific stuff, code optimization, protocol > design, software i18n, and everything else imaginable. > > Until the mailing lists are set up (someone volunteer a site, quickly!) I'll be > handling things in email, which means that it could take quite a while for me > to extract myself from the flood of messages I'm expecting. Please try and > keep non-essential messages to a minimum, and be patient when waiting for > replies. > > Peter (Hmm, maybe I'd better mount /usr/spool/mail on a seperate drive). > - paul

1 0

Re: US Fascist Dictatorship?
by frissell＠panix.com 17 Dec '03

17 Dec '03

At 12:09 AM 9/15/94 -0400, Bob Snyder wrote: > >>So is the US about to grab all the guns, seal the borders, make foreign >>trade a crime, and change the color of the money? > >And the link to cryptography is what? > >Bob Most of the members of this list are here because they see crypto as a "technological fix" that will let us ignore government and private interventions/invasions (that we want to ignore). That makes this a somewhat political list. I know we have been a bit political of late but what I was trying to do with my post was to introduce a bit of reality in to what are usually somewhat unrealistic ideas. Those who are involved in cryptography often seem to be seeking mathematically perfect security. They also assume that the oppressors are deploying mathematically perfect oppression. When I describe the total incompetence at the INS, I am just trying to point out that The Great Enemy is not all that efficient so we can make do with less than perfect security. DCF

1 0

if this is RC4
by Carl Ellison 17 Dec '03

17 Dec '03

Assuming for the moment that alleged-RC4 came from the keyboard of Ron Rivest, my question is whether to look at this as an amateur cipher from a famous cryptologist -- or as a carefully designed cipher from a professional. If it's the latter, we should probably look for some underlying strengths the way the community picked apart S-box design rules years ago. - Carl

6 8

DigTel: ERRATA - correct path to Berman HR testimony 09/13/94
by Stanton McCandlish 17 Dec '03

17 Dec '03

Apologies for the incorrect path given at the end of yesterday's release of our hearing summary. The correct path to the file containing EFF Policy Director Jerry Berman's testimony at the US House of Representatives hearing on Digital Telephony of two days ago is: ftp.eff.org, /pub/EFF/Policy/FBI/eff_091394_digtel_berman.testimony gopher.eff.org, 1/EFF/Policy/FBI, eff_091394_digtel_berman.testimony http://www.eff.org/pub/EFF/Policy/FBI/eff_091394_digtel_berman.testimony -- <A HREF="http://www.eff.org/~mech/mech.html"> Stanton McCandlish </A><HR><A HREF="mailto:mech@eff.org"> mech(a)eff.org </A><P><A HREF="http://www.eff.org/"> Electronic Frontier Fndtn. </A><P> Online Activist

1 0

thoughts on RC4
by perry＠imsi.com 17 Dec '03

17 Dec '03

I've been looking at the RC4 (or alleged RC4) code a bit. Unlike most ciphers, RC4 doesn't seem to have any particular word length dependancies in its principles. That is to say, a cipher like IDEA has lots of magic numbers involved, but RC4 does not, which means that one could, in principle, extend it from being byte oriented stream to being word oriented stream without causing particular harm. (It would, of course, become incompatible, but thats not a real issue.) Can anyone see any reason why one could not change RC4 to being a word oriented stream cipher, call it "ERC4"? The reason I ask is because this would speed things up by a factor of four on 32 bit machines, which would mean modest hardware could possibly break 100mbps speeds. The 64 bit extension on 64 bit RISC processors could go far, far, faster still. This is a real consideration in the protection of network traffic, where extremely fast encryption in software has been a stumbling block. Perry

7 9

RC4 Legal Issues
by hughes＠ah.com 17 Dec '03

17 Dec '03

Some general words on trade secrets. Trade secret law is eminently sensible. It grows out of common law and the merits and facts of real situations regarding information. Trade secret law does not attempt to reverse the disclosure of information, which would be contrary to the properties of information. It does not require that people forget something they have learned. Nor does trade secret law force tribute upon those who use that knowledge, as patent law does. It does not restrict the transmission of information, as copyright law does. If, however, you tell someone you're going to keep a secret, and they compensate you for that promise (i.e. consideration in a contract), then the law expects you to uphold your promise or make good the harm that you've caused. Lacking an agreement, the holder of the agreement has no recourse. In a cryptographic world, the model of trade secret law is worth considering. It concerns only information and agreements between individuals. Eric

1 0