HI @athorath
I’ve replicated
mbedtls_test_entropy_func() fromctr_drbg_validate_internal().
What do you mean? Have you taken this to your code?
Could you confirm that test_offset_idx is increased every seed operation?
Does this mean that you are running an additional ressed if no prediction resistance?
Do you get error also when PredictionResistance is False?
Is MBEDTLS_CTR_DRBG_USE_128_BIT_KEY defined?
I am trying to understand your test case.
If prediction resistance is on, then every time you generate random, you reseed.
I can’t see anything suspicious in your code.
Have you checked rc of your calls to mbedtls_ctr_drbg_random_with_add()?
Why is test_max_idx set to 32 * 8? I believe it should be 32 * 3, however this shouldn’t be the cause for your failure.
Please note that the test suite for ctr_drbg is specifically use case in Mbed TLS tests, and should not be used in production.
You can implement your test however you wish, but you can look at the test suite for reference.
As for the test suite, you should always concatenate the entropy, according the test entropy function, to generate the expected entropy.
If yes, in what order?
The order they appear in the test. Every call for reseeding, should generate the expected entropy
I don’t see AES related stuff anywhere.
Correct. Mbed TLS ctr_drbg supports AES 256. MBEDTLS_CTR_DRBG_USE_128_BIT_KEY was added, in compile time, to add support for hardware accelarators that don’t have any AES other than 128 bit keys. Note that using AES 128 reduces the security strength of your random. You should only use AES 256 if possible!
Also, how can I update settings so that both 128 and 256 bits are handled.
As mentioned, only at build time. This is not dynamic.
Regards