DRBG interfaces

[gilles-peskine-arm]

By default, pseudorandom generator interfaces (ctr_drbg.h and hmac_drbg.h) will become private in TF-PSA-Crypto 1.0 and Mbed TLS 4.0. They need to be public in Mbed TLS because the legacy crypto API requires application code to pass RNG instances around, but PSA code uses an internal RNG wherever needed. PSA does not currently have an API for pseudorandom generators. Thus, while the CTR_DRBG and HMAC_DRBG modules will continue to exist (to power the PSA RNG, and also to power deterministic ECDSA with HMAC_DRBG), there is no compelling reasons for them to be accessible from application code. Should we still have an interface for CTR_DRBG and HMAC_DRBG in TF-PSA-Crypto 1.0?

Note that this solely is about application code creating DRBG instances for their own purposes. The CTR_DRBG and HMAC_DRBG will continue to exist under the hood (until the hypothetical day when we decide to use a different DRBG).

Some possibilities:

• Do nothing other than move ctr_drbg.h and hmac_drbg.h out of the public include directory. Consequence: there is no API for CTR_DRBG and HMAC_DRBG. This is the default choice, easier for maintenance but losing functionality.
• Keep exposing CTR_DRBG and HMAC_DRBG. Downside for users: the APIs are not PSA APIs and thus a poor fit to an otherwise PSA world. Downside for maintainers: it means we have to freeze the API to whatever we release in 4.0, whereas we may well want to restructure our RNG code — in particular, in terms of who decides when to reseed and who calls the entropy source.
• Expose DRBG through a PSA API. This is something we want to do in the long term, but it might not be ready by the time we release TF-PSA-Crypto 1.0. There are still open questions in the design of that API, in particular with respect to how reseeding works. For example, if the DRBG has a policy that requires reseeding, would a psa_drbg_output_bytes() function call a reseeding callback, or would it return PSA_ERROR_INSUFFICIENT_ENTROPY or a new error code?

Mailing list discussion: https://lists.trustedfirmware.org/archives/list/[email protected]/thread/WM3USJYYYIWPUIVTEMIAX7YLGRLJ4TYA/

[mschulz-at-hilscher]

How will seeding of the DRBG be achieved? How is it to be connected to a hardware TRNG providing entropy?

[gilles-peskine-arm]

The PSA DRBG will be seeded from entropy collected from entropy collection entry points provided by drivers. (Today we're using the entropy.c module; entropy drivers are a completer redesign of that module.)

[gilles-peskine-arm]

Decision for 4.0: the DRBG modules are going to be private. It's likely that we'll add a PSA API for DRBG calls, but that probably won't be ready in time for 4.0, and it can be done any time in 4.x.

The DRBG modules are going to undergo changes due to the entropy overhaul.