From: tcmay@netcom.com (Timothy C. May)
Date: Sun, 24 Apr 94 12:45:23 PDT
To: cypherpunks@toad.com
Subject: "Information-Hiding" in Crypto Programs
Message-ID: <199404241946.MAA05741@mail.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


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