"Information-Hiding" in Crypto Programs

The challenge I mentioned in my last message can be summarized as
follows:

- hide the complexity of implementation in the code, so that other
programmers, and especially end-users, don't have to worry about it.

- to pick a simplest example, a random number generator needs to
generated a good random number without the user having to worry about
a zillion related issues

(this may get flames....I'm not saying users should be blissfully
ignorant of some of the assumptions that went into the RNG, only that
most users want an RNG that operates consistently, has been tested by
others, etc. This is the Mathematica function method: have experts
devise the best factoring or primality testing approach, implement it
efficiently (usually in C or even machine language), and then give it
to the user as "FactorInteger[3858783237285638838513] for him to
incorporate as a canned functon.)

- "information hiding," or modularization, means hiding the
implementation details from the user and providing regularized calling
conventions to make the code behave almost like a "thing" (internal
consistency, reproducible behavior, etc.)

- "crypto objects" (or instances of classes) would presumably know how
to handle the usual crypto messages.

- "digital cash objects" would help with the extraordinarily confusing
protocols for multi-party transactions

I'm not saying _how_ they would help, just that my intuition is that
the crypto community could make new strides if the imperative style of
programming ("do this," "now do this," etc.) were to be supplemented
with the descriptive style ("this is a digital cash object and these
are the messages it understands") and even the logical style (of
Prolog, for example).

Two years ago, Eric Hughes and I spent a few intense days debating
these sorts of issues, including discussions of "program correctness"
and protocol generation. 

For digital money to succeed, there had better not be flaws and
loopholes that allow attackers to drain your money away or to cause
confusion and doubt amongst your customers! Automatic theorem-proving
methods, so often the topic of dusty old Ph.D theses, may come to the
fore to handle these extremely complex (and attackable by spoofers,
eavesdroppers, forgers, etc) protocols.

This stuff goes beyond what I was talking about with objects, classes,
and libraries, but may be needed sooner than we think.

I promise to shut up for a while.

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

> II. What's Neeeded
>
> * Consider some things we like to talk about:
> 
> - alternatives to RSA (elliptic functions, etc.)

This isn't a technical problem, but I think having some RSA alternatives
would put us in a better position politically.  What sort of systems are
availiable?  (For my own personal inquisitiveness, I have developed some
ideas for systems that might work, but I really can't be sure of their
effectiveness/security.)

> - secret-sharing protocols

You mean like DH?  Alternatives to DH?

> - remailer-specific code (adding latency, mixing, padding, etc.)

Well, Karl Barrus has done a lot of work here, but let me restate my
call for more remailers - BTW: Why don't you set up a remailer on your
Netcom account, since you seem to like them so much?

> - dining cryptographers nets (DC-Nets, a la Chaum, Bos, etc.)

We could do this...  You want to build a DC-Net for the remailers or something?

> - digital cash (a vast area of diverse protocols for clearing
> transactions, for blinding, for detecting double-spending, etc.)

Yep, the old digicash problem...

> - 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?)

We have lots of RNGs...What do you want to DO with them?

> - code for message pools, for chaining remailers, etc.....a lot of
> this exists as scraps of Perl in various places.

Well, we have message pools, but perhaps software to automatically scan
them and pick out messages for you would be helpful...


Your point about the Crypto Toolkit is well-taken, especially in light
of your comment about Mathematica.  We need some sort of universal
interface that everyone can use, that is easy to understand, and have it
be able to work with different mail packages and different systems. 
Maybe we need some kind of new interpreted (for universal portability)
data-manipulations language, so we can write crypto tools and everyone
could use them on every platform.  Or maybe we just need to write a
cypherpunks mail program, that could automatically handle PGP, anonymous
remailer chainings, and remailer reply protocols.  I know Ian Smith was
working on something like this...

One other potential project - on-the-fly file encryption/decryption for
multi-user unix systems would be a big plus for security (like secure
drive but not for the whole disk).  If a hacker got into you account,
all they'd have is a bunch of encrypted files.  We could set it up to
work with existing accounts so that after you enter your account, you
have to enter a second password to get to your files, preferably by
secure key-exchange protocols.  It's a shame I don't know enuf about
unix to hack it myself. :(

(I'll only respond to the points Matthew Ghil made about Crypto
Toolkits and such, not to his reactions to my laundry lists of
projects and code.)

> Your point about the Crypto Toolkit is well-taken, especially in light
> of your comment about Mathematica.  We need some sort of universal
> interface that everyone can use, that is easy to understand, and have it
> be able to work with different mail packages and different systems. 

Understand that I'm in no way suggesting Mathematica syntax for these
functions and modules (though there are certainly worse choices....).
But what the developers of Mathematica (henceforth MMA) did was to
provide functional tools for scientists and casual programmers (and
nonprogrammers) that did not require them to know C or to accumulate
their own C and FORTRAN libraries. MMA mainly is a collection of more
than 1200 functions, with user-defined funtions acting as keywords.

The market success of MMA (courses at most schools, about 20 books, a
journal, etc.), and its cousin Maple (a competitor actually, but also
a cousin), not to mention MathCAD, shows a market exists for
higher-level language tools.

(However, MMA and Maple and other such products are _environments_
requiring the product to run, with sometimes cumbersome means of
hooking to outside code and resources. This rules these out for most
users, who don't have MMA or SmalltalkAgents or the like. Still,
there's _some_ chance that such tools could be used for building
standalone apps. But I would have to agree with any criticisms that
Unix and C and such are more available--now.)

There's little doubt that C is more efficient, blah blah. But the
success in using Perl to write the remailer scripts in shows that
efficiency is not always the only concern.

A lot more to be said on this whole issue. I'm not sure everyone here
is interested, though. And I detect some impatience with the very
idea that these things need discussing....the idea that "Cypherpunks
write code" seems to be interpreted by some that what we should all do
is just to sit down and start pounding out C code.

(A good idea, of course. For those with the skills and the time. But
implementing something other than another cipher, such as we've seen
several of here, is *conceptually nontrivial*. For example, suppose a
DC-Net is desired as the target. Several efforts have started, but
none has reported any significant progress. Most of the efforts seem
stillborn. There are reasons for this, I think. The old "semantic gap"
between the descriptions in papers (themselves often incomplete or
confusing) and the tools available. I shudder to think at the
difficulties in writing C code from scratch to implement even a crude
DC-Net, absent crypto primitives like bit commitment (the idea of
choosing a bit then not being able to change it....done
cryptographically, of course) and the other "tools" that are assumed
in a real-world system but which are nonexistent in C.)

> Maybe we need some kind of new interpreted (for universal portability)
> data-manipulations language, so we can write crypto tools and everyone
> could use them on every platform.  Or maybe we just need to write a

In line with PostScript and its newer cousin Telescript, I jokingly
suggested to Peter Wayner in a recent message that a crypto version of
such a crypto-protocol-oriented language be called "CryptScript." The
idea being that of a collection of tools and utilities, unified in a
language that can more seamlessly incorporate the current concepts and
protocols of modern cryptography. (Telescript itself looks
intriguing.)

As I said in a private message to Hal Finney, I'm not at all trying to
set or focus the agenda of others. Rather, I'm just trying to focus my
own agenda through discussion. If others get something out of this
discussion, great. If they don't, at least discussion of crypto
protocols and integration with languages and tools is no more
off-topic than most discussions here.

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

On Tue, 26 Apr 1994, Matthew J Ghio wrote:
> Well, we have message pools, but perhaps software to automatically scan
> them and pick out messages for you would be helpful...

please Please PLEASE! SOMEBODY WRITE ONE OF THESE!!  I have been trying 
for about six months on and off and can't get it to work at all!

Happy Hunting, -Chris
<who is a shitty programmer but is not afraid to admit it; and who hopes 
to improve over time.>