On Mon, Jan 16, 2006 at 12:06:32PM +1100, Herbert Xu ([EMAIL PROTECTED]) wrote: > 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?
Yep. But it still requires some kind of parsing in kernel: what if we will have "deflate(a,b)", and "defalate(a, default_b)"? Will all such strings userspace parsing end up in userspace requests for tons of the same module, but different algorith strings? Although we can only allow to have "deflate" and "defalte(all parameters)"... > 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. Such strings are perfectly fine, but what will happen when someone calls "cbc(cbc(cbc(...(aes)))"? What if we create restriction and allow to only call "basic" algo creations, and then link them at setup() time? I.e. tfm1 = tfm_alloc_method(xcbc); tfm2 = tfm_alloc_method(xcbc); tfm3 = tfm_alloc_cipher(aes); tfm2->setup(tfm3); // "cbc(aes)" tfm1->setup(tfm2); // "cbc(cbc(aes))" And call such chains from inside of the parsing state machine. Is it you idea, Herbert? > 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 -- Evgeniy Polyakov - 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
