Question about IETF RFC6979 determinisitc (EC)DSA document section 3.6 additional data k' In RFC6979 document
https://tools.ietf.org/html/rfc6979
page 14~15, Section 3.6 &quot;Variants&quot;

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')

 ...  In [SP800-90A] terminology, k' is the &quot;additional
 input&quot; 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 &quot;Generation of k&quot;.
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?
ie step f becomes
K = HMAC_K(V || 0x01 || int2octets(x) || bits2octets(h1) || k')

Q2: As said

SP800-90A terminology, k' is the &quot;additional input&quot;

In SP800-90Ar1 document
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf
section 10.1.2.3 &quot;Instantiation of HMAC_DRBG&quot;,
there is no &quot;additional input&quot; in &quot;HMAC_DRBG Instantiate Process&quot; but
k' appears to be passed as &quot;personalization_string&quot; as in SP800-90Ar1 section 10.1.2.3.
If k' is used as &quot;personalization_string&quot;, then in Q1, we may also concatenate k' after bits2octets(H(m)) in HMAC input in step f, no?
Q3:

SP800-90A terminology, k' is the &quot;additional input&quot;

In SP800-90Ar1 document section 10.1.2.5 &quot;Generating Pseudorandom Bits Using HMAC_DRBG&quot;,
there is an &quot;additional_input&quot; argument.
Is the &quot;additional input&quot; in RFC6979 document section 3.6 referred to the &quot;additional_input&quot; in
SP800-90Ar1 document section 10.1.2.5?
If so, may we need to pass additional data k' as &quot;additional_input&quot; also to &quot;HMAC_DRBG_Generate Process&quot;,
ie 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 &quot;HMAC_DRBG_Generate Process&quot;

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 &quot;HMAC_DRBG_Generate Process&quot;:
(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?
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: &quot;Thomas Pornin&quot; ...
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 &quot;need&quot; 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 &quot;true&quot; 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 &quot;correct&quot; or
&quot;incorrect&quot; 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 &quot;make sense&quot; (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 &quot;yeah, sure, you can&quot;.
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 &quot;additional_input&quot; 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 &quot;additional input&quot; in RFC6979 doc 3.6 (page 14 the last line ~ page 15 the first line) is not the term &quot;additional_input&quot; (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 &quot;additional entropy&quot; (used in instantiation) in NIST.SP.800-90Ar1 doc. It just means &quot;additional&quot; (extra, more) data.  We may or may not use k' as &quot;additional entropy&quot; or &quot;additional input&quot; in HMAC_DRBG instantiation or generating.