New Mechanisms subgroup Part 1 or 4 new in v2.3

[Robert Relyea <rrelyea@redhat.com>]

Part 1: Mechanisms in draft form in the PKCS #11 v2.3 spec.

CKM_AES_CTR
CKM_AES_GCM
CKM_AES_CCM
CKM_AES_CTS

Red Hat has implemented CTR, GCM, and CTS according to draft 7. We used 
the following mechanism numbers.

/* new for v2.30 */
#define CKM_AES_CTR                    0x00001086
#define CKM_AES_GCM                    0x00001087
#define CKM_AES_CCM                    0x00001088
#define CKM_AES_CTS                    0x00001089

In implementing, we found the following issues:


----- GCM ---
NIST requires that no data be returned from decrypt until the gmac has 
been verified. This means there is a little ambiguity as to whether 
C_EncryptUpdate() should return a fully mac'ed data, or whether the mac 
should be generated in C_Encrypt final.

In the decrypt case, if the mac is included in the C_DecryptUpdate(), it 
can meet the NIST requirement, but if the MAC is only sent at the end, 
then the full decrypt data would not be available until C_DecryptFinal().

AEAD fits the C_EncryptUpdate/C_DecrypteUpdate having a fully mac'ed 
value. Because of the abmiguity, Red Hat disabled 
C_EncryptUpdate/C_DecryptUpdate, but instead we only implemented GCM as 
a single-shot encryption (a.la. RSA):

C_EncryptInit()
C_Encrypt()

and.

C_DecryptInit()
C_Decrypt()

In repeated calls. This removed the worry about what the meaning of the 
output for the second C_DecryptUpdate() was (no new AAD, use the same 
AAD?) and how the internal IV changes.  Similiar argument for 
C_EncryptInit/C_Encrypt/C_EncryptUpdate. It probably makes sense to do 
the conservative thing in the spec as well.

Oracle implemented the meaning that from C_EncryptInit() to 
C_EncryptFinal() is a single GCM operation with the MAC returned in 
final. On Decrypt, C_DecryptUpdate() returns no data and buffers it. 
C_DecryptFinal() returns the entire decryption.

If the PKCS #11 group wants to allow C_EncryptUpdate/C_DecryptUpdate, 
then we need to decide which semantic we want and make it explicit in 
the spec.

----- CCM ---
We did not implement CCM. It would have the same issues. Longer term we 
may want a new function for IETF AEAD type functions ( see rfc 5166).

------ CTR ---
There were no issues with CTR, the spec is pretty straighforward.

------ CTS ---
A few things. First: though it wasn't clear, the only thing that makes 
sense for the spec is that each C_EncryptUpate call returns CTS data. 
That means that each C_EncryptUpdate/C_DecryptUpdate call must have a 
length > blocksize length. The spec does say that, but in a way that 
many interpret to mean only C_Encrypt/C_Decrypt (which conflicts with 
the explicit statement aht C_Finalize doesn't return anything).

Second, we should be clear what the next IV is when multiple 
C_EncryptUpdate calls are made. We can alieviate both problems the same 
way we handled GCM (making it single shot), though in this case we 
didn't implement a single-shot only approach. Oracle would be OK with 
the single shot approach.

The other issue is an issue with the definition of CTS. The spec simply 
references NIST SP 800-38A. Unfortunately this spec actually defines 3 
different CTS formats:

Type 1, or NIST.
Type 2, or Schneier.
Type 3, or Kerberos.

(English labels are my own, based on where the type is used/defined). 
The difference between these types is the order of the sent blocks. The 
output of CTS includes full AES blocks: C0, C1, C2 ... Cn-2, Cn. and one 
partial block Cn-1. The types are as follows:

Type 1: C0, C1, C2 ... Cn-2, Cn-1, Cn
Type 3: C0, C1, C2 ... Cn-2, Cn, Cn-1
Type 2: if len(Cn-1) == blocksize, like Type 1 else like Type 3.

Here are the purposes of the different block orders:
Type 1 and Type 2 make CTS degenerate to CBC if the plaintext length is 
a multiple of the AES block size (so CTS is completely compatible to CBC 
if the data is already chunked by the AES blocksize).
Type 1 and Type 3 are consistent in their the block order, independent 
of the data size.
Type 2 and Type 3 are easier to parse in the decrypt case, because it's 
easier to identify the the partial block, Cn-1 if it's at the end of the 
data.

We implemented Type 1, assuming that that is the type the spec meant 
when it referenced the NIST documents. It's relatively easy to convert 
any of the different types at the application layer given just the 
cipher text and the length.

Kerberos is the major use of CTS (including our use), so oracle would 
prefer kerberos style. I would prefer this to have a diffferent 
mechanism number than above, if we go with Kerberos style. (Note, if you 
know what kind of CTS style you have and what type of style you want.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature