Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-07.txt

[Greg Hudson <[e-mail]>]

On 12/03/2015 01:32 PM, Peck, Michael A wrote:
> We would appreciate working group feedback on this new finally posted draft.

I'm looking at the description of ciphertext state in this draft versus
the description in RFC 3962.  RFC 3962 says:

   The initial vector carried out from one encryption for use in a
   subsequent encryption is the next-to-last block of the encryption
   output; this is the encrypted form of the last plaintext block.  When
   decrypting, the next-to-last block of the supplied ciphertext is
   carried forward as the next initial vector.  If only one ciphertext
   block is available (decrypting one block, or encrypting one block or
   less), then that one block is carried out instead.

The draft says:

      ciphertext = C | H[1..h]
      cipherstate = the last full (128 bit) block of C
      (i.e. the next-to-last block if the last block
      is not a full 128 bits)

I believe the intent was to align the draft with RFC 3962 (in that a
previous version of the draft used a simpler construction involving the
confounder, and it was later changed), but these definitions are not
identical when the last plaintext block is a full 128 bits, unless I'm
missing something.

As an implementor, I would like to reuse the AES enc-provider in MIT
krb5, which consumes and outputs ciphertext state, so I would prefer
that the definitions align.  It looks like Luke's implementation for
Heimdal also reuses the _krb5_evp_encrypt_cts() function, which consumes
and outputs ciphertext state.

(This discussion does not affect the test vectors, which do not use
cipher state.  Cipher state is really only used for the obsolete krb5
rlogin, as far as I know.)