Re: GUCAPI (Grand Unified Crypto API)
L.Todd Masco <cactus@hks.net> writes:
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.
So, you just want a generic overlay (wrapper) to any of the existing encryption algorithms? Is this correct?
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 ...
Well, it sounds good in theory. However, trust me, Todd, writing a generic API that is multi-platfomr is not necessarily as easy as it sounds. There's alot of code in this prioject. You would also have to make sure that the API is generic so it could work in ANY program that might use encryption or digital signatures. (i.e. e-mail, USENET news, possibly even lending itself to a Secure HTTP implementation.)
(key management would be done on the basis of the method specified.)
Uh, just from a first glance, I'd say that this is going to slip gently into the ITAR pits. There are very few "methods" other than RSAREF that you could use to make this "universal". Also, would this act as a wrapper over PGP, or would it use the same concepts (and or code) to do the same things?
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.
Agreed, it would be nice to have one API. As a developer though, I panic when I see "generic" API's. Usually, they are not as "black-box" as people would like to believe. What I mean is, usually they are not just as simple as "put in this input, and you will get this output." Also, are we talking about C code or C++ code? DOS? Windows? Are we talking multi-platform code that will work on all the major OS's? For a generic API, that's alot of code...I keep saying that....must mean something. I would be interested in seeing something like this implemented, but I question whether it will be a hit as an industry standard. Generic API's really haven't gone over well for things in the past. (Except the class libraries for major C++ compilers. MFC, OWL, etc.) The design has to be robust before you start coding. Anyone else have any comments? Brad
>>>>>>>>>>>>>>>INTERNETWORKING THE DESKTOP<<<<<<<<<<<<<<<<<<<<<<< Brad Shantz bshantz@spry.com Software Engineer SPRY Inc. Direct #: (206)-442-8251 316 Occidental Ave. S. Main #: (206)-447-0300 Suite 316 Fax #: (206)-447-9008 Seattle, WA 98104 WWW URL: http://WWW.SPRY.COM
PGP Public Key at: http://www-swiss.ai.mit.edu/~bal/pks-toplev.html Or email: pgp-public-keys@pgp.ai.mit.edu Subj: GET bshantz
>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
`bshantz@spry.com' wrote:
Anyone else have any comments?
QoS considerations. If the purpose of the API is to allow polymorphic access to cryptographic operations, then you need to provide a method to select `methods' based on particular needs (you're the client, you want the assocation to meet specific contractual requirements). For example, you may specify key bounds or block sizes. At the same time, you need to reduce the interfaces complexity and overhead, which could mean for example that `limited' implementation could do without the QoS aspects; ie. elements need to be clearly seperable and orthogonal. For example, I could envisage: resp_t skcs_open (skcs_ctx * ctx, void * name, uint name_sz, uint name_type, bucket * qos, bucket * param) resp_t skcs_process (skcs_ctx * ctx, void * iblock, uint iblock_sz, unit * iblock_pos, void * oblock, uint oblock_sz, uint * oblock_pos, bitstring options) resp_t skcs_close (skcs_ctx * ctx, bitstring options) where: typedef struct bucket_str { struct bucket_str * next; void * data; uint type; uint length } bucket; and qos types could include: QOS_KEYSZ_MIN, QOS_KEYSZ_MAX, QOS_KEYSZ_RANGE, QOS_INBLOCKSZ_MIN, .... param types could include: PARAM_KEY, PARAM_IV, PARAM_FEEDBACK_BITS or something like that. But by the same token, you'd want to ensure that there is something like the following so the additional overhead of chained buckets could be avoided. resp_t skcs_set_param (skcs_ctx * ctx, void * data, uint type, uint length) The point is that the provision of such a `generic' method of specifying attributes lends itself to support a diverse set of algorithms and cryptographic modules. The `skcs_open' could well be a subset of a more generic `crypto_open'. By the same token, there could exist a `skcs_DES_open' and `skcs_IDEA_open' for use when you know the specific algorithm you want and want to avoid additional overheads. I'm only considering a cryptographic operations interface, not one that deals with more generic `security' operations, such as in GSSAPI. But there are plenty of issues to be examined and resolved. discuss away! mg. -- Matthew Gream (sw/hw engineer) <M.Gream@uts.edu.au> (02) 821-2043
I would be interested in seeing something like this implemented, but I question whether it will be a hit as an industry standard. Generic API's really haven't gone over well for things in the past. (Except the class libraries for major C++ compilers. MFC, OWL, etc.) The design has to be robust before you start coding.
Something like this should be fairly reasonable to implement in C++. The basic concept would be to have a single public abstract class with a static method that takes a protocol name and returns a pointer to an encryption engine object that implements that protocol. The actual classes could either register themselves with the base class statically at link time or dynamically via DLL's or equivalent and an OS dependent config utility. The biggest question to my mind is how to handle key management and whether the engines should require blocks of an appropriate size (eg encrypt(size_t blksize, const char *inbuf, char *outbuf)) or act as pumps with user-specified data sources and sinks (eg encrypt(istream& input, ostream& output)). Paul
participants (3)
-
bshantz＠spry.com -
M.Gream＠uts.EDU.AU -
pstemari＠fsp.fsp.com