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