OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: AEAD - Wan Teh's proposal

Hi -

I was listening in via phone during the F2F, but unfortunately I ended up in a dead spot just as Wan Teh started talking about his AEAD proposal, so I pretty much missed any context information not present in his slides. It's possible some of my comments below will be OBE based on those - so bear with me.

I made a somewhat different proposal on the list back on 15 Feb but heard no direct comments back. At the end of my proposal I listed a number of characteristics of my proposal and I'm going to try and compare Wan Teh's proposal to mine point by point.

This approach

a) allows for any length of message or encrypted stream (e.g. while the mechanism may restrict this, the API doesn't)
Based on slide 16, Wan Teh's proposal supports this.

b) makes no assumption about whether or not decrypted data may be released before the integrity tag is verified. (again, mechanism or mode of HSM may restrict this).

Slide 9 appears to require all modes that use AEAD decryption to not release data until the tag is verified. I believe this should not be a characteristic of the API, but of specific modes or even of the HSM in a specific (e.g. FIPS) mode.

c) has no requirement for pre-call marshalling and formatting of the crypto stream (e.g. no assumptions about exactly where the integrity tag is and its length nor where the AAD is and its length - no memory to memory copies should be required prior to the call).

Slide 13 appears to indicate that Wan Teh's proposal does not support this. AFAIK ALL existing AEAD algorithms have an identifiable set of bytes that are the integrity tag. In protocols, generally, but not always, the tag follows the data, but that should not be a restriction of the API.

d) can deal with AAD preceeding and following the ciphertext/data to be encrypted (future proofing)
Slide 11 indicates no support. This slide actually has an error of fact. McGrew has proposed an AEAD cipher based on CBC and HMAC and uses the following construct for the calculation of the MAC T = MAC(MAC_KEY, A || S || AL) - where A is the associated data and AL is the length of the associated data. For our purposes, the AL is actually unencrypted associated data which means that the associated data both precedes and follows the ciphertext. And yes, the mode could do this - but that's less general that permitting prefix and suffix AAD.

e) handles message based encryption as a separate and backwards compatible item from AAD and IV generation. (e.g. can actually do per-message CBC stuff within an association using new calls).

I can't find anything equivalent in Wan Teh's proposal.

f) divorces IV generation specification from mechanism specification - same mechanism can use multiple IV generation mechanisms (future proofing).

Slide 14 indicates this isn't supported.

g) mirrors, extends or combines existing functions so easy transitions for future programming.
There's some of this.

h) possible to use IV generator for decrypt, but not required.
Maybe possible - slide 10 seems to tie this to AEAD vs non AEAD rather than mechanism specific.

i) includes functions to do message verification and signature

Not supported by Wan Teh's proposal. This is at least as important as the encrypt message stuff.

One final thing - Wan Teh's message based encryption/decryption/sign/verify seems to be tied specifically to AEAD modes - that misses the point that the need for message processing is a distinct and separate requirement from supporting AEAD constructs and misses the need for message processing for just signature/verify constructs.

I appreciate the desire to solve this specifically for TLS, but I believe that approach is short sighted. The API should be as general as possible, and should not have constraints based on current usages.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]