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 on GitHub, the same package as the Windows DLL and the Linux CLI. Not a separate product. If it is ready earlier, it ships earlier.

Until then, use the .NET 9 Linux CLI for Linux and macOS integration.

Two separate deliverables

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

	Linux CLI	Python client
Ships	30 September 2026 (fallback 30 October)	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 — but the CLI arrives with the developer beta and the Python client does not. Do not plan a Python integration around the September date.

What to use instead

For Linux and macOS integration today, use the .NET 9 CLI (coming September 2026) or reference CryptinSDK directly.

Target	Use	When
Windows application, C#	Windows SDK (DLL) — Apache-2.0	Available
Linux, macOS, scripting	Linux CLI, .NET 9, Apache-2.0	30 September 2026, fallback 30 October
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.

Target 30 September 2026, fallback 30 October 2026. 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 and answers ERR_DEPRECATED — the file secret never leaves the chip, so a client cannot derive a file key itself and does not need to.

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.