On Mon, 2005-01-24 at 14:31 -0800, Andrew Morton wrote: > Fruhwirth Clemens <[EMAIL PROTECTED]> wrote: > > > > This patch adds the ability for a cipher mode to store cipher mode specific > > information in crypto_tfm. This is necessary for LRW's precomputed > > GF-multiplication tables. > > These patches clash badly with Michael Ludvig's work: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm1/broken-out/cryptoapi-prepare-for-processing-multiple-buffers-at.patch > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm1/broken-out/cryptoapi-update-padlock-to-process-multiple-blocks-at.patch > > so someone's going to have to rework things. Ordinarily Michael would go > first due to test coverage.
I already pointed that out to Michael. His reply was that he will look at my tweakable extensions. Let me bring forward a proposal to the multiblock function lookup of Michael's patch in crypt(..) I think this selection should be done much earlier, in crypto_init_cipher_flags. The tfm's encrypt/decrypt interfaces (there are three ATM, ECB, IV-based, tweak-based) should be initialized with an appropriate pointer to a stub multiblock function, if there is one for the given cipher mode and the given interface type. Either this function is a stub like for instance my cbc_process_gw or it's a stub for a multiblock function, that do the necessary preprocessing (kmalloc). Both can then call the generic scatterwalker after that. The different number of arguments are _no_ problem for the generic scatterwalker, that's what it was designed for. If the stub is for a software call, then we won't have to do the somewhat expensive aligned kmalloc call, as this isn't needed for software anyway. In the software implementation, one can set the .buf field of the scatterwalker's walk_info to a stack based buffer, and in the multiblock version, just do the kmalloc. My design allows any variation. That would be a way to deconcentrate the two code paths in crypt(..). -- Fruhwirth Clemens <[EMAIL PROTECTED]> http://clemens.endorphin.org
signature.asc
Description: This is a digitally signed message part
