Re: [pkcs11] Groups - Message Based processsing uploaded

[Wan-Teh Chang <wtc@google.com>]

On Mon, May 5, 2014 at 7:33 PM, Michael StJohns <msj@nthpermutation.com> wrote:
> On 5/5/2014 9:16 PM, Wan-Teh Chang wrote:
>> 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.

By IV recovery, I mean a process where a decrypter recovers the IV
from the input, which is a scrambled combination of the logical IV and
logical ciphertext. In this case, the encrypter still sends the IV to
the decrypter. (I believe this is the example you gave in our prior
email discussion.)

> 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.

I see. The IVs are not sent in this case, so the decrypter needs to
reconstruct the IVs using the same generation algorithm and the shared
secret seed.

>> 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.

Understood. But the need for an internal IV generator comes from
policy. So the additional API complexity should actually meet policy
requirements.

>> 4. All occurrences of "CK_NULL" and "NULL_PTR" should be changed to
>> "CK_NULL_PTR".
>
> 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.

You're right. Sorry about the confusion. The right macro is NULL_PTR.
So only "CK_NULL" needs to be fixed.

(Yesterday I only checked the PKCS #11 headers in the NSS crypto
libraries. For some reason the NULL_PTR macro is renamed CK_NULL_PTR
in NSS.)

Wan-Teh Chang