Is HMAC-DRBG or Hash-DRBG stronger? Out of the two deterministic random bit generators defined in section 10.1 of NIST SP 800-90A (i.e. based on hash functions), which one is cryptographically stronger?


Hash-DRBG (Section 10.1.1)
HMAC-DRBG (Section 10.1.2)


Is there any other criteria to select between these two?
To complement fgrieu's short answer, here is an overview of the two RNG algorithm sets.

Hash-DRBG

The state of Hash-DRBG is composed of a value $V$ (which is updated with each request of new bits), and a same-size constant $C$ (which is only updated on reseeding the generator), and a counter $c$ to track when the next reseeding is needed.

Only $V$ is directly used to generate new bits, by concatenating $H(V), H(V+1), H(V+2), \dots$ until enough bits are generated.

After each generation of new bits, both the constant, the counter and a hashed version of the value are added to the value to generate the new value:

$$V_{\text{new}} = V + H(\text{0x03}||V) + C + c $$

Then $c$ is increased by one.

You can also provide additional input to the generator, in which case another hash call with $V_{\text{new}} = H(\text{0x02}||V||A)$ is done before generating the output.

For initial seeding and reseeding, an adaptable-output-size version $\tilde H$ of $H$ is used (as defined in Section 10.4.1), to generate enough bits for $V$ and $C$.

Hash-DRBG relies on $V$ and $C$ staying secret. For $V$, this is the preimage-resistance of the hash function (as $V$ is hashed to generate the output), while $C$ can be easily derived from two (or three, if the counter value is not known) consecutive values of $V$ (as it is simply added).

From this, the following output can be predicted, until the application adds non-predictable additional data or the state is reseeded.

(Of course, we also need that the output of $H$ is pseudo-random, i.e. has no detectable patterns.)

Initialization: The value $V$ is created by hashing the "seed material", and the constant $C$ then by hashing $V$ (with a prefix byte of $0$) (both producing 440 bits).

HMAC-DRBG

In HMAC-DRBG, the state is composed of a key $K$, a value $V$ and a counter c (to keep track of when a reseed is needed - it is not used for generation itself).

The actual generation of random bits uses

$$ V := HMAC(K, V)$$

in a loop and concatenates these new values of $V$ until enough output is generated.

After this, an update function is called, which changes both key and value by two HMAC calculations:

$$\begin{align*}
   K_{\text{new}} &amp;= HMAC(K_{\text{old}}, V_{\text{old}} || \text{0x00}) \\
   V_{\text{new}} &amp;= HMAC(K_{\text{new}}, V_{\text{old}})
 \end{align*} $$

Update can alternatively also incorporate additional data $A$ provided by the application, using four such calls in total:

$$ \begin{align*}
  K_{\text{tmp}} &amp;= HMAC(K_{\text{old}}, V_{\text{old}} || \text{0x00} || A) \\
  V_{\text{tmp}} &amp;= HMAC(K_{\text{tmp}}, V_{\text{old}}) \\
  K_{\text{new}} &amp;= HMAC(K_{\text{tmp}}, V_{\text{tmp}} || \text{0x01} || A) \\
  V_{\text{new}} &amp;= HMAC(K_{\text{new}}, V_{\text{tmp}}) \end{align*} $$

(If additional input is given to the generate-function, update will be called before and after generating more output.) This will also be used for seeding and reseeding, where the additional data contains entropy input (and maybe any application-specific stuff).

HMAC-DRBG's security depends on the key $K$ staying secret (intermediate values of $V$ are output directly as pseudorandom bits), i.e. on the key-retrieval-resistance of the HMAC.

If value of $K$ is known, all the following ones can be derived, until the application adds non-predictable additional data or a reseeding occurs.

But other than this worst-case break, there might be other weaknesses in the hash function's output which make HMAC's output be non-random (i.e. show patterns). Optimally, we want the HMAC output be a pseudorandom function of the input.

Initialization: The HMAC_DRBG_Instantiate_algorithm function sets $K$ to 0 and $V$ to $0x01010101\dots01$, before calling first the Update function with the seed material as "additional data".

Summary

One can see that HMAC-DRBG shuffles stuff around a bit more than Hash-DRBG ... and HMAC itself even contains two hash invocations.  Thus HMAC-DRBG is certainly slower.

But as any possible weaknesses of HMAC will come from weaknesses of the underlying hash function, HMAC can't be 
weaker than the hash ... but it could be stronger (i.e. some weaknesses of a hash function will not transfer to the corresponding HMAC). For now, there is no weakness known in either of both constructions, though.