How to generate a key that never leaves your hands, sign things with it, and let the server verify without ever holding your secret. A reproducible runbook — the commands below actually run. We host our own reference so others can learn it, we can find it again, and anyone can do it over.
Everything else follows from this. If a private key is ever generated on the server, uploaded to it, or pasted into a session/CI secret that gets logged — the server can now impersonate you, and the whole identity model collapses. So we don't move the key to the work. We bring the work to the key (detached signing), and ship only the signature.
An Ed25519 keypair, made locally (offline is even better). The private half goes nowhere.
# the private key — this file never leaves this machine openssl genpkey -algorithm ed25519 -out builder.key # the public half — this is the only part that travels openssl pkey -in builder.key -pubout -out builder.pub
Register builder.pub against your .aint via AINS. Now the
network knows your public key — the thing that checks signatures — and nothing that could make
them. (In the AInternet stack the keychain/AINS wraps this; the shape is the same.)
Want to vouch for a build, a release, a sealed .tza? Sign it locally; emit a detached
signature. The key stays put; only release.sig leaves.
openssl pkeyutl -sign -inkey builder.key -rawin -in release.tza -out release.sig
The verifier needs builder.pub and the signature. It never needed your secret, and never
will.
openssl pkeyutl -verify -pubin -inkey builder.pub -rawin -in release.tza -sigfile release.sig
# -> Signature Verified Successfully
One rule, two ways to keep it, depending on whether a human must be present and whether a secret may sit at rest at all.
| role | custody | used for | secret at rest? |
|---|---|---|---|
| builder.aint cold key | a human, offline, on their own machine | golden builds, releases, high-trust provenance — the things that must be vouched for by a person | yes — encrypted, offline. Never on the server. |
| governor.aint sealed key | a machine's TPM | automated, machine-scoped signing that must happen with no human present | no — it materialises per-window (derived fresh from a TPM-sealed root), then it's gone. Nothing standing to steal. |
The cold key trades convenience for the strongest custody: a person, offline, deliberate. The sealed key trades a human's presence for a guarantee that no usable secret ever sits on disk — it's computed at the moment of use and discarded. Pick by the question: who must be there, and may a secret persist?
At registration: your public key. At use: a fresh challenge it hands you, and your signature over it. It checks the signature against your public key and moves on. There is no logged-in session sitting around, because there is nothing to sit around — you prove yourself fresh, each time. (That's identity as a condition, never a claim.)
Custody, in one breath: generate offline, encrypt at rest, back up offline (paper or a hardware token), guard it with a passphrase or a hardware key; for machines, seal it to the TPM and materialise per-window. Losing the hardware isn't losing yourself: a recovery knock (e.g. a mailed link) opens the door, but a fresh, independent proof closes it — then you tombstone the old binding and rebind on new hardware. The knock is never the authority; the proof is.
We host our own reference on purpose. A ceremony you can't find again is a ceremony you'll do inconsistently — and inconsistent key handling is how secrets leak. Written down and self-hosted, it becomes something others can learn from, something we learn from when we re-read it, and something anyone can reproduce line by line. Of the commons, for the commons — including the knowledge.