Closed fservillat closed 7 months ago
Hello @fservillat,
Thank you for this report. We will get back to you as soon as we analyze it further. This may take some time. Thank you for your comprehension.
With regards,
Hello @fservillat,
First of all we would like to thank you again for your report. In order to allow a better understanding of the problem, could you please give us more details allowing our development teams to reproduce the problem? Did you detected it at runtime or is it just an observation ?
With regards,
Hello,
No I didn't try to run the code as is, I used it as a reference for my integration of the mbedtls library.
You won't detect any problem at runtime, but you will completely mess-up your entropy.
In fact, if you refer to the API of memset, you will see that it declare the second parameter value as an int, but cast it afterward as an unsigned char.
The value is passed as an int, but the function fills the block of memory using the unsigned char conversion of this value
Thus, you will be always using only the last byte of your random number, which means that you have a random with 256 different values.
That's clearly not what you want for your SSL encryption.
Hope this explanation is clear enough.
Best Regards,
ST Internal Reference: 157388
Hello @fservillat,
The issue you reported has been fixed in the frame of version v1.28.0 of the STM32CubeF4 published recently on GitHub. Thank you again for having reported.
With regards,
https://github.com/STMicroelectronics/STM32CubeF4/blob/964d63294cab82f77c5a568ab3b4a9ea6c6d5a2a/Projects/STM324x9I_EVAL/Applications/mbedTLS/SSL_Client/Src/hardware_rng.c#L40
I believe memcpy should have been used here instead of memset.