Try the interface used by smart cards and hardware security modules, using software on your computer. Haskoki lets you create a disposable key, sign a message, check its signature, and experiment with encryption. No hardware or Haskell knowledge required.
PKCS#11 is the common interface that applications use to ask a token
to hold keys and perform cryptographic operations. Haskoki is a software
token written in Haskell, a functional programming language. OpenSSL
performs the cryptography; ordinary tools talk to Haskoki through
libhaskoki.so, just as they would load another PKCS#11 module.
Use disposable keys. This is a demonstrator for learning and client testing, not a production HSM; its stored keys are not encrypted at rest.
With Docker running, paste this into a terminal:
mkdir -p out
docker run --rm --network none --user "$(id -u):$(id -g)" \
-v "$PWD/out:/out" ghcr.io/mingulov/haskoki-demo:v0.3.0.0 demoDocker downloads the image on the first run. The demo itself works offline: it generates keys, signs and verifies a message, checks a SHA-256 fingerprint, and encrypts then decrypts another message. Look for:
demo-ok: 8/8 verifications hold
That's the complete first run. No clone, compiler, account, PIN setup, or
physical token is needed. Reports and disposable keys remain in out/demo-*/.
This checkout prepares v0.3.1.0, adding a prepared shell and p11-kit
remoting. Its registry tag is available only after publication. The
hands-on guide shows how to load a tested candidate,
generate a key with pkcs11-tool, and sign your own message.
The demo image includes Haskoki, its runtime and crypto libraries, OpenSC
pkcs11-tool, pkcs11-check, and pkcs11-proxy-ng; the candidate adds
p11-kit server/client examples. Extra
test-vector collections are an optional download. The tested platform is
Linux x86-64 (amd64); Docker supplies the Linux libraries. Other platforms
and ARM emulation have not been qualified. Image measurements and contents
are in Try it.
Haskoki explores a development idea: describe a token's rules in Haskell, test that model separately, then let real applications challenge the compiled module. The aim was easier development with broad, explicit coverage of PKCS#11 behavior: keys, sessions, errors, and interrupted work.
pkcs11-check supplies the external checks. pkcs11-proxy-ng keeps Haskell's runtime and shared libraries in a separate process, so a client can use Haskoki through a PKCS#11 shim. Reusing that transport avoided building a custom client/daemon protocol alongside the token.
Coding agents helped implement and review the project; tests and consumer runs supply the behavioral evidence. The development story explains the design, its milestones, and the recorded AI-token usage.
A side note: p11scope can observe PKCS#11 calls on Linux. It is optional and runs separately; an observer note explains that route.
| I want to... | Start here |
|---|---|
| Generate a key and sign something myself | Hands-on guide |
| Try the checker or another process | Checker and remoting |
| Understand the project and its creation | Development story |
| Load it in my own application | Native reference and host requirements |
| Investigate support or build the project | Coverage, results, developer toolchain |
Haskoki exposes PKCS#11 2.40-3.2 interfaces, with 316 behavior-tested mechanisms out of 464 catalog entries. The full checker profile retains 22 documented findings; the short smoke profile expects zero. Neither number establishes conformance or certification. See the results and limits before choosing it for an integration.