Conversation
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 I think we should enable this backend by default. Given that ESP-IDF provides such bindings, it's clear they intend for cryptographic libraries (such as their fork of WolfSSL) to use them. Furthurmore, it seems like the only time the Hardware RNG wouldn't be seeded with 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 unconditonally 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 Signed-off-by: Joe Richey <joerichey@google.com>
|
@newpavlov the first version of this PR used the |
It's not so clear for me, considering the following remark:
In other words, without a proper hardware setup users can get potentially predictable entropy.
IIRC I would be fine to use 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 |
There was a problem hiding this comment.
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.
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.
After reviewing the updated ESP-IDF random documentation:
Given that ESP-IDF provides binding of
getrandom/getentropytoesp_fill_random, it's clear they intend forcryptographic 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.