Hi all,

In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: should we remove havege.c from the code base?

[1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/

The crypto library currently includes an implementation of the HAVEGE entropy gatherer [2], which is disabled in the default build (MBEDTLS_HAVEGE_C in config.h), but used as a source by our entropy module if enabled.

[2]: https://www.irisa.fr/caps/projects/hipsor/

We'd like to drop this module and remove it from the code base entirely for the following reasons:

- HAVEGE was designed for superscalar processors with high microarchitectural complexity, and is unsuitable for microcontrollers (or virtualized environments). We feel like when a complex enough CPU is used for HAVEGE to stand a chance of being secure, it's very likely that an operating system is also available, which probably already manages a random generator better that what we can do in user space.

- On a more practical note, our implementation relies on `timing_hardclock()` provided by timing.c only for a limited number of architectures and environments (funnily enough, not including any Arm architecture), with a silent fallback to a definition relying on `gettimeofday()` which is clearly not high-resolution enough to make HAVEGE secure.

- As with any random source, it is very difficult to assess whether HAVEGE is actually secure on any given platform. Further, the maintenance team doesn't have any specific knowledge of HAVEGE and there hasn't been any independent evaluation of our implementation of it.

- As a result of the above points, we're afraid people using our HAVEGE implementation on the wrong platforms, might be getting a false sense of security, which might prevent them from using more secure options, such as the OS RNG (when using an OS) or a hardware RNG (on microcontrollers).

If you're using MBEDTLS_HAVEGE_C or know someone who does, or if for any other reason you think we shouldn't drop it in Mbed TLS 3.0, please speak up now!

Regards, Manuel.