Yes, we should remove it. Unlike other features, I think we should remove HAVEGE _especially_ if someone is using it, because unlike the rest of the library, I cannot vouch for its security. I don't even know if our havege.c is implementing the HAVEGE specification correctly. And I cannot think of a platform where HAVEGE would give a useful amount of entropy, and where there isn't already a proper hardware RNG or an OS kernel with its own entropy gathering built with knowledge of the actual platform.

(Also noted on https://github.com/ARMmbed/mbedtls/issues/2599 .)

-- Gilles Peskine Mbed TLS developer

On 08/04/2020 12:41, Manuel Pegourie-Gonnard via mbed-tls wrote:

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?

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.

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.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.