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