Python tools (internal → SDK Q2 2027)

The Python files in tools/ are currently internal test harnesses, used during development and red team sessions. They are not a distributable SDK today.

There is no pip install cryptin-sdk, there is no Python package, and there is no support commitment attached to these files. They exist to drive the dongle from a shell while the firmware is being tested — nothing more.

Coming Q2 2027: a proper Python client ships as part of CryptinSDK — Apache 2.0, free, the same package as the Windows DLL and the Linux CLI. Not a separate product. If it is ready earlier, it ships earlier.

The .NET 9 Linux CLI has still not shipped as a binary package — it was not in the beta package and no date has been announced — but since 17 October 2026 its source is published in cryptin-sdk-beta (src/CryptinCli/, Apache-2.0) and it compiles. On Linux and macOS you can only write your own client against the published HID protocol.

Two separate deliverables

They are often confused. They are not the same thing and they do not ship together:

	Linux CLI	Python client
Ships	not shipped — it was not in the beta package, no date announced	Q2 2027
Built on	.NET 9, cross-platform	Python
Licence	Apache 2.0	Apache 2.0
Part of	CryptinSDK	CryptinSDK

Both live inside CryptinSDK — neither is a separate product — and neither has shipped. The CLI was expected with the developer beta and was not in that package; it has no announced date. Do not plan an integration, in Python or otherwise, around the September date.

What to use instead

On Linux and macOS today, write your own client against the published HID protocol and .crin format.

Target	Use	When
Windows application, C#	Windows SDK (DLL) — Apache-2.0	Source published (beta) — cryptin-sdk-beta
Linux, macOS, scripting	Linux CLI, .NET 9, Apache-2.0	Source published; no binary package, no date
Python	Python client, Apache-2.0, part of CryptinSDK	Planned Q2 2027
Any other language	The HID protocol is published in full	Available

The CLI is a wrapper around CryptinSDK. Four commands:

cryptin encrypt    cryptin decrypt    cryptin status    cryptin unlock

The PIN is read from stdin, never from argv — it must not end up in the shell history or in the process table, where any local user could read it with ps.

It has not shipped: it was expected with the developer beta and was not in that package, which is Windows-only. No new date has been announced. Status on the investors page.

Writing your own client

Nothing about the Python tools is needed to interoperate. The HID protocol and the .crin format are published in enough detail to write an independent client in any language, with no agreement and no repository access. That is the point of publishing them.

The one thing worth repeating from the protocol reference: CMD_VERIFY_PIN (0x08) comes first. Five opcodes are exempt from the gate — 0x01, 0x08, 0x09, 0x0A, 0x0B — and every other one is refused with ERR_PIN_REQUIRED until it succeeds.

There is no derive_session_key. Command 0x05 is reserved and not implemented.

Since firmware 2026-08-02 the file key is derived entirely on the dongle. The host streams plaintext chunks in with CMD_ENCRYPT_BLOCK (0x0D), or ciphertext chunks with CMD_DECRYPT_BLOCK (0x0E), and gets the result back: nothing that could reconstruct the key crosses the bus. CMD_GET_SECRET (0x04) is deprecated: on production firmware (-prod) it answers ERR_DEPRECATED and the file secret never leaves the chip, so a client cannot derive a file key itself and does not need to. On the developer beta track (-dev) it still responds with file_secret — intentionally, because that track is open for security research.

Licence

See the licence page. The SDK — Windows DLL, Linux CLI, and the Python client from Q2 2027 — is Apache-2.0, one package. The Python tools in tools/ today are internal and are not licensed for redistribution as a product.