ESV Client constrained inputs

[swkeypair]

In the ESV registration JSON, there are 2 values that seem to serve two (not necessarily equivalent) purposes:

• "bitsPerSample" which translates to "Sample Size" on the ESV certificate posting. Valid values are limited to integers from 1 to 8. If this is passed into the SP 800-90B assessment tool, then that would explain the current constraint, as the NIST SP 800-90B tool can't process data wider than 8 bits. The bitsPerSample value passed into the tool need not be the actual width of the raw sample; there are many cases where a full raw sample is >8 bits, at which point the samples must be mapped down prior to testing with the SP 800-90B tool. In this case, mapping the provided data sample doesn't change the width of the actual raw sample to 8 bits or less. "Sample width" (here called "sampleBitWidth") should be able to be independently specified, and there should be an added constraint sampleBitWidth >= bitsPerSample.
• "alphabetSize" which is not on the ESV certificate posting. Valid values are limited to integers from 2 to 256. The value "alphabetSize" should be freely settable, with the only constraint being alphabetSize <= 2^(sampleBitWidth).
• "hminEstimate" (which is presumably the SP 800-90B "H_submitter parameter) acts as a bound for the "Entropy Per Sample" on the ESV certificate posting. Valid values are limited to floats >0 up to "bitPerSample", but should be limited to floats up to "sampleBitWidth".

As an example, consider an implementation that natively outputs 16 bits per symbol ("bitsPerSample") where all documentation, data gathering, H_submitter values, and entropy source output to a DRBG revolve around this value. It seems unnecessary and misleading to report that value as 8 bits per symbol on the ESV certificate just because the 16-bit wide values had to be mapped down for statistical testing. Translating that value would also require the "alphabetSize" no longer match the actual implementation/documentation.

Please consider removing these constraints or increasing the allowed ranges.

[locksmithone]

May I add the minNin value (conditioning components), which is constrained to the range [1; 512]. I assume the constraint comes from the inability of the 90B tool from computing the conditioning component entropy equations for n_in > 512. However, this parameter does not directly match the n_in that is required for the EARs, and that can be practically of any value. I would perhaps suggest that the maximum constraint, if due to the equation computation, be considered internally, but we should be able to enter the value here that matches the actual n_in from the conditioning component.

[celic]

I tend to agree that these values should be flexible. We could limit them down when we actually run the testing, but expect the submitter to provide the true value.

I'm a bit unsure what a field would look like that can accept values up to 2^256. Some decision would need to be made restricting that to particular common values... 1-256, then 2^32, 2^64, 2^128, 2^256 for example.

I have this marked down for v1.3 (we are trying to release v1.2 over the next couple of weeks to Demo).

[joshuaehill]

@locksmithone The "new" (post-December 2021) ea_conditioning should be able to deal with any practical setting for n_in. the main limitation is generally available memory, though I am aware of other arbitrary precision library limits.

[celic]

This will be fixed on the next release.