Re: Crypto API and keyed non-HMAC digest algorithms / Michael MIC

[Clay Haapala]

On Tue, 9 Mar 2004, Jouni Malinen outgrape:
>> On Tue, 9 Mar 2004, Clay Haapala wrote:
>> > I had the same thought in my attempt at adding CRC32C to the
>> > crypto routines, that what was needed was "digests + setkey".
>> > But I didn't want to add the key baggage to digests, and so
>> > created a new alg type (CHKSUM), with pretty much identical code
>> > to digest, but with a modified init and a new setkey interface.
> 
> On Tue, Mar 09, 2004 at 03:32:58PM -0500, James Morris wrote:
>> I think that adding a setkey method for digests is the simplest
>> approach.
> 
> 
> I took a quick look at the CRC32C patch and it looked like the only
> needed change for the digest type was the new handler for setting a
> 32-bit seed. I used setkey handler that takes an arbitrary key data
> and length (Michael MIC uses 64-bit key/seed). As far as I could
> tell, this setkey function should be enough for CRC32C needs,
> too. Clay, please let me know if I missed something here. James,
> please consider merging this into Linux 2.6 tree if there are no
> issues with CRC32C.
> 

I believe that is all that CRC32C requires.  I had hesitated to add
the setkey/setseed method because I mentally had it tied to "init",
which is not necessary, as your patch shows.  I also didn't know what
to do with the "&flags" parameter, but I gather that passing it in and
not using it is fine.  Should "unsigned int keylen" be also "const" or
does that matter?

>  
> +static int setkey(struct crypto_tfm *tfm, const u8 *key, unsigned
> +int keylen) { u32 flags; if (tfm->__crt_alg->cra_digest.dia_setkey
> +== NULL) return -1; return
> +tfm->__crt_alg->cra_digest.dia_setkey(crypto_tfm_ctx(tfm), key,
> +keylen, &flags);
> +}
> +

-- 
Clay Haapala (chaapala@xxxxxxxxx) Cisco Systems SRBU +1 763-398-1056
   6450 Wedgwood Rd, Suite 130 Maple Grove MN 55311 PGP: C89240AD
  Windows XP 'Reloaded'?  *Reloaded?*  Have they no sense of irony?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/