Because I am not myself much of a programer, and because I have to find excuses to feel useful, I thought I would annoy everyone with my ideas about where c'punks might want to direct their efforts at encryption development. Of course any suggestion at direction tends to require a disclosure of the assumptions one is working from. The following are mine: 1. The most interesting crypto uses and implementations seem to come from grassroots programers, not large organizations. Remailers, PGP, Curve Encrypt, Private Idaho, mixmaster, premail, and magic money all were the results of "grassroots" efforts. None of these have been produced from massive corporate R and D programs, and most have been the result of predominately a single programmer's efforts. 2. The most useful crypto applications out there have tended to survive by using crypto that looks forward, not to the past, or the present. This is generally manifest in the inclusion or easy use of multiple methods. Zimmerman's selection of IDEA over DES, PGP's multiple key sizes, Curve Encrypt's 3DES/IDEA option, are all examples of an effort to design systems which will be useful tommorow, not just today. PGPlib seems to pick up this trend where PGP 2.x went awry. 3. In so far as proliferation is important, the impact of crypto applications and implementations is directly tied to ease of use. If PGP has failings, one must be that it can be immensely intimidating to the novice. 4. Increasingly cryptography is defying attempts at conventional regulation. 5. #4 will eventually spur sovereigns to rather drastic methods to defy #4. 6. Secure Communications, and transparent crypto are a Good Thing. Assuming the above, I think it is apparent that crypto development should be focused on a few general points and a few key areas. As to general points, I think the clear concentrations include: A. Increasing the ease of use. Perhaps I should have put this as #1, because really among those things which I suggest in this post, I think this is of primary importance. It cannot be stressed enough that encryption must be transparent, easy to use, but at the same time make its presence just apparent enough to encourage its use, and to make users note its absence. Crypto will have its most significant impact, its most liberating results, and be self assuring only to the extent that it is not a novelty, but an assumption. Please, authors, coderpunks, make crypto easy to use, but flexible enough so that adept and expert users can modify functional aspects. (Key generation, key size, exponent size, algorithm selection, level of verbosity and suchlike should find their way into an expert menu somewhere). B. Multiple encryption method support/larger key sizes. While I may be more paranoid than some, or even most, I think it is crucial to provide for the possibility that strong encryption may one day face a total ban in more countries. To avoid the chilling effect that this would certainly have on development, it is of key importance to permit applications and implementations to nexus with several methods, and to allow what may today seem like extrodinarily large key sizes. (256 bits would not be unreasonable in my view, particularly so where the user was given the option of selecting a ~128 or so bit method like IDEA or 3DES at their option (consistent with A. above). C. Anonymous communication. I'm not sure this needs much explanation. D. True stego. Today it is a simple matter to identify encrypted traffic. This is the key flaw in what I will call (at risk of sounding like a white paper) the NEI (National Encryption Infrastructure). It subjects users to very effective and easy to implement traffic analysis. While I understand the temptation to use checksum like methods to speed the key checking process, at some point I am of the view that this convenience will come back to haunt crypto. Given these areas, what specific applications might be the best to look into for the grassroots crypto advocate/coder? A. Methods to run secure websites on insecure servers. A thread on 'punks last month, I am of the view that local decryption of web pages is essential to the development of coercion free web pages. Estlablishing a truely secure web page today requires the server to be extra-terratorial, in a secure physical location, and requires such lengths to defeat traffic analysis (which lengths must be applied to the actual network logistics, rather than the software logistics) so as to be impractical to all but institutional resources. The best effort I have seen is in European Union Bank (www.eub.com) or (www.eub.net) [neither of which I recommend you use for deposits] and it still falls quite short. A software solution which permits local decryption makes traffic analysis less useful, presents the opportunity to use front end and disposable www pages on domestic ISPs while imposing no liability on the ISP itself, and opens several more effective traffic analysis deterants. Ideally, both web proxies (for servers as well as clients) and local decryption will be written allowing both server and user a degree of double blind operation as well as easy disposability of front ends. A Netscape plugin for local decryption of web pages and proxy forwarding of WWW form submissions to the server is a MUST. Is anyone considering work on these? B. More effective message pools. Really this is the only practical and most effective method to defeat traffic analysis of e-mail communications. Why do you think it is that informants always communicate with the FBI in the classified ads? This has been discussed again and again, yet I am aware of no serious effort to construct an effective server or client to implement it more effectively than USENET (which seems to be hopelessly slow and prone to drop postings regularly) I am encouraged by the new mixmaster model, but I have yet to read the entire abstract carefully. If the goal is, as I believe it should be, to make encryption accessible and understood by, if not everyman and joe sixpack, joe digitalsixpack, then it strikes me that the focus should be on WWW browsers and servers, (Netscape like material), popular mailing programs (Eudora), and the building blocks of the network, the point of origin, and the point of final destination. Point to point, grassroots plug ins to existing de facto standards, and ease of use, ease of use, ease of use. cypherpunks write code. Call me "half a cypherpunk" -- I hate lightning. (unicorn@schloss.li)