[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GUCAPI (Grand Unified Crypto API)
L.Todd Masco <[email protected]> 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 [email protected]
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: [email protected] Subj: GET bshantz
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<