`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