Re: [PATCH 01/04] Adding cipher mode context information tocrypto_tfm

[Fruhwirth Clemens]

On Mon, 2005-01-24 at 14:31 -0800, Andrew Morton wrote:
> Fruhwirth Clemens <clemens@xxxxxxxxxxxxx> 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 <clemens@xxxxxxxxxxxxx>  http://clemens.endorphin.org

Attachment: signature.asc
Description: This is a digitally signed message part