nostr:npub1jg552aulj07skd6e7y2hu0vl5g8nl5jvfw8jhn6jpjk0vjd0w...

Cyph3rp9nk

npub1lnms53w04qt742qnhxag5d6awy7nz6055flnmjkr6jg39hm86dlq7arrnt

hex

ae1656fbb4c341afc0eed1d6ac122b1aaa976457fa8da77f75f5df0f0e47172e

nevent

nevent1qqs2u9jklw6vxsd0crhdr44vzg43425hv3tl4rd80a6lthc0per3wtsprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgs0eac2gh86s9l24qfmnw52xawhz0f3d862yleaetpafygjmanaxlsn7jc5u

Kind-1 (TextNote)

2026-09-01T20:27:31Z

nostr:npub1jg552aulj07skd6e7y2hu0vl5g8nl5jvfw8jhn6jpjk0vjd0waksvl6n8n

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.

原始 JSON

{
  "kind": 1,
  "id": "ae1656fbb4c341afc0eed1d6ac122b1aaa976457fa8da77f75f5df0f0e47172e",
  "pubkey": "fcf70a45cfa817eaa813b9ba8a375d713d3169f4a27f3dcac3d49112df67d37e",
  "created_at": 1788294451,
  "tags": [
    [
      "p",
      "922945779f93fd0b3759f1157e3d9fa20f3fd24c4b8f2bcf520cacf649af776d"
    ]
  ],
  "content": "nostr:npub1jg552aulj07skd6e7y2hu0vl5g8nl5jvfw8jhn6jpjk0vjd0waksvl6n8n \n\nTechnical question for the Blockstream/Jade team regarding Jade Classic (original ESP32) + No-Radio firmware, especially around v1.0.40.\n\nIn v1.0.40, Jade initialized its 256-bit entropy state with:\n\nbootloader_random_enable();\nesp_fill_random(entropy_state, 32);\nbootloader_random_disable();\n\nOn the original ESP32, bootloader_random_enable() enables the SAR ADC entropy source when RF/Wi-Fi/Bluetooth are disabled.\n\nThe point I am trying to understand is the entropy extraction rate.\n\nFor ESP32 Classic, esp_random() uses:\n\nAPB_CYCLE_WAIT_NUM = 16\n\nWith 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).\n\nHowever, 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.\n\nSo there appears to be a difference between:\n\nSAR ADC recommendation:\n\u003c= 500 kHz\n\n\u003e = ~2 us/read\n\nesp_random() on ESP32 Classic:\n\n\u003e = ~0.2 us/read minimum enforced delay\n\u003e ~5 MHz theoretical maximum\n\nEspressif also uses a much more conservative extraction rate in its bootloader RNG code when the SAR ADC is the entropy source.\n\nAt 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.\n\nJade 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.\n\nMy questions are:\n\n1. Did Blockstream measure or estimate the min-entropy of esp_fill_random(32) on ESP32 Classic with bootloader_random_enable() active and RF disabled?\n\n2. Was the ESP32 TRM recommendation of \u003c=500 kHz for maximum SAR entropy considered?\n\n3. 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?\n\n4. 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?\n\n5. 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?\n\nI 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.\n",
  "sig": "e483edebec2d37621dba6b8c42a1c763fcaf2d71479cecd2579c0edc026bbd7aee5a630759b65841a0e775b653146f9b44474761256d63e17124ce58860b5294"
}