The extraction challenge

Status — open since 12 October 2026. Submissions close on 31 March 2027.

Download the challenge image: github.com/jaffa2970/cryptin-challenge (release challenge-2026-10-11) — read its README before you flash: the first boot burns the chip for good, and two mistakes in the flashing procedure brick it.

Want to play hard with us? Then beat the silicon.

The claim that would actually interest us is pulling the identity seed off a chip with Flash Encryption burned in RELEASE mode — where the flash is XTS-AES ciphertext and no command ever hands the seed out. That barrier is not our cryptography; it is the ESP32-S3 platform. We stand on it, and we told you exactly how the beta differs: the beta dongle is an open book, on purpose.

The flag is the identity seed — the 32-byte BIP-39 entropy that is the Ed25519 private key. Not file_secret.

On a provisioned, acknowledged dongle the seed leaves through no command. CMD_GET_PROVISIONING (0x09) hands it out once, before acknowledgement, and then the NVS flag closes it forever (ERR_ALREADY_ACKNOWLEDGED, 0xE4, terminal). CMD_GET_PUBKEY (0x02) returns only the public key; CMD_CHALLENGE (0x03) only signs; CMD_GET_SECRET (0x04) returns a different secret, file_secret — and only on the -dev beta track, since on production firmware it answers ERR_DEPRECATED. So on any dongle past setup, the only way to the seed is to read the flash: in the clear on -dev, XTS-AES ciphertext on a chip with Flash Encryption burned. The challenge image removes even that one-time door.

The game — three steps, no bureaucracy

1. Check the seal yourself. On the challenge image the seed has no door at all: CMD_GET_PROVISIONING (0x09) and CMD_GET_SECRET (0x04) are refused, the serial console prints no words and no PIN, and there is no recover. CMD_GET_PUBKEY (0x02) and CMD_CHALLENGE (0x03) answer without a PIN — the public key and a signature, never the seed. Proven, by you — the full command table is in the HID protocol spec.

2. Flash the challenge image from github.com/jaffa2970/cryptin-challenge — not the beta binary, which is built with flash encryption off and bricks the chip if you burn on top of it. Follow the README exactly: never --flash-size detect, and never a reset during the first ~6 seconds of the first boot. The first boot burns Secure Boot v2 and flash encryption in RELEASE mode by itself and generates the seed inside the chip; nothing ever returns it — no recover, no 24 words. If you do not extract it, the board is a paperweight.

   After the first boot, read the unit’s public identity key with CMD_GET_PUBKEY (0x02 — no PIN needed on this image) and send it to us before you start attacking. We publish it, and it becomes the fingerprint your extraction has to match; a fingerprint produced after the fact proves nothing, which is why the order is part of the rules. It must be RELEASE, not Development (Development mode leaves a known re-flash path and is not the barrier), and you send the output of esptool get-security-info, which still answers in Secure Download Mode: Secure Boot Enabled, Flash Encryption Enabled, SPI_BOOT_CRYPT_CNT 0x7, JTAG Permanently Disabled. There is no going back from a RELEASE burn.

3. Extract the seed — the 32 bytes — from the encrypted flash of that burned chip, and tell us how you did it. We derive the public key from the bytes you send and match it against the published fingerprint. A match proves you hold the seed. It does not yet prove how you got it: on a chip you prepared yourself, a seed can be planted before the seal. So we re-run your method on our own reference chip — burned by us with the same image on 11 October 2026, its history known, its key read by us at first boot. If your method pulls our seed too, the break is real and it is ours to answer. If it works only on your chip, the claim stays NOT REPRODUCED. A method we cannot reproduce stays open until it is described well enough to be — asking for details is not an accusation, it is how a real break proves itself.

   Our reference unit: chip 14C19F200E48, burned on 11 October 2026 with this same image — public identity key 375da2f2ddbdefb3f4a82ed5126b8985f12446977d6d01bb64faf8ca78ee6334.

We are honest. If a claim is not, we publish why.

Every claim and its outcome is public — your method and our verification — and we publish them all, as a running list. We do not call anyone a liar: we state what is verifiably true and let the numbers settle it. Each claim is one entry, from open to resolved:

state	meaning
🔴 open	received and not yet adjudicated — or a confirmed break we have not yet responded to
🟢 closed	NOT REPRODUCED or OUT OF SCOPE — the math did not hold, or it was a documented port (e.g. 0x04 is file_secret, not the seed), nothing for us to do
🟢 ⚠ confirmed	a real break: the derived key matched and the method extracted the seed of our reference chip too. Published with our response — fix, disclosure, rotation or erratum — and kept on this page

A confirmed break never silently turns into a plain green: this list is honest in both directions — a break of our own barrier lands here too.

Claims & outcomes

Published as they arrive. Nothing received yet.

Date	Claim	Verdict	Our response
—	—	—	—

How to submit

Send your result to security@lake8.dev, encrypted to our PGP key:

curl -sO https://cryptin.lake8.dev/security.asc

One message, four things:

1. The 32 seed bytes you pulled off the chip.
2. The public identity key we published for that unit — the fingerprint you committed in step 2.
3. Proof of RELEASE mode: the output of esptool get-security-info, which still answers in Secure Download Mode: Secure Boot Enabled, Flash Encryption Enabled, SPI_BOOT_CRYPT_CNT 0x7, JTAG Permanently Disabled.
4. How you did it, in enough detail for us and others to reproduce.

Asynchronous and offline, by design

There is no live verification endpoint, and there will not be one. This site, the production licence server and the red-team clone all answer on the same host: a public challenge with a live endpoint on that box would be a denial-of-service lever pointed at production. Submissions go by encrypted mail and we answer by mail.

What a win means

Crypt-in’s threat model excludes laboratory attacks on the chip — side channels and fault injection. This challenge allows them anyway, because we want to know where the barrier really ends.

• A win through software — USB, HID, the ROM in Secure Download Mode, the console — falls inside what the product claims to resist. It is a finding on the product, and the problem is ours.
• A win through the lab — glitching, power analysis, an opened package — reproduced on our reference chip, is confirmed on the challenge. It confirms the limit we declare: the product never promised to hold against that attacker.

Where things stand publicly, checked on 11 October 2026: no Secure Boot or flash-encryption bypass is known for the ESP32-S3. One published glitch attack (AR2026-005) recovers the key of the general AES peripheral, not the XTS key of flash encryption; on Crypt-in that peripheral encrypts files with per-file keys and never runs without the PIN. On sibling chips the bypass exists — the original ESP32, and the C3/C6 (AR2023-007, which Espressif considers theoretically applicable to every chip with XTS-AES, the S3 included). The S3 has no hardware glitch detector. Flash encryption on the challenge image uses the ESP-IDF default, XTS-AES-128.

Do that and we will credit you, and say in writing what it means — for the platform, for the product, or for both.

Scope & safe harbour — read this

In scope: the dongle in your own hand, and nothing else.

Explicitly out of scope, and covered by no safe harbour: our servers, the host at 5.157.106.226, license.lake8.dev, and any other user’s device or data.

This challenge is a different exercise from the Beta Red Team — Rules of Engagement and from the general Vulnerability Disclosure Policy: attacking your hardware is invited — it is the one exception to the VDP’s exclusion of chip-level physical attacks — while attacking ours is not. “Attack our hardware” never means “attack production”.