Keys and derivation
The five-level, dual-curve hierarchy, derive-not-store, composable custody, and rotation by epoch.
Audience: developers · Read route: rebuild · Reflects specification v0.1
Every key the runtime needs, for a party's account, for a running instance, for a single message, for a single field, is derived on demand from a single master input plus a labelled context. Knowing the master and the context recreates the key; without the master the key is unrecoverable, and without the context it is unidentifiable. This is the derive-not-store principle: the runtime never stores a long list of keys, and that is what lets the previous page's per-field encryption scale without a key vault growing underneath it.
Five levels, two curves
Derivation follows an open, published key-derivation standard, cited here the way one cites an RFC: as the published standard on which the mechanism rests and which an implementer may follow directly. A single master input expands into two parallel curve trees, each five levels deep, and each level's input is the level above it plus a context label.
Because each field key is a distinct per-context derivation, keys are never reused, and encrypting the same value twice produces two different results.
Why two curves
The two curve trees do two different jobs from one secret.
- Curve A (secp256k1) binds the runtime to the public audit layer: ordering, audit-layer signatures, and the runtime-internal binding that the anchoring mechanism rests on.
- Curve B (P-256) signs payloads in the formats that EU digital identity wallets and web identity systems already use.
Both derive from the same master input, so an implementation covers audit-layer binding and EU wallet and web-identity signing without managing a second secret.
Composable custody, as reference recipes
Where the master input comes from is a choice, not a fixed part of the protocol. A small set of base providers and a couple of wrappers could be composed to supply it. These are example recipes, not conformance requirements.
| Base provider | Suited to |
|---|---|
| Passphrase, key-stretched into the master input | solo operators, low-friction onboarding |
| Browser-derived passphrase | flows where installing a client is not acceptable |
| A managed service that holds the master input | machine-to-machine services with a high-trust host |
| Ephemeral session token bound to a passkey | one-time approvals and consent flows |
| Wrapper | Suited to |
|---|---|
| Threshold reassembly, N-of-M across custodians | organisational continuity, multi-party governance |
| A sealed out-of-band recovery key | break-glass continuity when the base provider is unavailable |
The concrete key-management-service or hardware-module set-up, and any hosted derivation service, are operator configuration and are out of scope for this reference. The recipes above show that custody is a composition; how a particular operator provisions and runs it is not part of the base protocol.
Rotation by epoch
Keys retire per epoch. On rotation a new master input is generated, the runtime starts a new epoch, and the transition is marked publicly and anchored so that any party can tell which epoch a record belongs to. Data encrypted under a prior epoch stays decryptable to any party that held a key in that epoch. There is no re-encrypt-everything event; the log records the transition and history stays readable.
Provisional item PROV-2 (forward-secrecy trade-off), pending technical review. The per-field content-encryption key is derived deterministically from the field's own content. That determinism is exactly what lets any legitimate holder of the content rederive the key and verify the field independently, with no need to contact the party that recorded it. A deliberate consequence is that the scheme does not provide classical forward secrecy in the way an ephemeral-key transport does: determinism and independent verifiability are chosen over ephemerality. This is an engineering trade-off in favour of auditability and self-contained verification, not an oversight. The framing of this trade-off is subject to technical review; see the specification, Section 9, PROV-2.
The rules behind this page
The MUST rules for five-level, dual-curve derivation per the open key-derivation standard, per-field independent keys, and epoch rotation with prior-epoch decryptability are in the specification, Section 3.3. The exact derivation parameters are pinned by the dual-curve suite named in Section 6, not by this prose.
The envelope and field-level encryption
The versioned typed-tier record, deterministic encoding, per-field encryption, selective disclosure, and the placement descriptor.
Anchoring and the audit log
Chained, ordered, tamper-evident recording, independently verifiable proofs, and cross-domain references that carry their own proof.