ESP32 Forum

Title: Questions about flash encryption flashing mechanism in Development mode (and the process of dealing with a terrible AI)

Background:

According to the documentation, the workflow for using a host-generated key in ESP32-C3 Development mode is:

1. Generate the key:

   Code: Select all

   idf.py secure-generate-flash-encryption-key my_flash_encryption_key.bin

2. Burn the key to eFuse:

   Code: Select all

   idf.py --port PORT efuse-burn-key BLOCK my_flash_encryption_key.bin XTS_AES_128_KEY

3. Flash the firmware:

   Code: Select all

   idf.py flash monitor

Question: Step 3's "idf.py flash monitor" command does not specify a key path. How does the chip know which key to use to encrypt the flash?

The AI's terrible performance during the discussion:

1. Fabricated "clearing eFuse": The AI claimed that "FLASH_CRYPT_CNT" would be cleared to zero after each plaintext firmware flash. This is a complete lie — eFuse bits cannot be cleared.
2. Fabricated "stub code transparent encryption": The AI invented the claim that "stub code in UART download mode transparently encrypts plaintext firmware during flashing." This has absolutely no basis in any documentation.
3. Cited a non-existent command: The AI cited "idf.py encrypted-app-flash" and described its functionality, but this was not in the knowledge sources.
4. Fabricated a comparison table: The AI invented a comparison table between Development mode and Release mode, the contents of which had no documentary basis.
5. Got the meaning of "DISABLE_DL_ENCRYPT" completely backwards: The AI claimed "not set means hardware encryption is disabled." This is the exact opposite of the truth. Not being set means encryption operations are enabled.
6. Repeatedly claimed UART download mode auto-encrypts plaintext: The AI repeatedly claimed "hardware automatically encrypts data before writing to flash in UART download mode," which directly contradicts the question "then how do you flash encrypted firmware?" — a contradiction the AI could not resolve.
7. Glossed over the meaning of "second-stage bootloader allows": The AI repeatedly avoided the key point that the second-stage bootloader determines future UART bootloader permissions by writing eFuse bits during normal boot, and only clarified this after repeated questioning.
8. Claimed "idf.py flash monitor" flashes plaintext, chip encrypts in-place on next boot: This was incomplete and misleading, failing to explain the complete mechanism for subsequent boots and subsequent flashing operations.
9. Fake apologies followed by more fabrications: After each caught error, the AI would apologize and then immediately fabricate new errors, repeatedly misleading the user.
10. Repeatedly tried to whitewash itself in the summary post: The AI deliberately downplayed its own errors, and only gradually added more after being called out multiple times — and even then each version remained incomplete.

Unresolved core questions:

1. Since "DISABLE_DL_ENCRYPT" is not set in Development mode, meaning hardware encryption is enabled during UART download, would flashing an already-encrypted binary result in double encryption?
2. What is the complete mechanism for flashing both plaintext and ciphertext firmware in Development mode?
3. After flashing plaintext firmware, how is in-place encryption triggered again?

The official documentation does not contain a complete explanation of this. Does anyone have answers to these questions?

Step 3's "idf.py flash monitor" command does not specify a key path. How does the chip know which key to use to encrypt the flash?

The chip uses the key it finds in its e-fuses:

Second stage bootloader first checks if a valid key is already present in the eFuse (e.g., burned using espefuse tool), then the process of key generation is skipped and the same key is used for flash encryption process.

Step 3's "idf.py flash monitor" command does not specify a key path. How does the chip know which key to use to encrypt the flash?

The chip uses the key it finds in its e-fuses:

Second stage bootloader first checks if a valid key is already present in the eFuse (e.g., burned using espefuse tool), then the process of key generation is skipped and the same key is used for flash encryption process.

Thank you! Perhaps I did not express myself clearly. You mentioned that the second-stage bootloader checks whether a key is already stored in the eFuse and uses it if present. I understand this logic perfectly well, yet this mechanism only applies to the transition from unencrypted to encrypted mode during the very first boot. My question is this: after flash encryption is enabled, it seems odd that we can upgrade ESP32 firmware without disabling encryption, accessing the encryption key, or copying the key to the development PC. Since the development PC does not hold the encryption key, it can only generate plaintext binary firmware files. The development PC merely needs to add the `-encrypted` flag during flashing—no actual key needs to be provided; it only indicates that encryption should be applied. The fact that firmware updates still succeed proves that the ESP32 chip itself performs the actual encryption using the stored key. This raises my core question: In development mode, is the ESP32 capable of converting the plaintext binary transmitted from the PC via serial port into encrypted binary data and writing it into flash memory while operating in download mode?

is the ESP32 capable of converting the plaintext binary transmitted from the PC via serial port into encrypted binary data and writing it into flash memory while operating in download mode?

Yes. You flash the plaintext and burn an efuse. On the next boot, the bootloader checks the efuse, sees that the firmware is not yet encrypted, reads the unencrypted firmware from flash, encrypts it, and writes the encrypted data back to flash before running the application.