DRBG interfaces #107

New issue

Open

opened 2024-06-26 07:48:15 -05:00 by gilles-peskine-arm · 3 comments

gilles-peskine-arm commented

2024-06-26 07:48:15 -05:00

(Migrated from github.com)

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/mbed-tls@lists.trustedfirmware.org/thread/WM3USJYYYIWPUIVTEMIAX7YLGRLJ4TYA/

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/mbed-tls@lists.trustedfirmware.org/thread/WM3USJYYYIWPUIVTEMIAX7YLGRLJ4TYA/

mschulz-at-hilscher commented

2024-07-24 10:13:05 -05:00

(Migrated from github.com)

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

gilles-peskine-arm commented

2024-07-24 11:10:06 -05:00

(Migrated from github.com)

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.)

The PSA DRBG will be seeded from entropy collected from [entropy collection entry points](https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-3.6.0/docs/proposed/psa-driver-interface.md#entropy-collection-entry-point) provided by drivers. (Today we're using the `entropy.c` module; entropy drivers are a completer redesign of that module.)

gilles-peskine-arm commented

2024-08-07 10:19:51 -05:00

(Migrated from github.com)

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.

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.

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-Mbed-TLS/TF-PSA-Crypto#107

No description provided.

Rows
Columns