In this message I talk about C code, agents, TeleScript, Smalltalk, PGP tools, and the general and pressing need to somehow make all the diverse fragments of code available and (even more importantly) comprehensible and usable. (As I'm no expert in C++ and the like, take my comments as "moderately informed speculations.") Hal Finney writes:

From: Peter Murphy <pkm@maths.uq.oz.au>

...

I was most taken by the idea of a "Crypto Toolkit". I think it would be understand- able to write the code in plain, vanilla C (as opposed to C++). One good reason is the widespread availability of C compilers, especially with UNIX. Additionally, C++ compilers do take up more space (although this would be more of an issue with PCs.

I think Tim had in mind something that was accessible more from a higher- level language than C or C++; ideally, something interpreted so you could sit down and type in a few commands to get something useful. Perl and TCL are two languages which Tim mentioned and which have been discussed here in the past. Smalltalk might do, although it is not as "freely" avail- able.

Yes, this is mostly what I meant. Lots of stuff here, and I really should use my outline processor to do a better job of outlining options, routes, and miscellaneous points. But I'll just make a few notes here. (The theme of the next Cypherpunks meeting, date not yet finalized, is "Protocols," so issues like this are presumably relevant. Depending on the date, I may be in L.A., and would welcome meeting with other Southland Cpunks to discuss ideas.) I. What We Have * PGP...the most basic of all crypto functions (RSA encrypt/decrypt/sign/etc.), and it took over a decade to get a usable, public domain (?!) version. (Yes, I know about RIPEM, RSAREF, etc.) (I mention this because _use_ of this protocol, even with a nice manual and whatnot from Phil, Hal, Derek, and others, still mysifies many people, and still is not easily callable from most mail programs, as you all know. This is *terribly important point*, to wit: if the most basic of all crypto functions is so long in gestation and so difficult to use interoperably, what hope do we have in integrating the vast range of crypto protocols to be found in Schneier, the Crypto Conference Proceedings, etc? This is the problem I'd like to see solved, hence my interested in "Computer-Aided Crypto Algorithms," or CACA.) * we also have fragments of C code accumulated and laboriously developed by Bruce Schneier. How many of us have bought the C code book and used the code? (Don't look at me....I had wonderful intentions to convert some of Schneier's code from his C code (and C is something I limp along in, using Think C 6.0, aka Symantec C++) to Mathematica code (which I'm much more adept at playing around with, though not at delivering code usable by others). But I've not yet found the time or motivation to do this, as I suspect is the case with many of us. * there's the ProductCypher (sp?) code which Hal mentioned. I haven't looked at it, for the same reasons I just gave. I _should_ look at it, but I haven't. Oh well. * code in Perl obviously exists in various places, and both Hal Finney and Henry Strickland have written about TCL. Whether these scripting languages, with excellent facilities for accessing Unix utilities directly (as opposed to from deeply within a C program, like PGP), should or can form the basis of a Crypto Toolkit that others will actually use is unclear, to me at least. * other programming efforts presumably exist out there in Cypherpunk land, and some folks not on the List (unless by pseudonym, which is quite possible....after all, ProductCypher is obviously a talented programmer and may be one of the main folks posting algorithms and code fragments to sci.crypt) are clearly writing code for various purposes. ...thus ends my informal summary of what's out there (it may be incomplete, or inaccurate in places...corrections are welcome, as always) II. What's Neeeded * Consider some things we like to talk about: - alternatives to RSA (elliptic functions, etc.) - secret-sharing protocols - remailer-specific code (adding latency, mixing, padding, etc.) - dining cryptographers nets (DC-Nets, a la Chaum, Bos, etc.) - digital cash (a vast area of diverse protocols for clearing transactions, for blinding, for detecting double-spending, etc.) - random number generators (Schneier, for example, supplies code fragments for the Blum-Blum-Shub generator...need I again say that probably few of us know how to "call" this code easily?) - code for message pools, for chaining remailers, etc.....a lot of this exists as scraps of Perl in various places. - and so on My point? How can we achieve the Crypto Singularity (tm) when these algorithms and _conceptual functions_ (my term, meaning that each of these embodies almost an agent-like level of behavioral complexity....hence my interest in implementing these protocols as classes and methods in something like Smalltalk or even the new TeleScript) are scattered around, are hard to grok (a technical term invented by the neural programmer Heinlein), and are more or less going unused today? III. Some Approaches to a Crypto Toolkit * Large collection of C programs. The Schneier approach, except on steroids. Regularize the calling conventions, add further documentation, generate test sample, etc. A massive undertaking, fraught with problems. * C and Perl, and maybe TCL. As above, but use other Unix utilities as needed. * A class library for crypto, in C++. Encapusulate as much of the capability into classes and make them available. For example (and here I'm using Smalltalkish lingo), an "RSA object" would understand (have methods for) messages sent to it that included RSA-encrypted sections. It would find the identifying blocks (a la "begin pgp message") and attempt to decrypt them with its private key. Similarly, a "digital banknote" would have internal structure and methods for dealing with various messages, such as "Display your value" and "Authenticate yourself." I'm not sure how feasible this would be in C++, as I know very little about C++ (I have Symantec C++ and _someday_ plan to learn enough to get by on--not being a professional programmer, and nobody paying me to learn, I have plenty of reasons to keep postponing this learning).

From my Lisp background (Symbolics 3600, Zetalisp, Common Lisp) and from my experiments with Digitalk's Smalltalk/V on my Mac, I think an object-oriented environment could be ideal.

* TeleScript. Here I will go out on a limb and predict that the forthcoming TeleScript, which is nicely described in the latest "Byte" by our very own Peter Wayner, could be the basis for some exciting progress. With multi-platform capability, object orientation, and an explicit foucs on agents running around delivering mail, encrypting, etc., it could be a winner. Few details have been released by General Magic, AT&T, Apple, NEC, etc., and a Developer's Conference is coming in several months. Our own Scott Collins worked for GM for a while, and I believe Fen LaBalme does (though he's not active on this list and may not even read this message). They can no doubt comment generally on the prospects for TeleScript and whether it could form a solid basis for Cypherpunks code. (Speculatively, my notion is to embed in Telescript agents many of the things we've been talking about, and then count on the market to make mailers and Mosaic drivers to talk to these agents. Lots to talk about here.) * Speaking of Mosaic, what about using WWW/Mosaic as the basis for transparent use? I'm already impressed that on a non-Mosaic platform (I don't have either a SLIP or PPP connection at this time) I can use my cut-and-paste to easily do a "lynx http::blah blah blah" and get to a home page with arrow-selectable hypertext points. I can see WWW/Mosaic/Lynx/etc. as a common platform (set of utilities) for handling even encrypted traffic. IV. Conclusions (brief) * Existing tools are hard to understand (isn't surprising--we can't use of an Asmuth-Bloom secret-sharing protocol to be easy to use if people first of all have no idea what "secret sharing" means in a formal sense, etc.) * Integrating existing tools (PGPToolKit, Perl scripts, Schneier's code, RSAREF) into new apps is basically *not* happening, at least not by the Great Masses here on our list (let alone the Unwashed Masses off the list!). * Interoperability with dozens of mailers, on several platforms, remains a critical problem. * Hence, *good luck* in getting all the whizzy new protocols we like to speculate about implemented any time soon. This is the challenge I see. To somehow deal with this set of problems. Thanks for reading...and I again apologize for just sitting down and writing this in emacs instead of using my Mac-based outline processor. Sometimes just writing is better than planning, reorganizing, and never finishing. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."