hashDRBG output length should be 1..hash_digest_size

[smuellerDD]

environment
Demo

testSessionId
75723

vsId

Algorithm registration
162340, 162341

Expected behavior
Test vector to be generated

Additional context

[ {
  "acvVersion" : "1.0"
}, {
  "vsId" : 162341,
  "status" : "error during vector generation",
  "message" : "failed to generate tests for: 162341"
} ]

[celic]

The error we see is

"AdditionalInformation": "Invalid Returned Bits Modulus supplied: 2048.  Values were not a multiple of 384"

The server requires that for HashDRBG, the output is in whole segments of digests. So the output of a HashDRBG with SHA2-384 must be a multiple of 384 bits.

[smuellerDD]

Am Mittwoch, 11. März 2020, 21:34:20 CET schrieb Chris Celi: Hi Chris,

The error we see is ``` "AdditionalInformation": "Invalid Returned Bits Modulus supplied: 2048. Values were not a multiple of 384" ```

Which specification requires that the additional info length must be a multiple of 384 bits? 90A says that for CTR DRBG without DF, the max is seedlen bits. For all others, its length is not restricted. If you look into 10.2.1.4.1 step 2, the addtl info is padded with zeros if it is too short. Or is the error note about the returned bits length? If so, the DRBG should return an arbitrary amount of bits and not just a block length. Ciao Stephan

[celic]

The "additional information" tag is misleading. It's providing information about the error unrelated from the property. I'll look into whether or not a drbg output can be truncated for hashDRBG.

…

On Wed, Mar 11, 2020, 6:06 PM smuellerDD ***@***.***> wrote: Am Mittwoch, 11. März 2020, 21:34:20 CET schrieb Chris Celi: Hi Chris, > The error we see is > ``` > "AdditionalInformation": "Invalid Returned Bits Modulus supplied: 2048. > Values were not a multiple of 384" ``` Which specification requires that the additional info length must be a multiple of 384 bits? 90A says that for CTR DRBG without DF, the max is seedlen bits. For all others, its length is not restricted. If you look into 10.2.1.4.1 step 2, the addtl info is padded with zeros if it is too short. Or is the error note about the returned bits length? If so, the DRBG should return an arbitrary amount of bits and not just a block length. Ciao Stephan — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#808 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATQXEK4LSFRAYVB63R6Q6DRHADOTANCNFSM4LF5IUWQ> .

[smuellerDD]

Am Mittwoch, 11. März 2020, 23:10:29 CET schrieb Chris Celi: Hi Chris,

The "additional information" tag is misleading. It's providing information about the error unrelated from the property. I'll look into whether or not a drbg output can be truncated for hashDRBG.

SP800-90A says for all DRBGs about the following: 1. requested_no_of_bits: The number of bits to be returned. ... 1. m = requested _ no _ of _ bits / outlen ... 5. returned_bits = leftmost (W, requested_no_of_bits). ... When I implemented the DRBG, it allowed any arbitrary amount of data to be requested (up to the maximum for one request).

On Wed, Mar 11, 2020, 6:06 PM smuellerDD ***@***.***> wrote: > Am Mittwoch, 11. März 2020, 21:34:20 CET schrieb Chris Celi: > > > > Hi Chris, > > > > > The error we see is > > ``` > > "AdditionalInformation": "Invalid Returned Bits Modulus supplied: 2048. > > Values were not a multiple of 384" ``` > > > > Which specification requires that the additional info length must be a > multiple of 384 bits? > > > > 90A says that for CTR DRBG without DF, the max is seedlen bits. For all > others, its length is not restricted. If you look into 10.2.1.4.1 step 2, > the > addtl info is padded with zeros if it is too short. > > > > Or is the error note about the returned bits length? If so, the DRBG > should > return an arbitrary amount of bits and not just a block length. > > > > Ciao > Stephan > > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#808 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AATQXEK4LSFRAYVB63R6Q6D > RHADOTANCNFSM4LF5IUWQ>

.

> > -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #808 (comment)

Ciao Stephan

[celic]

You are correct. While the output length is specified in SP800-90A as the output length of the underlying hash function, the output can be truncated to a specific amount of bits. The other portion of the DRBG output is just dropped, NOT used for a future value. Was this needed for an implementation currently going through validation?

[smuellerDD]

Am Donnerstag, 12. März 2020, 16:43:00 CET schrieb Chris Celi: Hi Chris,

You are correct. While the output length is specified in SP800-90A as the output length of the underlying hash function, the output can be truncated to a specific amount of bits. The other portion of the DRBG output is just dropped, NOT used for a future value. Was this needed for an implementation currently going through validation?

I can easily change the output lengths for testing. So, there is no urgency in having that fixed. But I recommend to fix it because I know of DRBGs that only provides a fixed, say, 256 bits which is not equal to the output size. Ciao Stephan

[celic]

OK. This might not be an immediate fix for us but will be on our radar. Thanks for the information.

[smuellerDD]

I am not sure the new heading is correct - the DRBG spec defines the capability of generating 1 ... 2^19 bits in one generate function.

[Kritner]

this change is now on production https://github.com/usnistgov/ACVP-Server/releases/tag/v1.1.0.12