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: Re: [pkcs11] Groups - Message Based processsing uploaded

On 5/5/2014 9:16 PM, Wan-Teh Chang wrote:
On Wed, Apr 16, 2014 at 1:29 PM, Michael StJohns <msj@nthpermutation.com> wrote:
Submitter's message
Got tired of trying to tweak what Wan Teh was doing so I wrote the the whole
thing from scratch. This benefits from a number of ideas I got from Wan
Teh's approach and from discussions during the calls. I believe its close to
95% - will need a review pass and a pass to complete discussion of error

This adds three API calls, and 4 IV generators and should cover the bulk of
AEAD and existing legacy uses.
Hi Mike,

I reviewed your proposal v1 dated 16 Apr 2014. I ordered my review
comments from high level to low level. Most people can skip the
editorial comments and typo fixes at the end.

Overall comments:

This is a well-thought-out proposal based on good research.

In this proposal the API evolved into a universal C_ProcessMessage
function that can perform any phase of any cryptographic operation.
Our two proposals made diametrically opposite design choices in this
aspect. I suspect the best way forward is for the technical committee
to select one proposal rather than trying to merge them.

API design comments:

1. In the description of C_ProcessMessage, we have:

     Note: while it is unlikely that an IV generator will be used on
the received side for to-be-defined mechanisms, the API does not
prohibit this.

We discussed this issue in email before but I forgot to follow up. I
think the decrypter doesn't need to use an IV generator. The scenario
you described in that email thread seems to be IV recovery rather than
IV generation.

I'm not sure I understand what you intend as the difference between the two.

It's possible that the IV generators for the sending and receiving are lock-step PRNGs. They both give the same values given the same original seed. Again, the API supports this, the mode, mechanism or token may not.

2. In the "Initialization Vector Generators" section, the paragraph
that begins with "Some IV generators MAY take an input value": it
seems that if an IV generator needs to take an input from outside the
crypto token, then that defeats the purpose of having the crypto token
generate the IVs because the IV generation process cannot be fully
validated by a FIPS testing lab. The IV generator will need to
validate the external inputs, for example, verifying that the sequence
numbers are monotonically increasing.

This is based on the possibility of something like a HASH or PRNG mixin transform of an input (e.g. sequence, nonce) value. The carried value in the message or generated externally is mixed in to a HASH or seeded PRNG to provide an "unpredictable" IV value. Given that "IV generation" seems to be a new hot topic in cryptography, I left the possibility that an IV generator could take an external value as an input. See the pseudorandom based IV generator sample. The idea is that the sender and receiver remain synchronized and use the PRNG to generate the same IVs. The mixin might be a public or secret (e.g. decrypted nonce from previous message value).

In any event, you're confusing policy (e.g. FIPS preventing X from being an input to Y) with API. The API supports this, the mode, mechanism or token may not.

3. The "CK_MECHANISM_TYPE randomMechanism" field of
unnecessary because the C_GenerateRandom function doesn't take a
mechanism input.

And that's a problem more with C_GenerateRandom than it is with this field. Editorially, I need to define placeholders which can be used to indicate the token default PRNG and the default TRNG.

For the pseudorandom generator - both sides need to have the same PRNG model and given the many many PRNGs (cf SP800-90A) I left the placeholder here. The difference between the random and pseudorandom generators is mainly in the ability to add mixins on a per message basis to the PRNG state.

Editorial comments:

1. In the description of C_ProcessMessage, we have:

     For output of signatures (i.e., when bReceiver is CK_FALSE), the
processing of pulIntegrityTagLen follows the conventions of section

We should also describe, for input of signatures (i.e., when bReceiver
is CK_TRUE), how pulIntegrityTagLen should be processed.
Fair.  I've got an example for this, but it can be added to the text.

2. In the CKM_IVGEN_CCM_COUNTER section: "Note that if pNonce is not
null, then the rightmost ulFixedFieldLength bytes are the initial
value of that counter": this sentence should ideally be combined with
"pNonce points to the location that contains the fixed part of the
nonce or is NULL_PTR", so that we say something like:

     pNonce points to the location that contains the fixed part of the
nonce and the initial value of the counter, or is NULL_PTR.

Yep. There are a few other places where some clarification will be needed. Deferred until there's a decision on how to proceed.

Typos and nits:

1. "That handle for that object": perhaps "The handle for that object"
or just "That handle"?
"The handle for that object" or even "The handle for the association object"

2. "the HSM MAY relax that restriction to permit one encrypt/decrypt
and one hash/sign/verify per association rather than per session": it
seems that "one encrypt/decrypt and one hash/sign/verify" should be
"one encrypt/decrypt or one hash/sign/verify" because the |pMechanism|
input of C_NewAssociation can only specify one encrypt/decrypt or one
hash/sign/verify, but not both.

This is slightly awkward wording because of the difference between message and legacy processing and because of the weirdness of AEAD. The "encrypt/decrypt" and "sign/verify/hash" refer to the underlying primitive operations, not to the mechanism. E.g. a signature mechanism is a "sign/verify/hash" context, something like AES-CBC is an "encrypt/decrypt" context while an AEAD AES-CCM mechanism could be considered both an "encrypt/decrypt" context AND a "sign/verify/hash" context (consider processing a message with no encrypted data and only AAD).

I'm looking at the possibility of an AEAD composite mode - e.g. AES-CBC-CMAC for example, which is logically two different operations (a sign and encrypt), but is specified as a single mechanism. This is already being discussed in TLS and I'm trying to get the language in this to the point where it won't be immediately obsolete.

3. CK_BOOLEAN => CK_BBOOL. CK_BBOOL is the boolean type in PKCS #11.

4. All occurrences of "CK_NULL" and "NULL_PTR" should be changed to

Unless we've changed things, the current mechanisms document has it as NULL_PTR *not* CK_NULL_PTR. I thought I'd caught all the CK_NULL's - I'll fix those.

5. In the function prototype of C_ProcessMessage, the use of "Len" and
"Length" in function parameter names is inconsistent. In the text,
"ulAssociatedDataLength" should be changed to "ulAssociatedDataLen" to
match the name used in the function prototype.

6. All occurrences of "uPhase" should be changed to "ulPhase".
K - actually this may change to phase and the type will be redefined to an enum like definition

6. "The API specified in the mechanism parameters of the cryptographic
mechanism is ignored": change "API" to "IV".
K - actually caught that on the current edit.

7. "every initial call to C_ProcessMessage (i.e. where uPhase is
either one of the PHASE_SINGLE values or is PHASE_INITIAL provides an
IV for that specific message": add a closing parenthesis ')' after

8. "I.e. if the length of the variable part is 4, then the value of
the variable part will be ...": "I.e." probably should be changed to

Wan-Teh Chang

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