From: M.Gream@uts.EDU.AU (Matthew Gream)
Date: Tue, 6 Dec 94 16:04:34 PST
To: bshantz@spry.com
Subject: Re: GUCAPI (Grand Unified Crypto API)
In-Reply-To: <9412062142.AA08621@homer.spry.com>
Message-ID: <199412070002.AB13209@sequoia.itd.uts.EDU.AU>
MIME-Version: 1.0
Content-Type: text/plain



`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