Re: GUCAPI (Grand Unified Crypto API)

["L. Todd Masco" <cactus@hks.net>]

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


bshantz@spry.com writes:
 > 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?

More or less.  It doesn't need to implement everything straight off: the
API itself just has to pass all the information that's necessary. 

 > >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 
Actually, I'm not talking about implementing the library in a multi-platform
way.  Once the API is specified, people could be found who would do the 
implementation for any given platform.  I'd do a UNIX version that would
straight off translate appropriate calls to RSAREF for RSA calls and
implement IDEA.  A friend of mine is interested in doing the PC version .

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

Encryption is a pretty straightforward process in the abstract:  While
such an API might not be well suited to hyper-fast stream methods, it would
be Good Enough to have something that could be integrated into mail and
news easily.  News and mail are doing the same thing: a big part of the
difficulty in getting integrated support is in the cumbersome interface
to PGP and the percieved short horizon on PGP changes.  If a unified API
promised that a crypto API would stay put, I think more people would be
hacking code.

I'm not talking about implementing it all at once.  In essence,
a PGP engine that used these calls would be useful because people could
implement MUAs and newsreaders (and perhaps web browsers) that easily
integrated PGP encryption by linking with the newest version of the PGP
distribution: and then, as newer methods and formats came along, all
that would be required would be a relink to support new formats (another
function, BTW, would be a guc_parse_format() that would determine the
format of the input).

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

Only the spec itself need be exported, no crypto code or even hooks.
RSAREF would have to be part of the RSA methods inside the US: outside, it
would probably end up being the old PGP code that the current 2.6ui-style
PGPs use.

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

Certainly, some APIs are much better than others.  The C stdlib, for
example, is a pretty good API.  Stdio does a very good job of abstracting
concepts to calls that work across filesystems as different as VMS's
RMS and MS-DOS filesystems.  I'm talking about C -- not every platform
supports C++.  The OS isn't important: the API can be implemented
independently.

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

Frankly, I don't give a damn about it becoming an "idustry standard" if that
means Microsoft, Lotus, etc.  I have no interest in doing their work for
them.  I'm more interested in generating a "net-standard," something that
people hacking code for themselves or for freely-distributable packages
can use.  It's a necessary step along the road to "crypto for the masses."
- --
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

iQBFAwUBLuTkJioZzwIn1bdtAQFEhwF7Bo0K7ZwWDlYtaB46B4kpwOM/jXY0pLrT
Q/y84MBu6Z7nwt75X+r0Y93rpBon1QQh
=VWmR
-----END PGP SIGNATURE-----