Crypto Toolkit, Objects, and TeleScript

[tcmay@netcom.com (Timothy C. May)]

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."