If I correctly understand RFC 6979, there is an error in the ref implementation section 3.2.

In the step H2, RFC specification says

 2.  While tlen < qlen, do the following:
              V = HMAC_K(V)
              T = T || V

but in Java implementation in the RFC appendix, we found the comparison with rolen

That does not provide the same result.

For example if used with Stark curve with prime field equal to 0x0800000000000011000000000000000000000000000000000000000000000001, qlen is 252 and rolen is 256

As consequence the loop occurs twice with rolen, but only once with qlen. it doesn't change the first k value but the subsequent k change.

The RFC code has been used now from third software.

Any thought about that?

  • 1
    $\begingroup$ Did you check the errata $\endgroup$ – kelalaka Mar 18 '20 at 14:54
  • $\begingroup$ Yes I did, nothing related to that $\endgroup$ – cslashm Mar 18 '20 at 15:06

The RFC specifies things in terms of bits. Each call to HMAC outputs hlen bits. tlen is the count of bits obtained so far; when at least qlen bits have been obtained, this step is finished.

The sample code is written in Java in which the elementary unit of information is the octet ("byte" in usual terminology). The supported hash functions always output a given number of bytes, and there is no fractional byte. In other words, within that code, hlen is always a multiple of 8. This implies that tlen is also a multiple of 8.

The rolen value is the length of q in octets; that is, it is equal to qlen/8, rounded up. This is OK in the code, since hlen is a multiple of 8. For instance, with a curve such that qlen is 252, the generation needs 252 bits of output from HMAC; but since hlen is a multiple of 8, you cannot get 252 bits of output without getting at least 256 bits of output. Thus, the code can keep track of things counting octets (hence, rolen) instead of bits. With HMAC/SHA-256, you get 32 bytes of output per HMAC call; and rolen is 32. Thus, one call will be enough to get rolen bytes, and there won't be a second one.

  • 1
    $\begingroup$ hmm yes I miss reading some point of the spec and search a bug in the wrong direction. I finally found what's goes wrong in the code I debug. Thanks for pointing me the truth ;) $\endgroup$ – cslashm Mar 18 '20 at 16:53
  • 2
    $\begingroup$ @cslashm When this answer answered your question, please accept it by clicking the checkmark-icon next to it. $\endgroup$ – Philipp Mar 19 '20 at 10:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.