Security Model

The right enemy.

If you are still deciding whether Crypt-in is the right tool for you at all, who Crypt-in is for answers that question with concrete profiles. This page explains why the product is built the way it is.

Who should not buy Crypt-in

Crypt-in costs less than €100. It solves problems worth less than €100.

If you have known, serious security problems — confirmed industrial espionage, state-level adversaries, secrets worth millions — this product will not save you. Not because it is poorly made, but because your threat model requires a cybersecurity agency: physical surveillance, penetration testing, forensic analysis, and a budget in the order of €100,000 a year. Not a €5 dongle and a Windows app.

Crypt-in is for people who want to protect their data from device theft, unauthorised access and unwanted curiosity — not from intelligence agencies or professional attackers with unlimited resources.

If you are in the second group, call a specialised agency. Seriously.

Most people, most of the time, face threats on the left of this scale. Crypt-in was built for that.If your threat sits on the right, you need tools and expertise costing significantly more than €100 — and that is completely legitimate. The answer to that problem exists. It is just not us.

The three levels — economic, not technological

Anyone who wants your data has to pass three levels in sequence. Each one costs more resources, more time and more expertise than the one before.

Level	Function	Cost for the attacker
1 — PIN	Physical authentication	€0 — but only 3 attempts
2 — Firmware	Hardware resistance	€1,000–5,000 in lab equipment
3 — Seed	Master secret	€10,000+ and a coordinated operation

The barrier is not technological. It is economic.

By the time you reach the seed you are running a professional intelligence operation costing tens of thousands of euros and weeks of planning. For that there are specialised agencies charging €100,000 a year. We are not them, and we do not want to be.

Before the PIN — the paradox of theft

Without a PIN the dongle is the key to the castle. Whoever holds it walks in. No need to copy it, analyse it, or extract anything from it.

That was the problem. The PIN is the answer.

With the PIN — the arithmetic is on your side

A stolen dongle without the PIN is a €5 piece of plastic. On production dongles. A developer beta dongle is not: its flash is readable — see the beta exception below.

PIN space:               1,000,000 combinations
Attempts available:      3
Probability of guessing: 3 / 1,000,000 = 0.0003 %
After 3 wrong attempts:  permanent lock
Unlock:                  only with your 24 words

Verified on real hardware — this is not theory. A test dongle with PIN 902579 locked after three wrong attempts and did not unlock when the correct PIN was entered afterwards. Only recovery with the 24 words restored access.

The PIN is not chosen by you. It is generated by the dongle at first boot, derived from your 24 words through HKDF-SHA256. You cannot change it and you cannot pick it, which also means you cannot accidentally pick 000000 or your date of birth.

Same seed, same PIN, always, on any dongle. That is what makes backup verification possible: if the backup dongle shows the same PIN, the backup is correct.

One more detail that matters: the wrong-attempt counter is stored in flash, not in RAM. Power-cycling the dongle between guesses does not reset it — which is the first thing anyone would try.

Technical note. The lock lives in firmware. An attacker with prolonged physical access and lab equipment — JTAG programmer, hardware debugger — can reset the attempt counter. Even then your data stays safe, for the reason in the next section.

Closing the security window

Once the dongle is unlocked, the session stays open for as long as the dongle is powered. Auto-lock kicks in after roughly 10 minutes of complete inactivity.

To close the window immediately:

1. Unplug the dongle.
2. Wait at least 5 seconds before plugging it back in.

Plugging it back too quickly may not power the chip down completely: the internal capacitors keep it briefly alive, and the unlocked state survives with them.

In practice: unplug, count to five, plug back in.

This matters when you step away from a machine you do not control, or hand the laptop to someone else. It is the same habit as locking your screen, applied to the dongle.

File binding — where the check happens

The “wrong dongle” check — verifying that a .crin file was encrypted by this specific dongle — happens in the app, not in the firmware.

The firmware decrypts for any unlocked dongle physically present, regardless of the public key declared in the .crin header. If the wrong dongle is used the GCM tag does not verify and decryption fails: the file does not open either way.

What the host-side check buys is a clearer error. The app compares the pubkey before sending any data to the dongle, so you get “wrong dongle” instead of “corrupted file”.

This is by design and declared, both here and in the red team report. Security rests on possession of the physical dongle, not on the identity claimed in a file header.

Chunk counters

seq and total are exactly 3 bytes each. Verified in red team Session 3 (F-WRAP): a ~3.63 MB file, about 66,000 chunks — past the 65,536 boundary a 2-byte counter would hit. Round trip identical, GCM tag verified. The wraparound described in older code comments was historical and has been corrected.

Three bytes puts the theoretical maximum at ~900 MB.

You will not reach it. The Windows client enforces a 5 MB limit (MaxEncryptBytes = 5,000,000 bytes), because USB HID throughput of roughly 27.8 KB/s makes larger files impractical: 5 MB already takes about three minutes, and the theoretical maximum would take over nine hours.

Developers using the SDK directly are not subject to that limit — it lives in the client, not in the firmware or the format.

Full details: red team report.

PIN transmission over USB

The PIN is transmitted in cleartext over the USB HID bus during CMD_VERIFY_PIN (0x08).

This is a confirmed finding from the August 2026 red team (F-003/B1): the PIN appears at offset 3 of the HID report as 6 ASCII bytes, with no challenge-response and no anti-replay.

This is out of the declared perimeter. It requires a compromised PC with an active USB sniffer — USBPcap or equivalent. If an attacker has that level of access to your machine, you have far larger problems than the dongle PIN.

Fix planned: challenge-response for CMD_VERIFY_PIN, Q2 2027, with the WiFi firmware release — after the April 2027 public launch.

Full details: red team report.

Security advisory — 13 October 2026. Update dongles flashed from beta-2026-09-24.

Between 8 and 11 October 2026 the firmware went through seven red-team rounds. They found the defects below in the firmware of beta-2026-09-24. beta-2026-10-13 fixes all of them. If you flashed a dongle from the earlier package, update it (see Updating from beta-2026-09-24).

id	severity	what it was
F1	High	CMD_CHALLENGE (0x03): a second request arriving while a signature was being computed could replace the message half-way, so two signatures shared one Ed25519 nonce — and from that pair the identity signing key can be computed. Needs an unlocked session and a process on the host. The 24-word seed does not come out, but the key is enough to sign as the dongle. Fixed: the command is copied before it is processed, the signature nonce is hedged, and every signature is verified on the chip before it is sent.
H1	High	A malformed USB control request made the dongle send back the last report any process had written — a VERIFY_PIN included, PIN in clear — and execute it again. On a beta unit it re-unlocked the session after auto-lock, without the PIN. Fixed in the USB stack. This is a different hole from F-003/B1: that one needs a sniffer on the bus, this one only needed a process on the host.
G6	Medium	Cutting power between the PIN comparison and the write of the attempt counter gave a free guess. Fixed: the attempt is counted and written before the comparison.
J1	Medium	Some USB control requests sent with the wrong direction wrote host bytes past a one-byte buffer in the USB stack and crashed the dongle. Fixed.
G1	Low	An over-long report length was truncated instead of rejected, and could make the dongle run the previous command again — possibly another process’s. Fixed: rejected.
G2	Medium	The identity seed was drawn at first boot before the hardware entropy source was enabled. We measured first draws across reset and real power cuts and found no repetition, but the source was not what the design required. Fixed: the seed now comes from the enabled entropy source, compressed with SHA-256. A recovered dongle keeps its old seed — see the note below.
K2	Low	VERIFY_PIN had no rate limit beyond the three attempts. Now at most one attempt per second; an early one answers ERR_PIN_TOO_SOON (0xE5) and is not counted.
J4/K4	Medium	Version 1 .crin files written by the chip are not standard AES-GCM past 27 bytes, and their header is not authenticated. Fixed by format version 2 (see .crin spec). Version 1 files still open.
L3	Medium	On an unlocked session, a second process could produce a reply that a client would take for the verified end of someone else’s decryption. Fixed: the decrypt close now carries a nonce from the host.

About G2 and recovery. Recovering with your 24 words gives back the seed generated by the old firmware. That is what lets you open your old files. If the dongle will protect anything that matters, create a new identity after you have decrypted what you need, and re-encrypt.

Still open, as before: F-001-REV (session not bound to the process), F-ISO, F-003/B1 (PIN in clear on the USB bus).

The three findings below are still open; the nine in the advisory are closed by beta-2026-10-13.

F-001-REV — shared unlock session (open, High)

During the August 2026 red team an open finding was confirmed, and it is the reason the section above matters more than a convenience habit.

The unlock state is global to the chip, not bound to the handle or the process that authenticated the PIN. A second, unauthenticated HID handle can reach gated commands during an active unlock window — including the 0x0E decrypt oracle.

Mitigation in place, and its limit. Auto-lock after roughly 10 minutes without a PIN-gated command. CMD_PING (0x01) does not refresh the deadline — it is answered before the gate — so a process that only pings cannot hold the session open. That is no help here: this attacker reaches gated commands, which is the finding itself, and every one of them refreshes the timer. Auto-lock protects a genuinely idle chip, not a chip under attack. Unplugging closes the window immediately — wait at least 5 seconds before reconnecting.

Fix planned: session binding (handle and process authentication), Q2 2027 with the WiFi firmware release — after the April 2027 public launch. Until then the mitigations above are what stands between an unlocked dongle and a hostile process on the same machine.

What this finding does not do: it does not open a .crin file at rest. Without an active unlock window the file stays closed, and the attack needs code already running on your machine while the dongle is plugged in and unlocked.

Full details, with severities and exact response bytes: red team report.

F-ISO — shared block-cipher accumulator (open, Medium)

Same root cause as the finding above, and the same fix: the block-cipher accumulator is global to the chip, not bound to a handle or a session. Confirmed in Session 3, under the same condition — a compromised PC with an active unlock window.

With two OS handles open on the same dongle, chunks from the second handle are accepted into a transfer started by the first, in ascending sequence, and the resulting stream carries a valid GCM tag over interleaved data. A single out-of-sequence chunk from the second handle aborts any encrypt or decrypt in progress, which is a trivial denial of service.

Fail-closed, and that is the part that matters. The victim’s own tag, taken over the truncated stream, does not verify — so the transfer fails rather than producing a file the victim would go on to accept. There is no silent poisoning.

Fix: session binding, the same milestone as F-001-REV — Q2 2027, with the WiFi firmware release. F-ISO is therefore open at the public launch too.

Full details: red team report.

F-004 — licence status pre-auth (remediated)

Prior to August 2026, CMD_GET_LICENSE_STATUS (0x0C) responded without PIN authentication, revealing licence validity and expiry to anyone with USB access to the dongle.

Status: remediated. 0x0C now requires the PIN and returns ERR_PIN_REQUIRED on a locked dongle. Verified on hardware.

Full details: red team report.

F-NEW-RAM — PIN transient in RAM (mitigated)

After PIN entry the PIN briefly exists in process memory as a .NET string — TextBox.Text is immutable by construction, so the control keeps its own copy until the garbage collector reclaims it.

Mitigation. The char[] buffer handed to the SDK is zeroed immediately after the HID exchange, and ShortcutsEnabled is disabled on the control so the PIN cannot be copied to the clipboard.

The TextBox control retains its own internal copy briefly until the .NET GC reclaims it — a platform limit, not a code defect. The application cannot zero what it does not own.

This is a reduction, not an elimination: it requires a compromised PC with ReadProcessMemory access, which is outside the declared perimeter.

Full details: red team report.

What lake8.dev receives, and what you choose

The keys never leave the chip. What does travel to lake8.dev, and how much of it, is partly your decision at activation time.

Anonymous activation is not a discount or a lesser tier: it is the same product, activated without telling us who you are. Registered activation exists because invoicing and VAT sometimes require it, not because we need the data.

Protection even against custom firmware

On a production dongle, custom firmware cannot run: Secure Boot v2 accepts only images signed with the lake8.dev key, and a flash dump yields ciphertext because Flash Encryption is on. That — not the PIN — is what protects the seed stored on the chip. Developer beta dongles have neither: custom firmware runs and the seed can be read — see the beta exception below.

Authentication and cryptography stay separate layers: the PIN protects ordinary use of the dongle, and the keys that decrypt .crin files derive from the seed, not from the PIN. Removing the PIN check does not by itself hand an attacker the keys. What keeps the seed itself out of reach is the eFuse configuration of the chip it lives on.

Secure Boot — production dongles. Production dongles (Kit Standard, Kit Pro — April 2027) burn the eFuses at first boot and run with Secure Boot v2 and Flash Encryption active. Verified on real hardware, on a virgin chip rather than the development dongle:

• Secure Boot: enabled
• Flash Encryption: enabled
• JTAG: permanently disabled
• read-flash: refused, the chip is in Secure Download Mode
• write-flash with an unsigned binary: refused

On such a dongle only firmware signed with the lake8.dev production key runs, and that is what blocks the attack described just above — flashing custom firmware to remove the PIN check.

The developer beta is a documented exception. Since 24 August 2026 beta units run the -dev firmware track and the eFuses are not burned: Secure Boot v2 and Flash Encryption are not activated on beta hardware. The board stays fully reversible — flash any other firmware and it goes back to being a standard ESP32-S3.

That has consequences, and they are the reason this is written here rather than left implied. On the dev track CMD_GET_SECRET (0x04) responds and the flash is readable via an SPI dump: a beta dongle protects against laptop theft, not against an attacker who has the dongle in their hands. Do not put data on a beta dongle that you would not want readable by someone with physical access and an SPI flash reader.

Beta licences are dated to 31 March 2027 — a fixed date, not a duration from activation. That exp claim is enforced online, by the licence server, when a licence is activated or transferred. The dongle has no clock, so a beta dongle already set up keeps decrypting your existing files offline after that date: what ends is the ability to activate or transfer a beta licence, not your access to what you have encrypted.

The red team sessions of August 2026 ran on a -dev dongle with virgin eFuses — established on 2026-09-29 by reading the chip directly, and corrected in the report on that date. The report originally claimed a production-track unit; that was wrong. The findings are about protocol and firmware logic and do not depend on the eFuse state, but they were not reproduced on a production-configured dongle — see the assessment and its erratum.

Anti-rollback is not implemented yet. It needs OTA support, which the current firmware does not have, and will arrive before the public launch together with the update mechanism. Until then, a signed but older firmware image could in principle be installed.

Firmware update channel

Firmware updates are distributed exclusively through the releases page of github.com/jaffa2970/Crypt-in-BETA, During the beta the firmware ships inside the package, as firmware\firmware.factory.bin, and it is not signed: it is the -dev build, which carries no Secure Boot v2 signature block because beta units have virgin eFuses. Check it by hash, against SHA256SUMS.txt.

Signing belongs to production firmware, from the April 2027 launch: there the image is signed with the lake8.dev production key, the Windows app verifies the signature before flashing and the dongle verifies again at boot — two independent checks, the second of which does not depend on our software behaving correctly. Neither check runs on a beta unit.

Flashing outside the official channel is possible but unsupported — you own the consequences. On production dongles unsigned images do not run at all: Secure Boot v2 blocks them before they execute. On the -dev beta units Secure Boot is not active, so unsigned firmware runs — which is what makes those boards fully reversible, and is set out in full above.

→ Full firmware update security model

Three common mistakes to avoid

1. Nobody from lake8.dev will ever ask for your PIN or your 24 words. If someone does, they are a scammer. Report it to security@lake8.dev.
2. Do not photograph your 24 words. Photos sync to the cloud automatically. Write them on paper. Only on paper.
3. Watch out for cloud sync on your PC. Encrypt first, then move the .crin file. If Dropbox or OneDrive syncs a file before you encrypt it, the cloud already has the plaintext.

The backup procedure

At first boot the dongle shows, once and once only:

• your 24 words
• your 6-digit PIN

Write them down on paper now. They will never be shown again. Seed and PIN are born together, stored together, recovered together.

The 24 words are a human-readable backup of K_root. They are shown once at first boot over serial (UART0, 115200 baud) and never again — write them down immediately.

Creating a backup dongle

1. Get a second Kit Standard from lake8.dev — recommended, it arrives ready — or a compatible ESP32-S3 if you know what you are doing.
2. Windows app → Create backup dongle.
3. Follow the guided steps and enter your 24 words when prompted.
4. The app shows the backup PIN. It must be identical to your original PIN. If it differs, start again.
5. The app registers the second chip with the licence server, by its own K_attestation, and extends the entitlement to it.
6. Backup verified and ready.

Where to keep things

• Main dongle: with you, daily use.
• Backup dongle: a physically separate location — a safety deposit box, or the home of a relative who does not live with you.
• Paper with the 24 words and the PIN: two copies, two separate locations.

Never digital. Never photographed. Never stored with the dongles.

Two copies because paper degrades. A second copy costs nothing; losing the only copy costs everything.

Recovery takes minutes with the backup nearby, or 3–5 working days if you have to order a new Kit Standard.

Licence note — a backup and a replacement are not the same operation.

• Backup dongle — two dongles alive at the same time: same seed, same cryptographic identity, licence active on both. One backup per calendar year, resetting on 1 January. A licence covers two chips in total; from the third one on you need a separate licence.
• Replacement dongle — the original broke or was lost. The entitlement moves to a new chip and the old one stops counting, so you are back to one live chip. At most three a year.

To the server both are “transfer the entitlement to another chip’s K_attestation”, which is why they get confused. The difference is what happens to the first chip: with a backup it stays alive, with a replacement it does not. Both limits are anti-abuse, not cryptographic — write to info@lake8.dev for exceptional cases.

Annual maintenance checklist

• The backup dongle decrypts a test file
• The paper is still readable
• Both copies still exist
• The licence has not expired

Your 24 words are like crypto wallet keys

Millions of people manage 24 BIP-39 words to protect cryptocurrency. Same standard, same responsibility.

If you lose the 24 words and the dongle breaks, your files are permanently inaccessible. Nobody can help — not even lake8.dev. That is not a bug: it is the guarantee.

Vault

Vault is not available

Vault is planned for 2027, date to be announced. It is not part of the developer beta, it cannot be bought or deployed, and what follows describes the intended design — not shipped software.

Vault extends Personal with a self-hosted document server. The same dongle and the same .crin format apply — nothing new is introduced at the cryptographic layer.

What is different: Vault requires network connectivity between the clients and the server holding the dongle. That link is part of your infrastructure, not ours, and it is inside your threat model rather than this page’s.

Full documentation at product launch.

What the lake8.dev server is for

The lake8.dev server handles four things:

1. Initial licence activation — one contact, when the dongle is first set up.
2. Annual licence renewal.
3. Registration of a backup dongle — one per calendar year, resetting on 1 January. Both chips stay alive and licensed.
4. Licence transfer to a replacement dongle — at most three times a year. The chip being replaced stops counting.

That is the complete list. It is not contacted during normal use: no periodic check-in, no phone-home, no session validation.

Not needed to decrypt files. An activated dongle decrypts entirely offline, and would keep doing so if lake8.dev ceased to exist. A lapsed licence stops new encryption; it never touches decryption.

Summary — the right enemy

Scenario	Does Crypt-in solve it?
Laptop stolen from a car	✅ Yes
Nosy colleague at your PC	✅ Yes
Decommissioned hard drive still holding data	✅ Yes
Ransomware on already-encrypted files	✅ Yes
Breached cloud backup	✅ Yes
Stolen dongle, no PIN	✅ Yes — a piece of plastic
Custom firmware	✅ Yes on production dongles — blocked by secure boot; on beta -dev units it runs, and only the seed still protects the data
Files saved to the cloud before encryption	❌ No — encrypt first
PC with a keylogger or malicious hardware	❌ No — that is a PC problem
Fake tech support	❌ No — but we will never ask
Physical coercion	❌ No — no technology can
Coordinated industrial espionage	❌ No — call an agency
State-level intelligence	❌ No — change country
Your own chronic negligence	❌ No — nobody can
lake8.dev itself compromised	✅ Zero impact — we do not hold the keys

The technical detail behind all of this is in the threat model and in the HID protocol.