[RFC 2/2] FIXME: initial implementation of GCM

[Stephan Mueller]

Am Montag, 5. August 2013, 20:05:31 schrieb Stephan Mueller:

Hi Stephan,

>Am Montag, 5. August 2013, 21:41:30 schrieb Dmitry Eremin-Solenikov:
>
>Hi Dmitry,
>
>>On Mon, Aug 5, 2013 at 9:12 PM, Stephan Mueller <smueller at chronox.de>
>
>wrote:
>>> Am Montag, 5. August 2013, 20:06:39 schrieb Dmitry Eremin-Solenikov:
>>>>On Mon, Aug 5, 2013 at 7:55 PM, Stephan Mueller
>>>><smueller at chronox.de>
>>>>
>>> wrote:
>>>>> Am Montag, 5. August 2013, 19:17:58 schrieb Dmitry Eremin-
>
>Solenikov:
>>>>Let me rephrase the issue in a little bit different way, so that you
>>>>see my point:
>>>>'GCM should not use the same IV for encryption more than once with a
>>>>given key'. 800-38D talks about calling 'authenticated encryption'
>>>>function with same IV. 800-38D does not have any requirements about
>>>>'authenticate decryption' function with respect to IV vectors.
>>>>
>>>>Thus we should not allow using 'bad' IV vectors for encryption only.
>>>>Adding a check
>>>>to gcm_encrypt() looks like a sufficient protection.
>>>>
>>> Of course, here I am with you. Covering the encrypt operation is
>>> sufficient.
>>> 
>>> Yet I fail to understand your proposal to handle 8.2.1 compliance.
>>> When you use clock_gettime, there is a chance greater than zero that
>>> you get two identical values. Note, CLOCK_REALTIME/CLOCK_MONOTONIC
>>> is affected by ntp drift and ntp updates, CLOCK_MONOTONIC_RAW may
>>> not be available on every system.
>>
>>I forgot about clock_monotonic being affected by ntp :(
>>In the end this can be as simple, as static counter, being incremented
>>on each call to generate_iv().
>>
>>Or (if that would still satisfy 800-38D) have that counter in cipher
>>context (oh, my, another one). Thus one can assume that if a key is
>>set on the cipher context,
>>all further generate_iv() invocations would increment that counter.
>
>That solution is explicitly allowed in 8.2.1.

There is one way that has been accepted that you may want to consider: 
have the setiv function that hardly can check anything wrt section 
8.2.1. Maybe it can check minimum lengths. For example, OpenSSL checks 
for a min length of 96 bits.

But in addition, have a geniv function where the implementation 
generates an iv. As a rule of thumb, the fixed field is a value that 
shall be under control of the caller. The invocation field shall be 
under control of the cipher. I.e. when generating an IV, allow the 
caller to provide the fixed field.

Another catch with the IV: SP800-38D requires that one key shall only be 
used with at most 2**32 different IVs. If you hit that threshold, you 
must not continue with the crypto operation, but inform the caller to 
set up a new key. Do you have such a check?
>
>"The invocation field typically is either 1) an integer counter or 2) a
>linear feedback shift register
>that is driven by a primitive polynomial to ensure a maximal cycle
>length. In either case, the
>invocation field increments upon each invocation of the authenticated
>encryption function."
>
>>> In general: how do you propose you want to construct or verify the
>>> "fixed field" and the "invocation field"?
>>
>>"fixed field" can be specified during generate_iv() invocation.
>>"invocation field" is a copy of a counter.
>
>Well, shouldn't there be a service offered to generate an iv that even
>generates the field if the caller has no clue (e.g. provides NULL for
>the fixed field)? I mean, how shall a caller come up with a unique
>fixed field value?
>
>>> The invocation field must be modified after each authentication.
>>> That
>>> modification must still ensure that the invocation field is unique.
>>> How shall that be done?
>>
>>Hmm. I would increment that during generation. You have to reset
>
>right, or use a shift register as specified in 8.2.1.
>
>>internal GCM counter to 0 values (so that your tag is correct).
>>Currently it is done either via setiv() (reset() will zero a marks.iv
>>flag, thus next encryption/decryption
>>operation will call gcm_setiv() internally).
>>
>>> Moreover, there is a specific length requirement for the IV.
>>
>>I think there are not. Spec says, that for |IV| < 96 bits, one must
>>use 8.2.1, for |IV| >= 96, it should use one of 8.2.1 or 8.2.2 (but
>>only one of them).
>
>Right, scratch my remark.
>
>
>[...]
>
>Ciao
>Stephan


Ciao
Stephan
-- 
| Cui bono? |