2
$\begingroup$

As I'm going through NIST-SP-800-90Ar1 spec for DRBG, I found the mention of security_strength in all of the 3 specified construct in the document: Hash_DRBG, HMAC_DRBG, CTR_DRBG. However, they're all noted as optional:

  1. security_strength: The security strength for the instantiation. This parameter is optional for Hash_DRBG, since it is not used.

and

  1. security_strength: The security strength for the instantiation. This parameter is optional for HMAC_DRBG, since it is not used.

and

{3 no df, 4 with df}. security_strength: The security strength for the instantiation. This parameter is optional for CTR_DRBG.

And in the disgraced previous version, there wasn't even mention of this parameter.

What is, or what can we infer as, the rationale for its inclusion?

$\endgroup$
1
  • $\begingroup$ Maybe to generalize the DRBG interface in case some other non-NIST implementations decide to behave differently on different security strength inputs, e.g. switching between AES-128 and AES-256? $\endgroup$
    – SEJPM
    Oct 15, 2019 at 8:00

1 Answer 1

2
$\begingroup$

A partial answer is that the 2012 version of SP 800-90A included a fourth DRBG construction, Dual_EC_DRBG (§10.3.1.2), for which the security_strength parameter was required. Since one DRBG flavor required this parameter, to have a common interface, all DRBG flavors had to take this parameter. In Dual_EC_DRBG, security_strength is used only for one thing: to select the curve.

Using the security_strength and Table 4 in Section 10.3.1, select the smallest available curve that has a security strength security_strength. The values for seedlen, p, a, b, n, P, Q are determined by the curve.

Dual_EC_DRBG was retired after it became public that is was probably backdoored by NSA, but its legacy survives in this minor way.

What escapes me is why Dual_EC_DRBG chooses the curve based on the security strength, whereas Hash_DRBG and HMAC_DRBG are parametrized by a choice of hash algorithm and CTR_DRBG is parametrized by a choice of block cipher.

$\endgroup$
1
  • 2
    $\begingroup$ It's almost as though the Dual_EC_DRBG parts of the standard were designed by another party who imposed their own conventions on NIST, leaving NIST to figure out how to make it fit into the standard… $\endgroup$ Oct 15, 2019 at 21:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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