On Sun, Jan 15, 2006 at 03:53:38PM +0300, Evgeniy Polyakov wrote: > > It can be struct crypto_config, > which will contain common to every crypto entity parameters > and size of attached private structure, which will have special data.
Actually you gave me an idea that could move the parsing out of kernel space. Instead of having the tfm objects receive the parameters either at allocation time (through crypto_alloc_tfm) or after allocation (through the setup function you mentioned), we can move the parameters in the crypto_alg object itself. For example, to allocate a "deflate(15)" tfm, you first check to see if a crypto_alg object with the name "deflate(15)" exists. If it doesn't, you would ask the deflate module (this part doesn't exist yet and will need be written) to instantiate a crypto_alg object with the win parameter of 15. This instance would then be registered under the name "deflate(15)". If we went this way, then the parsing of deflate(15) and the request to the deflate module could be done in userspace. The notification and request can take place through netlink. Evgeniy, does this resolve your concerns about parsing strings in the kernel? On a different note, someone was asking me about how cumbersome it is to add new block chaining methods. We could actually use what I outlined earlier wrt HMAC/XBC to solve that problem. For example, instead of having an "aes" crypto_alg object that does all of ECB/CBC/CFB/... we'll have only the base aes algorithm which just does a single block. We can then have generic ECB/CBC/CFB/... implementations that are simply cipher implementations like AES except that they take a base cipher as a parameter. So if you request an algorithm of type "cbc(aes)" the system would first go and look for an exact match which could be hardware devices (including the PadLock) that implement AES+CBC directly. If such a match couldn't be found, we would then notify some userspace daemon which would parse the string and make a request to the generic CBC algorithm to instantiate a copy of itself with the cipher algorithm set to "aes". This crypto_alg object would be registered under the name of "cbc(aes)" with a suitably low priority. 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
