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
  • 45,967
  • 7
  • 99
  • 205
DannyNiu
  • 9,207
  • 2
  • 24
  • 57
  • 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? – SEJPM Oct 15 '19 at 08:00

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.

Gilles 'SO- stop being evil'
  • 19,134
  • 4
  • 50
  • 92
  • 2
    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… – Squeamish Ossifrage Oct 15 '19 at 21:20