From: maschino@phx.sectel.mot.com (Mike Maschino)
Date: Tue, 6 Dec 94 15:43:35 PST
To: cypherpunks@toad.com
Subject: Re: GUCAPI (Grand Unified Crypto API)
Message-ID: <9412062344.AA14068@ phx.sectel.mot.com>
MIME-Version: 1.0
Content-Type: text/plain


(This is my first attempt at posting, please excuse any errors, and I do
not yet have PGP on my employer-owned machine)

> I've been thinking a lot recently about how to implement a generic API for
> crypto such that the interface could be independent of the cipher used.
> What I'm thinking of is something like:

There are numerous industry groups working on a "security" API, including
Microsoft, Novell, Motorola, Intel, etc.  Major focus is transparent (to the
user) security (encryption, KCA, signatures, etc) for email, local and
remote file access, generalized and integrated telephony, and so forth.

Of course, there are many approaches, generation by committee, personal and
corporate biases, and other garbage to get in their way.  What may be
interesting is to look at their proposed security APIs and glean interesting
ideas to be incorporated into your API.

Some ideas on effective APIs:
-  the process of encryption/decryption, signaturing, etc should be
   independent of the destination/source of the data.  The same API should
   be able to process a file, an e-mail message, an inter-process control
   message, etc.  The API does not care what the data is from or for, it
   just operates on it.  Of course, the API should be able to process in
   the various encryption modes, and may have to discriminate between a
   continuous flow of data and a finite size of data.
-  API's at this level must NEVER directly utilize the User Interface
   (regardless of whether the UI is graphical or textual).  It should be
   completely irrelevant to the API whether it was invoked by an actual
   user, a local system process, or a remote system process.  Return and
   error conditions are returned to the caller, which then decides what to
   do with the erroneous result.  Error traps are acceptable too, though
   the trap should allow the "trapper" to decide what to do about notification
   or handling of the error.

Of course, you recognize the hardest API is key management.  Use some 
data and/or object modeling techniques to handle the two basic senarios
and see if you can generalize it sufficiently.

I have no idea about how to get the group's proposed API's.  There has been
several mentions in the networking trade papers about them though.  Windows
95 and NT WILL have a security API based in part on the existing one worked 
out with Novell.  Of course, security is a local issues as well as a networking
or messaging issue, so I doubt their implementation will be thorough.

Hope this is of some help.

- Mike

*****************************************************************************
Mike Maschino                       Email: Mike_Maschino-P17960@email.mot.com

Motorola                                | "I am not speaking for my employer,
Government and Systems Technology Group | and they do not speak for me"
Scottsdale, AZ, USA                     |

"Neuro-encrypto-psycho-telco-photo-proto-nympho-lego <g>-maniacs wanted by
same; applications available; god-like entities always welcome"
*****************************************************************************