Skip to content

Conversation

@gilles-peskine-arm
Copy link
Contributor

@gilles-peskine-arm gilles-peskine-arm commented Oct 18, 2019

The functions mbedtls_ctr_drbg_set_entropy_len() and mbedtls_hmac_drbg_set_entropy_len() were only supported after the call to mbedtls_ctr_drbg_seed() and mbedtls_hmac_drbg_seed(), so the initial seeding always grabbed the amount of entropy defined at compile time (MBEDTLS_CTR_DRBG_ENTROPY_LEN for CTR_DRBG, calculated from the hash algorithm for HMAC_DRBG). There was no good reason for that and the documentation was not clear prior to ARMmbed/mbed-crypto#287. Change the API to be intuitive: you can call set_entropy_len() after init(), and it will influence both the initial seeding (if you call it before seed()) and subsequent reseeds.

Keep the test-only function mbedtls_ctr_drbg_seed_entropy_len for strict ABI compatibility.

Backport of ARMmbed/mbed-crypto#299, plus some follow-up fixes from ARMmbed/mbed-crypto#305.

@gilles-peskine-arm gilles-peskine-arm added bug needs-review Every commit must be reviewed by at least two team members, component-crypto Crypto primitives and low-level interfaces mbed TLS team labels Oct 18, 2019
@gilles-peskine-arm
Copy link
Contributor Author

While making ARMmbed/mbed-crypto#305, I discovered some documentation that I'd failed to update. https://github.com/gilles-peskine-arm/mbedtls/tree/drbg-set_entropy_len-doc_cleanup-2.7 contains fixup commits for these missing updates, and I rewrote the history of this branch to squash the fixups.

mbedtls_hmac_drbg_seed() always set the entropy length to the default,
so a call to mbedtls_hmac_drbg_set_entropy_len() before seed() had no
effect. Change this to the more intuitive behavior that
set_entropy_len() sets the entropy length and seed() respects that and
only uses the default entropy length if there was no call to
set_entropy_len().
Move the definitions of mbedtls_ctr_drbg_seed_entropy_len() and
mbedtls_ctr_drbg_seed() to after they are used. This makes the code
easier to read and to maintain.
mbedtls_ctr_drbg_seed() always set the entropy length to the default,
so a call to mbedtls_ctr_drbg_set_entropy_len() before seed() had no
effect. Change this to the more intuitive behavior that
set_entropy_len() sets the entropy length and seed() respects that and
only uses the default entropy length if there was no call to
set_entropy_len().

The former test-only function mbedtls_ctr_drbg_seed_entropy_len() is
no longer used, but keep it for strict ABI compatibility.
return( ret );
}

int mbedtls_ctr_drbg_seed( mbedtls_ctr_drbg_context *ctx,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function lacks the needed documentation now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What documentation? If you mean the comments relating the implementation to the NIST standard that are present in the mbed-crypto and 2.16 PRs, they were added after 2.7 and never backported, and backporting them would be out of scope here.

Copy link
Contributor

@AndrzejKurek AndrzejKurek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please update the documentation.

AndrzejKurek
AndrzejKurek previously approved these changes Oct 25, 2019
You can't reuse a CTR_DRBG context without free()ing it and
re-init()ing it. This generally happened to work, but was never
guaranteed. It could have failed with alternative implementations of
the AES module because mbedtls_ctr_drbg_seed() calls
mbedtls_aes_init() on a context which is already initialized if
mbedtls_ctr_drbg_seed() hasn't been called before, plausibly causing a
memory leak. Calling free() and seed() with no intervening init fails
when MBEDTLS_THREADING_C is enabled and all-bits-zero is not a valid
mutex representation. So add the missing free() and init().
You can't reuse a CTR_DRBG context without free()ing it and
re-init()ing it. This generally happened to work, but was never
guaranteed. It could have failed with alternative implementations of
the AES module because mbedtls_ctr_drbg_seed() calls
mbedtls_aes_init() on a context which is already initialized if
mbedtls_ctr_drbg_seed() hasn't been called before, plausibly causing a
memory leak.

Calling free() and seed() with no intervening init fails when
MBEDTLS_THREADING_C is enabled and all-bits-zero is not a valid mutex
representation.
@gilles-peskine-arm gilles-peskine-arm added approved Design and code approved - may be waiting for CI or backports and removed needs-review Every commit must be reviewed by at least two team members, labels Nov 4, 2019
@Patater Patater merged commit db64989 into Mbed-TLS:mbedtls-2.7 Nov 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Design and code approved - may be waiting for CI or backports bug component-crypto Crypto primitives and low-level interfaces

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants