ESP-IDF: Enable unconditionally

[josephlr]

After reviewing the updated ESP-IDF random documentation:

• https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/random.html
• https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf#rng

Given that ESP-IDF provides binding of getrandom/getentropy to esp_fill_random, it's clear they intend for
cryptographic libraries (such as their fork of WolfSSL) to use them. Furthermore, it seems like the only time the Hardware RNG would lack sufficient entropy is during early boot, so I added a section to our "Early boot" documentation noting this issue.

Also note that Rust's standard library unconditionally supports ESP-IDF for both hash seed generation and generating cryptographic random bytes, see https://github.com/rust-lang/rust/blob/62bf38fa600f4beb878d61c537837729d4ee689e/library/std/src/sys/random/espidf.rs#L7 I don't think there's a good reason to deviate from the standard library here.

[josephlr]

@newpavlov the first version of this PR used the getrandom bindings provided by ESP-IDF, but using those would require binding to ESP-IDF's errno, which seems unnecessarily complicated, so I just kept the implementation as-is.

[newpavlov]

it's clear they intend for cryptographic libraries (such as their fork of WolfSSL) to use them

It's not so clear for me, considering the following remark:

If none of the above conditions are true, the output of the RNG should be considered as pseudo-random only.

In other words, without a proper hardware setup users can get potentially predictable entropy.

Also note that Rust's standard library unconditionally supports ESP-IDF for both hash seed generation and generating cryptographic random bytes

IIRC std uses entropy sources only for seeding hash maps (well, technically it also uses it for things like thread ID generation on Windows, but it's not relevant), so it's less strict about entropy quality (e.g. it tries to use GRND_INSECURE on Linux). Meanwhile in our case we strive to always provide good quality entropy even during early boot.

I would be fine to use esp_fill_random for "insecure" functions (see #546), but I am hesitant to use them by default for "secure" functions without some kind of a check function, so to be conservative I think it makes sense to ask users to make a conscious decision.

See #397 for the earlier discussion. I also raised these concerns in espressif/esp-idf#8725, but, unfortunately, there are no updates on it.

cc @briansmith

[newpavlov]

On second thought, I guess we can simply say that it's a potential deficiency of the target and we did our best given the provided platform capabilities. In the issue they wrote the following:

Note that esp_random_fill() can be used to seed a software CSPRNG, which is done in mbedtls, as far as I know. I.e., esp_random_fill() is similar to the libc getentropy() function.

While I don't think that a getentropy()-like function should ever return potentially predictable entropy, it may be fine to defer to the intention of ESP IDF maintainers.