Flash Guide

Reference hardware

Any ESP32-S3 with a native USB-C OTG port works. These are the boards we develop and test on:

• Development setup — ESP32-S3-N16R8 on a breadboard with both USB-C ports connected: CH343 for flashing, OTG for HID. Green LED lit means the firmware is running.
• Beta reference board — ESP32-S3-WROOM-1 DevKit. On AliExpress, Mouser or Farnell for about €5, standard form factor, easy to source.
• Finished product — same chip, same firmware, in a compact PLA case. Available as Kit Standard at launch.

Photos of all three: Developer Beta.

Supported Hardware

• ESP32-S3-WROOM-1 (any flash size)
• USB-C cable connected to the native OTG port (NOT the CH343/flash port if your board has two)

Before you flash — the beta does not burn the eFuses

The firmware published for the developer beta is the -dev track. Flashing it is an ordinary write_flash: the eFuses are not burned, Secure Boot v2 and Flash Encryption are not activated, and the board stays a standard ESP32-S3 underneath.

This is reversible. If you decide not to continue, flash any other firmware and the board goes back to what it was. You can use the €5 board that was carrying another project.

What you give up is exactly what the eFuses would have bought you:

• any firmware runs — nothing verifies a signature at boot
• NVS is not encrypted, so an SPI dump of the flash is readable
• CMD_GET_SECRET (0x04) responds, and JTAG is not disabled

A beta dongle protects against laptop theft, not against someone holding the dongle. Do not put data on it that you would not want readable by someone with physical access and an SPI flash reader. The full picture is on the beta page and in the security model.

Production dongles (Kit Standard, Kit Pro — April 2027) are the other case: eFuses burned at first boot, the lake8.dev secure boot key in place, flash encryption enabled, JTAG permanently disabled and read-flash refused. That step is permanent, and it does not happen during the beta.

Download

Latest firmware: cryptin.lake8.dev/download

Verify the signature before flashing:

# verify with lake8.dev public key

Flash via Crypt-in App (Windows)

1. Open Crypt-in Personal app
2. Connect ESP32-S3 via USB-C (OTG port)
3. Click Flash Firmware
4. Select the downloaded .bin file
5. Wait for completion

Flash via CLI

Windows only: set the console encoding before running esptool, or it fails mid-write with a UnicodeEncodeError.

set PYTHONIOENCODING=utf-8

PowerShell:

$env:PYTHONIOENCODING="utf-8"

Then:

pip install esptool
esptool.py --port COMx write_flash --flash-size keep 0x0 cryptin-firmware-vX.X.X.bin

Do not omit --flash-size keep

Without it, esptool rewrites bytes 2–3 of the bootloader header with the detected flash size (16 MB on an N16R8, against the 8 MB the project compiles for) and the chip stops booting. On a signed bootloader this is permanent — it has already cost a chip on the bench.

On the beta track the write is the whole procedure — there is no eFuse burn afterwards, and the board is ready as soon as it reboots. The burn step belongs to production dongles, where it happens at first boot.

First Boot

On first boot, the dongle generates:

• Ed25519 keypair (K_identity)
• K_attestation from hardware entropy
• BIP-39 seed (24 words)

The seed is shown once via serial (UART0/CH343 port, 115200 baud). Write it down immediately — it will never be shown again.

For DIY builders

The seed appears on UART0/CH343 at 115200 baud — the hardware serial, not the native USB port. The firmware compiles with ARDUINO_USB_CDC_ON_BOOT=0, so the native OTG port carries HID and nothing else: with only that port connected, the seed scrolls past on a console nobody is reading. You need a USB-serial adapter (CH343 or similar) to see it, and a board with both ports is the easier path.

Have the terminal open before you power the board. The seed is printed during first boot and is not repeated: attaching the console afterwards shows you nothing. And the OTG port showing no COM port at all is not a fault — it carries HID only, by design.