2

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?

SEJPM
  • 46,697
  • 9
  • 103
  • 214
DannyNiu
  • 10,640
  • 2
  • 27
  • 64

1 Answers1

2

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.