From: "L. Todd Masco" <cactus@hks.net>
Date: Tue, 6 Dec 94 13:15:01 PST
To: cypherpunks@toad.com
Subject: GUCAPI (Grand Unified Crypto API)
Message-ID: <199412062119.QAA14522@bb.hks.net>
MIME-Version: 1.0
Content-Type: text/plain


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


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:

guc_init_crypto();
guc_encrypt();
guc_decrypt();
guc_assemble();

guc_key_get();
guc_key_put();
guc_key_gen();

So, to encrypt a PGP-style message, you'd:

	guc_init_cypto("PGP_26", &context, &keys, &message );

Which would initialize whatever random vectors you're likely to need for
a PGP session and allocate the appropriate space to the pointers.  The
types should be totally opaque, implemented in the library.

	guc_key_gen("PGP_26", &keys);

Which would generate a session key for IDEA and grow the keys structure
appropriately;

	guc_get_key("PGP_26", &keys, originator);
	guc_get_key("PGP_26", &keys, recipient1);
	guc_get_key("PGP_26", &keys, recipient2);
	...

Which would grow the keys structure and add in appropriate RSA keys.  
(Alternatively, it could be done as one vector with all the recipients
lists).

	guc_encrypt("PGP_26", &keys, &input, &message);

Which would encrypt the IDEA session key with the appropriate RSA key and
the input with the IDEA session key. And,

	guc_seal("PGP_26", &message, &output);

Which would put the messages into the appropriate (Radix-64?) format and
put it out to the output, (the output structure would specify whether
memory is to be allocated and filled, files written to, whatever).

My goal is to come up with an API that could be integrated once into an
application and would be flexible enough that new crypto methods, whether
ciphers or key management, could be supported entirely by upgrading the
library.  This includes being flexible enough to cover as diverse
methods as OTPs (where the init function would open a file or other
pad as its "random vector," key retrieval would be a noop, and encode
would just XOR) and PEM (key management would be done on the basis of
the method specified.  I'm fuzzy on how to generalize key management
into a model that would include both web-of-trust and PEM-style certificates,
so conversation on this would be greatly appreciated).

It seems to me that the benefits are pretty clear: Set up such an API
as a spec that can be implemented both inside and outside of the US and
it allows everybody to implement to one API.  There's no good reason to
have a bazillion different crypto APIs if a generalized one can be 
achieved.

I've posted about this before and received no response: since I'd like to
solidify the API soon so I can firm up the coding I'm doing, I ask that
folks take the time to comment.  The code I end up producing will be 
publicly available, possibly as a "non-commercial use" copyright, perhaps
PD. 

Thoughts?
- --
Todd Masco     | "'When _I_ use a word,' Humpty-Dumpty said, in a rather
cactus@hks.net |  scornful tone, 'it means just what I choose it to mean -
cactus@bb.com  |  neither more nor less.'"   - Lewis Carroll

- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLuTVNCoZzwIn1bdtAQFK1AGA16g1wgKMc4qg3SVxDMW3y+1IGeWDbVvj
Q6uqlRmyaFNm1NjNfV0gCxZgAZ9oM338
=br4C
-----END PGP SIGNATURE-----