Laser on Nostr: "The built-in hardware cryptographic random number generator (CRNG) derives entropy ...

"The built-in hardware cryptographic random number generator (CRNG) derives entropy from various sources, one of which is the included radio (used for Bluetooth). When the radio is disabled with the optional “noradio” firmware (selectable in the Green companion app), the CRNG loses that source and, therefore, has reduced entropy. To mitigate this, we use an ESP32 API call named “bootloader_random_enable()” to sample raw radio noise only during boot, which is then added to the entropy pool along with the sources mentioned above."

- Blockstream (nprofile…6av2)

https://blog.blockstream.com/blockstream-jade-tech-overview-part-1/

quoting
nevent1q…8lgj

Blockstream (npub1jg5…6n8n)

Technical question for the Blockstream/Jade team regarding Jade Classic (original ESP32) + No-Radio firmware, especially around v1.0.40.

In v1.0.40, Jade initialized its 256-bit entropy state with:

bootloader_random_enable();
esp_fill_random(entropy_state, 32);
bootloader_random_disable();

On the original ESP32, bootloader_random_enable() enables the SAR ADC entropy source when RF/Wi-Fi/Bluetooth are disabled.

The point I am trying to understand is the entropy extraction rate.

For ESP32 Classic, esp_random() uses:

APB_CYCLE_WAIT_NUM = 16

With an 80 MHz APB clock, this corresponds to a minimum enforced interval of ~0.2 us between RNG reads (~5 MHz theoretical maximum, excluding execution overhead).

However, the ESP32 Technical Reference Manual recommends reading RNG_DATA_REG at no more than ~500 kHz when using the SAR ADC in order to obtain maximum entropy, which corresponds to ~2 us per 32-bit read.

So there appears to be a difference between:

SAR ADC recommendation:
<= 500 kHz

> = ~2 us/read

esp_random() on ESP32 Classic:

> = ~0.2 us/read minimum enforced delay
> ~5 MHz theoretical maximum

Espressif also uses a much more conservative extraction rate in its bootloader RNG code when the SAR ADC is the entropy source.

At the same time, Espressif explicitly documents bootloader_random_enable() + esp_random()/esp_fill_random() as a valid way of obtaining true random numbers when RF is disabled.

Jade later changed this logic and now performs individual esp_random() calls separated by ~1 ms, explicitly mentioning additional time for HWRNG entropy refeeding and scheduler jitter.

My questions are:

1. Did Blockstream measure or estimate the min-entropy of esp_fill_random(32) on ESP32 Classic with bootloader_random_enable() active and RF disabled?

2. Was the ESP32 TRM recommendation of <=500 kHz for maximum SAR entropy considered?

3. Is there a known lower bound for the min-entropy of the 256-bit entropy_state generated by Jade v1.0.40 in this configuration?

4. Was the later 1 ms delay purely defense-in-depth, or was it also intended to remove uncertainty about the SAR entropy refresh rate on the original ESP32?

5. Does Blockstream consider a 12-word BIP39 mnemonic generated on Jade Classic + No-Radio + v1.0.40 to retain the full expected 128 bits of entropy?

I am not claiming a demonstrated vulnerability. I am trying to understand how the entropy guarantees of Espressif's SAR ADC/HWRNG path were evaluated in Jade.