GUCAPI (Grand Unified Crypto API)

[bshantz at spry.com]

L.Todd Masco <cactus at 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 at 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 at pgp.ai.mit.edu Subj: GET bshantz
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<