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

[Clay Haapala <chaapala@cisco.com>]

On Tue, 9 Mar 2004, James Morris uttered the following:
> On Mon, 8 Mar 2004, Jouni Malinen wrote:
>> If you prefer, I can make a new type crypto alg type
>> (CRYPTO_ALG_TYPE_KEYED_DIGEST) and make it a clone of the
>> CRYPTO_ALG_TYPE_DIGEST with the only change of adding a new
>> callback, setkey, in the way I added in the patch for
>> CRYPTO_ALG_TYPE_DIGEST. This would leave the digest type
>> unmodified, but would result in copying most of the digest code. I
>> do not see much benefit of this because the dia_setkey function
>> pointer does not seem to change the old digest functionality at all
>> since it is optional and since this function pointer does not even
>> enlarge struct crypto_alg due to the cra_u union already being a
>> bit larger than the current struct digest_alg.
> 
> Agreed.  I really wanted to keep digests 'pure', and not implement a
> setkey method, but it seems like the simplest way at this stage.
> 
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.

So, we could modify digests now, or perhaps Jouni and I could combine
our code into a new KEYED_DIGEST type and leave digests 'pure'.
What's best?

-- 
Clay Haapala (chaapala@cisco.com) 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?