Why the per-message IV is NOT always the same as the last block of the previous message in AES-CBC and other Ruminations

[Michael StJohns <msj@nthpermutation.com>]

There are any number of "protocols" that select IVs on a per "message" basis (including TLS).    See below.  The fact that we had such a discussion and that it took as long as it did is pretty good evidence that we're not solving the right set of problems.

Any solution to the message  based encryption solution that does not understand that there is NO guarantee of state derived from a previous message being useful for encrypting/decryption a later message is a non-starter.

So once again - the three problems that are not necessarily related:

1) Message-based processing for sign/encrypt/decrypt/verify.  One of the main reasons for doing this is to deal with network latency for network connected HSMs (reduce the number of round trips).    However, there are single key, large data applications which could benefit from this as well so the message based processing should not artificially limit the length of the data that can be processed.

2) Provide better AEAD support.  While the CCM and GCM modes) are pretty much used for network message based functionality (TLS IPSEC SSH Zigbee etc), there are other usages (bulk encryption of stored data, key wrapping etc) that tend to be one-offs.  AEAD support should NOT depend on Message Based processing.  Also, there looks like a trend to combine existing encrypt/sign mechanisms in some semblances of AEAD so any solution here should not depend on existing mechanisms.

3) Per-message parameter generation (E.g. IV generation for CCM and GCM, but also for CBC, CTS etc).  Given that there are lots of different ways to generate IVs and that those mechanisms are not necessarily tied to the mode (I count at least three or four ways for CBC),  the parameter generation model should not be part of the mechanism. 

Wan-Teh's proposal was targeted at solving all of these problems, but continues to lean on the existence of specific protocol implementations in selecting the API.    In fact he suggests that S/MIME would have to change (Note #1 after C_EncryptMessage description) - "since both TLS and IPSec were successfully revised" to better support AEAD algorithms and to meet his particular approach.  (I find this problematic - the guy who wrote CCM - Russ Housley - also wrote the S/Mime use of CCM and GCM).  The particular issue I have is the assumption he's making that the integrity tag is part of the ciphertext.  I believe that is a non-starter both for CCM in particular and AEAD in general.



So action items:

1) What is an association?   My definitions is it's the collection of data necessary to encrypt/decrypt/sign/verify messages between two parties - the traffic keys and mechanisms (and external to PKCS11 message formats and meanings).  It does not include the per-message IV data directly, but may contain an IV generator on either side. 

2) What is cryptographic state (called "cryptographic operations state" in pkcs11v220)?  For the existing PKCS11 V2.20/2.40 its the state information that exists beginning with a C_*Init and is deleted after a C_*Final.  In a PKCS11 v2.20 SESSION, there can only be one state, but it can contain state from two different operations - an encrypt/decrypt or a sign/verify.   PKCS11 does not require that a saved state (C_GetOperationState) include key material, but permits it.  An attempt to call C_GetOperationState outside of a C_*Init/C_*Final bracket results in an error (CKR_OPERATION_NOT_INITIALIZED) which further indicates that cryptographic state does not survive C_*Final.

3) What is cryptographic state in an association or message based model?  That's the question to answer.  In my model, a C_NewAssociation (or whatever its called) creates either an implicit or explicit object that contains the key material (as referenced by a key handle), a specific mechanism, an indication as to whether this is being used by the sender or by the recipient,  and an optional parameter generator (IV generator).  An implementer MAY do any one-time initialization (e.g. key expansion, hashing schedule etc) as part of the association setup, or defer it to the first call to actually process a message. 

 I would leave the definition of "cryptographic operations state" as it currently is and leave C_GetOperationState and C_SetOperationState to operate only within the C_*Init and C_*Final boundaries as it does now.

I would need to understand why you would want to save/restore associations.  If the limitation is the one association per session, then a better solution is to create the association as an explicit container object with its own handle which contains the key, mechanism, iv generator, direction and possibly the session handle.  Pass the handle to the container object in place of  (or in addition to) the hSession handle to the appropriate message based functions.







First from RFC3602

.  ESP Payload

   The ESP payload is made up of the IV followed by raw cipher-text.
   Thus the payload field, as defined in [ESP], is broken down according
   to the following diagram:

   +---------------+---------------+---------------+---------------+
   |                                                               |
   +               Initialization Vector (16 octets)               +
   |                                                               |
   +---------------+---------------+---------------+---------------+
   |                                                               |
   ~ Encrypted Payload (variable length, a multiple of 16 octets)  ~
   |                                                               |
   +---------------------------------------------------------------+

   The IV field MUST be the same size as the block size of the cipher
   algorithm being used.  The IV MUST be chosen at random, and MUST be
   unpredictable.

   Including the IV in each datagram ensures that decryption of each
   received datagram can be performed, even when some datagrams are
   dropped, or datagrams are re-ordered in transit.

   To avoid CBC encryption of very similar plaintext blocks in different
   packets, implementations MUST NOT use a counter or other low-Hamming
   distance source for IVs.

Then from a kitten draft
http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-01

.  Kerberos Algorithm Protocol Parameters

   In cases where the plaintext length is greater than the block size:

      Each encryption will use a 16-octet nonce generated at random by
      the message originator.  The initialization vector (IV) used by
      AES is obtained by xoring the random nonce with the cipherstate.

      The ciphertext is the concatenation of the random nonce, the
      output of AES in CBC-CS3 mode, and the HMAC of the nonce
      concatenated with the AES output.  The HMAC is computed using
      either SHA-256 or SHA-384.  The output of SHA-256 is truncated to
      128 bits and the output of SHA-384 is truncated to 192 bits.
      Sample test vectors are given in Appendix A.

      Decryption is performed by removing the HMAC, verifying the HMAC
      against the remainder, and then decrypting the remainder if the
      HMAC is correct.

   In cases where the plaintext length is less than or equal to the
   block size, a different algorithm is specified.

      Each encryption will use a 16-octet nonce generated at random by
      the message originator.  The initialization vector (IV) used by
      AES is obtained by xoring the random nonce with the cipherstate.

And if you go on to read TLS1.1 - RFC4346 section 6.2.3.2 you'll find that the "use the last CBC block of the previous message as the IV for the next message " has been deprecated for 8 years.