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

[Fruhwirth Clemens]

On Wed, 2005-02-09 at 20:42 -0500, James Morris wrote:
> On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
> 
> > Because a tweak is different from an IV. There can be an arbitrary
> > number of tweaks. For instance, EME takes 1 tweak per 512 bytes. If you
> > have a 4k page to encrypt, you have to process 8 tweaks of whatever
> > size. 
> >  Therefore, you need 3 scatterlists: src, dst and the running along
> > tweak.
> 
> The purpose of the scatterlists is to be able to process discontigous data 
> at the page level.
> 
> The tweak, as I understand it, is something which you generate, and it is 
> not inherently likely to be page-level clumps of data.  It does not ever 
> need to be kmapped.

For LRW, the tweak is exactly as large as the bulk data itself, so
tweaksize = blocksize. Yes, it is usually generated and sequential, but
that may not be the case. I like to put the generation of the tweaks at
the client side, because it knows best where the tweaks come from and if
it likes fragmented tweaks or not.

Further, this interface is more naturally to any other tweakable cipher
mode. In contrast to a regular cipher:

E: {0,1}^k  x  {0,1}^n -> {0,1}^n

a tweakable cipher is:

E: {0,1}^k  x  {0,1}^t  x  {0,1}^n -> {0,1}^n

where k is key size, n block size and t is tweak size.
( http://www.cs.berkeley.edu/%7Edaw/papers/tweak-crypto02.ps )

In the special case of LRW, it would be possible to squeeze it into an
IV styled interface, which does auto-incrementation. But that's flawed.
It would put functionality, where it does not belong. Witha  tweakable
mode, the blocks are independent and are not linked in any way. The
interface should reflect this.

> What you really need to do is use an array for the tweak (or possibly a
> structure which maintains state about it if needed).

The LRW cipher mode is stateless. There is context information, but this
only a cache. Same applies for EME, and it's fellows.

-- 
Fruhwirth Clemens <clemens@xxxxxxxxxxxxx>  http://clemens.endorphin.org

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