Laszlo has made a very good point; and the proposed extension does indeed
satisfy the dependencies.
Shai said:
> > The ciphertext-stealing construction above clearly does no have this
> > property (since C_I does not depend on P_{I+1}).
Why should it? All the earlier C_n blocks in the sector only have a dependency
on their
corresponding plaintext block P_n, and nothing else. So why should the
requirement for C_I be any
different. The key thing is that the I values are distinct for both (I, I+1)
LRW calls. The fact
that C' is included in the last block is merely extra entropy for that last
encryption.
FWIW, Shai has drawn the input to the final block, C' || P_{I+1} the wrong way
around,
it should be P_{I+1} || C' to maintain alignment in hardware, with no security
implications.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> [EMAIL PROTECTED]
> Sent: 15 December 2005 21:17
> To: SISWG
> Subject: RE: Security of ciphertext-stealing
>
>
> Shai, Instead of the property that the CTS scheme is a tweakable cipher
> for 128+k bits, it looks sufficient, that any ciphertext bit is
> dependent on at least 128 plaintext bits (in encryption), and every
> plaintext bit is dependent on at least 128 ciphertext bits (in
> decryption). If you could prove that this dependence is of complexity
> comparable to an LRW operation, we were done. -Laszlo
>
> > -------- Original Message --------
> > Subject: Security of ciphertext-stealing
> > From: Shai Halevi <[EMAIL PROTECTED]>
> > Date: Thu, December 15, 2005 3:34 pm
> > To: SISWG <[EMAIL PROTECTED]>
> >
> > Here is an ascii drawing of Don's proposal (just so that I can refer
> > to these notations later). LRW(x) means LRW with tweak value x:
> >
> > P_I C' P_{I+1}
> > | |
> > v v
> > +---------+ +---------+
> > | LRW(I) | | LRW(I+1)|
> > +---------+ +---------+
> > | |
> > v v
> > C_I C' C_{I+1}
> >
> > (You may want to output C_I after C_{I+1}, but that's irrelevant for
> > security.)
> >
> > The "security feature" that I was hoping to get for blocks of "odd size"
> > is that the transformation
> >
> > (P_I P_{I+1}) -> (C_I, C_{I+1})
> >
> > looks like a tweakable block cipher with blocks of size |P_I|+|P_{I+1}|
> > and tweak value of I.
> >
> > The ciphertext-stealing construction above clearly does no have this
> > property (since C_I does not depend on P_{I+1}). One can then ask the
> > following questions:
> >
> > (a) What security property IS archived by this construction? (And can we
> > prove it?)
> >
> > (b) Is the difference between what the above achieves and the "tweakable
> > block" notion something that we should worry about? Does it translate to
> > an attack in any realistic model?
> >
> > I still didn't have enough time to think about it to answer any of these
> > questions (I'll try to do it within a week or two). But I thought that
> > it is worthwhile posting these questions here, so other can try to think
> > about them as well.
> >
> > -- Shai
>
