From: "JEFF LICQUIA (CEI)" <JLICQUIA@mhc.uiuc.edu>
Date: Tue, 6 Dec 94 14:25:05 PST
To: cypherpunks@toad.com
Subject: Re: GUCAPI (Grand Unified Crypto API)
Message-ID: <MAILQUEUE-101.941206162307.480@mhc.uiuc.edu>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

> From:          "L. Todd Masco" <cactus@hks.net>

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

Here's a few random thoughts:

Perhaps we could split the functions into groups according to the purpose 
of the group.  Thus, key generation protocols would be in one group, 
encryption in another, decryption in another, file I/O routines in 
another, and so on.  This would seem to encourage a more modular 
approach.  It would provide an additional level of abstraction as well; 
you could implement higher-level actions in terms of lower-level ones.  
For example, you could implement "PGP-encrypt" in terms of calls to 
RSA-specific and IDEA-specific functions; from the point of view of the 
application, however, raw RSA and "PGP-style" encryption would look like 
two separate implementations of the same API.  It could also facilitate 
certain other types of apps; for example, if we had a "key management" 
API and implementations of the API for PGP keys and PEM keys, we could 
easily construct an app that could PGP-encrypt with PEM keys and vice 
versa.

Not to be an OO bigot or anything, but I would implement these as object 
groups, with the parents defining the API and the children implementing 
it.  As an example, consider this "Key" hierarchy:

                    Key
                   /   \
              PubKey   PrivKey
- ->              /       /   \
            RSAKey  DESKey  IDEAKey
             /  \
        PGPKey  PEMKey

The arrow indicates the drawing line between definition and 
implementation classes.  Note the common heritage of PGPKey and PEMKey 
with RSAKey; this could be used as a mechanism for converting between 
keys if RSAKey were implemented as a "raw" key, while PGPKey and PEMKey 
could include other key-specific baggage such as userIDs, attached 
certificates, etc.  Supposedly, then, key management and other stuff 
could be made specific to the key type, but encrypting and decrypting 
could consist of a simple:

  Boolean RSAencrypt(char *message, RSAKey &key);

(to use C++ language - substitute your own OOL if desired) and could then 
use either key format for its dirty work.  Of course, this is simplistic, 
as the encryption engine itself would probably be an object also, etc., 
etc.

There's some very rough ideas!  They're in bad need of clarification; let 
'em have it!

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLuTj6DER5KvPRd0NAQE2yAP/dqcaHUXa9UrGpGxWOg+8xs2/AhCh0TS6
0Cca76O6Ztc/vzEpBdz1iAMVa/N7DDybwTHR+wgTPjBEKoy1vqMjSPZpEk2Zwhpy
8EgQvGOHInJrMdlWssEZWn8Av1tSaYJtNrtDV2hTEB9pZSzhIi1T257gqjSrnHks
mH3qT0tQTjg=
=AXya
-----END PGP SIGNATURE-----