Messages in this thread | | | Subject | Re: Crypto API and keyed non-HMAC digest algorithms / Michael MIC | From | Clay Haapala <> | Date | Tue, 09 Mar 2004 11:30:36 -0600 |
| |
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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |