Subject: IV carry

From: Simon Josefsson <[email-masked]>
Date: Sun, 24 Aug 2003 05:54:38 +0200

KCRYPTO:

   encryption/decryption functions, E and D
      These are basic encryption and decryption functions for messages
      of sizes that are multiples of the message block size.  No
      integrity checking or confounder should be included here.  These
      functions take as input the IV or similar data, a protocol-format
      key, and a octet string, returning a new IV and octet string.
...
encryption function       conf = random string of length c
                          pad = shortest string to bring confounder
                                and plaintext to a length that's a
                                multiple of m
                          C1 = E(Ke, conf | plaintext | pad,
                                 oldstate.ivec)
                          H1 = HMAC(Ki, conf | plaintext | pad)
                          ciphertext =  C1 | H1[1..h]
                          newstate.ivec = last c of C1

What is the point of E returning a next IV, when the last c of C1 is
always used as the next IV?

The question is prompted by the AES specification: it is not clear
what the next IV for CBC-CTS returned by E should be, and the RC5 and
AC references for CTS doesn't appear to discuss next IV's either.  It
is (to me) not clear that using the last c of C1 as next IV is safe,
for CBC-CTS.  Consider encrypting a string of length divisible by the
block length, then CBC-CTS equals CBC but with the last two block
swapped.  If you use the last block as the next IV then it appears
this IV is involved in encrypting both the Cn-1 block and the C0 block
in the next encryption operation.  The C0 block is the confounder, so
it is not obviously a problem, but not obviously not a problem either.

Please advice,
Simon

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 25 Aug 2003 17:17:53 -0400

> always used as the next IV?

Yes, that appears to be an error.  Sloppy of me.  Thanks for catching
it.

The IV going forward should be specified in one place or the other.
Having E/D return no IV makes their specification simpler, and is a
straightforward simplification of the spec we put through last call
(omitting a supposed output which can never be used).  But making it
part of the specification of every E/D function may give a bit more
confidence in the resulting security.  Any opinions which it should
be?

> it is not obviously a problem, but not obviously not a problem either.

It's not too clear to me either whether it would be safe in a "normal"
situation, but since the only thing done with it is the XOR with the
random confounder, I'm not worried.  I can't express "not worried" in
formal language though. :-)

If we do decide that E/D should specify the IV to go forward, for the
CBC-CTS case, we could just use the next to last ciphertext block and
not worry about it.  (That corresponds to the last block in normal
CBC+padding.)

Ken

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 Aug 2003 03:37:58 +0200

> confidence in the resulting security.  Any opinions which it should

The latter, IMHO.  The next IV is an intrinsic part of an encryption
scheme; using the last encryption block as next IV seems to add an
assumption on the underlying scheme.

> not worry about it.  (That corresponds to the last block in normal

Yes.  It might be good to find some specification for CBC-CTS that
discuss the next-IV, and reference it, instead.  Or at least provide
ANY evidence that CBC-CTS implementations traditionally uses the
next-to-last ciphertext block as next-IV.  Specifying a non-standard
variation of CBC encryption, without solid justification like a
security proof, doesn't sound like a good idea to me.

Thanks.