Support hmac_drbg in PSA crypto

[gilles-peskine-arm]

The PSA crypto code relies on CTR_DRBG. By design, you can't use PSA crypto without an RNG. But the RNG doesn't have to be built on CTR_DRBG: any DRBG will do. Since the library also has HMAC_DRBG, the PSA crypto code should also support it. The only reason why psa_crypto currently requires CTR_DRBG is that it was easier to write it like this initially.

To avoid increasing the code complexity and the code size, the choice of DRBG should be done at compile time. Ideally there should be a compile-time choice of which DRBG to use (CTR_DRBG is a little faster than HMAC_DRBG, but less resistant against side channel attacks).

[frkv]

I see the convenience of having one single API for generating random data, but I wonder if this may break protocol requirements if there are competing uses of CTR_DRBG, HMAC_DRBG, etc. in a design. I don't see that "choose one" will always be acceptable.

This leads to the following questions:

• Will there be an option in the future to access specific DRBGs through PSA APIs?
• Are there any plans to expose DRBG-specific operations according to their specs (active reseeding, personalization, init and/or reset)?

And one additional question for my curiosity:

• Will the APIs facilitate ways to verify the DRBG(s) through PSA APIs?
  -E.g. using NIST CAVP - random number generators

Note that I have no issues with psa_generate_random as-is today. It is very convenient for the end-user to not have to worry about configuration if the only thing they want is "some random data".

[gilles-peskine-arm]

Will there be an option in the future to access specific DRBGs through PSA APIs?

Probably through the key derivation interface. That interface was even called “generator” in the past. It's a reasonable match for a DRBG interface, with the notable difference that a DRBG's output depends on the size of successive reads, whereas a KDF output doesn't.

Are there any plans to expose DRBG-specific operations according to their specs (active reseeding, personalization, init and/or reset)?

Personalization: yes, through an input step. Active reseeding: maybe by allowing inputs after retrieving output, but this is a bit of a bigger deviation from the nominal KDF interface. Passive reseeding: probably not: that would be an RNG interface, not a DRBG interface.

Will the APIs facilitate ways to verify the DRBG(s) through PSA APIs?

That was not in the plans as a standardized PSA interface, no. I think that if you're doing compliance testing, you're tied to a specific implementation.

In Mbed TLS, we don't have clear plans there. We want to reduce the amount of stable interface, in order to allow the internal design of the library to change. However, there'll still be an interface that allows you to validate the RNG — but after Mbed TLS 3.0, it probably won't be a stable interface (so it might e.g. change without prior notice between 3.4 and 3.5).