2

In RFC6979, on page 14, Section 3.6 "Variants":

o. Additional data may be added to the input of HMAC, concatenated after bits2octets(H(m)):

    K = HMAC_K(V || 0x00 || int2octets(x) || bits2octets(h1) || k')

However, in the terminology of SP800-90Ar1, k' is the "additional input" that can be set as a parameter when generating pseudorandom bits.

The line

K = HMAC_K(V || 0x00 || int2octets(x) || bits2octets(h1) || k')

appears to be from step d in section 3.2 "Generation of k".

Q1: Additional data k' is concatenated after bits2octets(H(m)) in HMAC input in step d. May we also need to concatenate k' after bits2octets(H(m)) in HMAC input in step f?

I.e., step f becomes

K = HMAC_K(V || 0x01 || int2octets(x) || bits2octets(h1) || k')

Q2: As said

In SP800-90Ar1 terminology, k' is the "additional input"

In SP800-90A, Section 10.1.2.3, pages 46 and 57, "Instantiation of HMAC_DRBG",there is no "additional input" in "HMAC_DRBG Instantiate Process" but k' appears to be passed as "personalization_string" as in SP800-90Ar1 section 10.1.2.3. If k' is used as "personalization_string", then in Q1, we may also concatenate k' after bits2octets(H(m)) in HMAC input in step f, no?

Q3:

In SP800-90A terminology, k' is the "additional input"

In SP800-90Ar1 document section 10.1.2.5 "Generating Pseudorandom Bits Using HMAC_DRBG", there is an "additional_input" argument. Does the "additional input" in RFC6979, Section 3.6, refer to the "additional_input" in SP800-90Ar1 document section 10.1.2.5?

If so, may we need to pass additional data k' as "additional_input" also to "HMAC_DRBG_Generate Process", i.e., in RFC6979 section 3.2. step h.1~h.3?

Presumably as a result, RFC6979 Section 3.2. step h may become:

Inserting a new step before step h.1:

(K, V) = HMAC_DRBG_Update(k', K, V);  //step 2 of "HMAC_DRBG_Generate Process"

and the later half of step h.3 may be modified, if k is rejected and generating a new k is needed, the original process appears to be step 6 of "HMAC_DRBG_Generate Process":

(K, V) = HMAC_DRBG_Update(null, K, V)

ie

    K = HMAC_K(V || 0x00)
    V = HMAC_K(V)

may become

(K, V) = HMAC_DRBG_Update(k', K, V)

ie

K = HMAC_K(V || 0x00 || k')
V = HMAC_K(V)
K = HMAC_K(V || 0x01 || k')
V = HMAC_K(V)

as later half of step h.3.

May such modifications be needed?

Community
  • 1
anmin
  • 41
  • 3

1 Answers1

2

I had emailed Dr Thomas Pornin the very same question and received his reply. With his permission I cross post his answer as followed

From: "Thomas Pornin" ... Date: 2021/04/22 11:38

Q1: Additional data k' is concatenated after bits2octets(H(m)) in HMAC input in step d. May we also need to concatenate k' after bits2octets(H(m)) in HMAC input in step f?

There is no real "need" here. Section 3.6 lists (but does not formally specify) possible variants of the mechanism described in RFC 6979; these variants are, emphatically, NOT the "true" RFC 6979 mechanism (section 3.6 says as much) and, in particular, do not match the test vectors contained in the RFC. However, they all make sense, cryptographically speaking, and thus can be considered in some specific contexts.

The process described in RFC 6979 has been designed to reuse as most as possible the definition of HMAC_DRBG from NIST SP800-90A, with the avowed goal of being able to rely on existing security analysis of that specific construction. Note that HMAC_DRBG is still, as defined by NIST, a random generator that expects to work along with a seed generator. The context of RFC 6979 is outside of the scope of HMAC_DRBG; thus, whatever we do, we cannot really claim to be using HMAC_DRBG in a formal sense; we can only claim that we use a construction for which existing cryptographic analysis also applies to the case of deterministic DSA and ECDSA signatures (see references from section 4).

Thus, in that context, there is no real notion of "correct" or "incorrect" variant. If injecting some additional input (k') into the first HMAC call (step 3.2.d), you may or may not also inject the same additional input into the third HMAC call (step 3.2.f). Both variants work and "make sense" (neither seems more secure or less secure than the other). Neither variant matches the RFC 6979 test vectors; this does not compromise interoperability (in all of this, interoperability is about generating signatures that are acceptable to unaware verifiers), but it is out of the scope of RFC 6979. It is a case of "yeah, sure, you can". Section 3.6 merely points out that having additional input (k') injected into HMAC_DRBG maps to construction elements in NIST SP800-90A which are designated as "additional_input" in the process on page 48 of that document (page 47 in the 2015 revision of SP800-90A, but RFC 6979 dates from before 2015), so that variant is not something absurd or unheard of.

--Thomas Pornin

So I'd guessed that the term "additional input" in RFC6979 doc 3.6 (page 14 the last line ~ page 15 the first line) is not the term "additional_input" (used in generating and reseeding) in NIST.SP.800-90Ar1 doc 10.1.2.5 (page 47) in exact sense. Nor is it the term "additional entropy" (used in instantiation) in NIST.SP.800-90Ar1 doc. It just means "additional" (extra, more) data. We may or may not use k' as "additional entropy" or "additional input" in HMAC_DRBG instantiation or generating.

anmin
  • 41
  • 3