Subject: [kitten] Request for summary of issues with existing AES-CTS with new SHA2

From: Michiko Short <[email-masked]>
Date: Tue, 29 Oct 2013 21:18:47 +0000

Can someone summarize what the issues blocking using the existing AES-CTS with SHA2? We have had several discussions over the past months discussing various aspects, but it is unclear to me what the blockers were that makes what we all implemented for SHA1 not feasible for SHA2.

Thanks,
Michiko Short | Program Manager | Windows Security & Identity

---

From: "Peck, Michael A" <[email-masked]>
Date: Wed, 30 Oct 2013 14:33:05 +0000

Michiko,

First, regarding the CTS vs. CBC with PKCS#7 padding question, we the document editors are of course happy to go along with whatever consensus the working group comes to.
Our latest CTS-based draft is at: http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-01
Our latest CBC with PKCS#7 padding draft is at: http://tools.ietf.org/html/draft-ietf-kitten-aes-cbc-hmac-sha2-00

In the Introduction of both drafts we have a section describing the differences between them and the existing Kerberos AES specification (RFC 3961/3962).
Our goal was to update to SHA2 and also follow current best cryptographic practices.
For example, unlike RFC3961 we follow the current best practice of Encrypt-then-MAC.
For CTS, we use the definition in the NIST Special Publication 800-38A Addendum, which uses an explicit IV instead of a confounder.
Unfortunately the NIST definition doesn’t deal with plaintext lengths equal to or less than the AES block size, so we added text in Section 5 to cover that situation for completeness, even if it might never happen in reality.

The CTS draft states:

*  The pseudorandom function used by PBKDF2 is HMAC-SHA-256 or HMAC-
      SHA-384.

   *  A key derivation function from [SP800-108<http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-01#ref-SP800-108>] which uses the SHA-256
      or SHA-384 hash algorithm is used to produce keys for encryption,
      integrity protection, and checksum operations.

   *  The IV used during content encryption is sent as part of the
      ciphertext, instead of using a confounder. This saves one
      encryption and decryption operation per message.

   *  The HMAC is calculated over the AES output, instead of being
      calculated over the plaintext.  This allows the message receiver
      to verify the integrity of the message before decrypting the
      message.

   *  The HMAC algorithm uses the SHA-256 or SHA-384 hash algorithm for
      integrity protection and checksum operations.

From: Michiko Short <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 29, 2013 5:18 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Anoosh Saboori <[email-masked]<mailto:[email-masked]>>
Subject: [kitten] Request for summary of issues with existing AES-CTS with new SHA2

Thanks,