Hi:
The recent AES-XCBC patch has given me some ideas on how to solve an old
problem.
The problem is how do we let users of the crypto layer supply parameters
to crypto algorithms. Such parameters include things like compression
factors, key lengths, etc. In the case of XCBC (and HMAC), we could
implement them as normal algorithms that take another crypto algorithm
as a parameter.
So what I have in mind is a string-based representation. For example,
SHA1-HMAC would look like "hmac(sha1)". AES-XCBC would look like
"xcbc(aes)". By the same reasoning you can have
"hmac(hmac(md5), 0x52173f0b5a27c840d16310cfc8e44d9e)"
Which means take MD5-HMAC with the specified key as a digest algorithm,
and then apply HMAC to it.
For compression we can have "deflate(11)" where 11 is the winbits
parameter. We need this because we really need to set the default
winbits to the maximum (15) in order to be able to accept whatever
other IPsec stacks can send us. While other users of deflate may
be able to get away with a smaller winbits because they only read
things that they write themselves.
These strings would be supplied by crypto users to crypto_alloc_tfm.
crypto_alloc_tfm would eat the algorithm name and give the rest to
the algorithm to interpret.
The string could also come from indirect users of the crypto layer.
For example, userspace IPsec KMs can give them to the the kernel
IPsec layer which then passes them to the crypto layer unchanged.
Does this look sane? Any better ideas on solving this problem?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
