RFC6979: error in reference implementation?

Question

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?

score 20 · Accepted Answer · answered Mar 18 '20 at 15:09

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.

RFC6979: error in reference implementation?

1 Answers1