From: fnerd@smds.com (FutureNerd Steve Witham)
Date: Mon, 25 Apr 94 16:12:17 PDT
To: cypherpunks@toad.com
Subject: Re: "Information-Hiding" in Crypto Programs
Message-ID: <9404252311.AA19415@smds.com>
MIME-Version: 1.0
Content-Type: text/plain


Tim about raising the programming language level for crypto
applications.  He Orients toward Objects...

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

There are a couple different issues you could hide in a language for
crypto.

Obviously you can abstract bignums, numbers with a modulus, matrices, 
...mathematical objects, and that would get a lot of cobwebs out of
the way in many crypto algorithms.  Even a Bignum Basic that could do
fast modmult would be nice.

Or you could make objects out of the data structures, like keys,
message blocks, key rings, etc., and their operations.  That would
be nice because you could separate the layer of calculation from
the layer of protocol.  But the protocol programming would still be in 
an imperative style.

Which has its good points.  I do a lot of work in a scripting
language that has procedures and lists and strings and that's
about it.  But the rules are understandable and it ends up the
language is *readable* in the sense that you can look at a 
procedure and get a good idea of what it's doing without 
stretching your concepts too much.  Which I think would be a good
feature for a crypto language, especially one for experimentation,
teaching and tossing ideas around.  I think the language I work in
gets readability by its plodding, structured-programming, imperative 
style (it also uses plodding long names for things).

But of course protocols and transactions are big things in crypto, 
and they take place in time, which leads to thoughts about special
control structures to handle them.

Structures in time are actually one of the nifty things to implement
with objects.  You can have an object that stands for a whole 
conversation in a protocol--sort of like a file handle.  So you have
operations like (in no particular language):
	conversation = Protocol.new( some parameters );
        conversation.send( message );
	conversation.receive( message );
        conversation.end();

You can also use objects to implement protocol layers, like:
	conversation0 = Protocol0.new( ... );
	conversation1 = Protocol1.new( conversation0, ... );
        conversation1.send( message );
        ...

(Some amazing things can be done with operations on objects that 
represent sequences in time.  In the book _The Structure and 
Interpretation of Computer Programs_, one chapter develops a Prolog 
interpreter as a bunch of layered stream filters.  Oops, I digress.)

Another area you might want to separate out of the heart of 
crypto programs is I/O, both with the user and with the rest of
the system--the mail system, for instance.

-fnerd


- - - - - - - - - - - - - - -
Gradually, I become aware of a presence.
Between me and sustenance stands a woman in a suit. --Michael Swaine
-----BEGIN PGP SIGNATURE-----
Version: 2.3a

aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K
ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz
3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG
sRjLQs4iVVM=
=9wqs
-----END PGP SIGNATURE-----