Split-custody cryptography · repository verification
The cloud preserves the vessel.
Your quorum completes the key.
DaemonChalice™ splits decryption authority instead of cutting a unique piece out of every file. DaemonGates can preserve client-encrypted, erasure-coded content while a customer-held A quorum and a separate cloud B quorum remain necessary to open it.
Current truth: the signed grant protocol, threshold/client cryptographic core, cold-Seed cohort separation, network share lifecycle, and init/activate/put/get/erase/delete/abort/reshare CLI are repository implemented under verification. No production Chalice Gate cohort, managed recovery service, automatic B-share repair/rotation, secure-hardware integration, Persona consent engine, or automatic inheritance workflow is live.
Split authority, not plaintext
Keep the irreplaceable part small.
A unique local slice of every file would make streaming, repair, versions, and recovery depend on one fragile piece of content. DaemonChalice instead encrypts the complete object and distributes recoverable ciphertext. The customer keeps only the small authority required to complete decryption.
That authority is not one cloud master key. A and B are independently random, threshold-split, and combined only on the recovering client to unwrap a fresh per-object data key.
Fresh object key
The client encrypts and authenticates content before an untrusted storage participant sees it.
PLAINTEXT STAYS LOCALOpaque data shards
Encrypted content is erasure-coded across one fixed data cohort with an explicit recovery threshold.
AVAILABILITY DOMAINA and sealed B
A becomes customer-held custody files. Every B contribution is HPKE-sealed to an A-derived client key.
AUTHORITY DOMAINSCombine locally
The client verifies both quorums, reconstructs A and B, unwraps the object key, and decrypts locally.
NO CLOUD RECONSTRUCTIONCold-Seed-enforced separation
The two cloud cohorts cannot quietly collapse into one.
The data owner signs a bounded Chalice request for one exact data grant. On the never-networked authority machine, DaemonSeed issues a separate tiny chalice grant only after selecting primary and staging Gates that do not appear anywhere in the data grant.
The two grants use unrelated Gate-visible object and grant identifiers. That reduces what an individual Gate can link; it does not hide the relationship from the cold Seed ceremony.
Encrypted substance
For each shard set, a Gate holds at most one authenticated ciphertext fragment under the content grant.
- No A share
- No B placement
- No plaintext key
≠NO SHARED
GATE IDENTITY
GATE IDENTITY
Sealed authority contributions
Each Gate holds one bounded B-share HPKE ciphertext under the Chalice grant.
- No data placement
- No A share
- No B reconstruction
Independence boundary
Distinct Gate identities do not automatically prove distinct companies, administrators, power systems, jurisdictions, or physical hosts. The signed policy also carries operator, provider, region, and network diversity requirements; real independence still needs deployment evidence.
Initial custody profiles
One construction. Different human policies.
A mode is policy presentation, not a weaker or stronger cipher suite. The initial Personal and Household modes distribute authenticated A share files. Copying two files onto one disk does not create two failure domains.
Your selected places
Choose a threshold across separate custody files—for example a laptop, home machine, and offline medium.
FILE-SHARE PROFILEYour selected holders
Distribute a threshold among people or devices you choose. The label does not prove family, identity, or independence.
FILE-SHARE PROFILESeparate policy groundwork
Daemonet has organization quorum primitives, but they do not yet authorize a DaemonChalice release. Organization roots are not reused as A.
NOT INTEGRATEDNo automated inheritance
Trustees, waiting periods, succession, identity, and legal determinations require a separate reviewed protocol and operating model.
NOT IMPLEMENTEDRecovery ceremony
The complete key exists briefly where the file is opened.
A trusted client verifies the pinned Seed, exact request, grants, binding, manifest, and every authenticated share before reconstruction. Failure is visible; missing material is never replaced with a provider override.
Collect A
Supply the configured threshold of authenticated customer-held files. Wrong Chalice, request, index, or threshold policy fails.
Fetch sealed B
The A-derived owner key authorizes exact Gate fetches; the A-derived exchange key opens returned HPKE envelopes.
Reconstruct locally
The client combines B, derives the wrapping key from A and B, and authenticates the wrapped object key.
Restore content
Enough verified ciphertext shards reconstruct and decrypt on the client. Temporary secrets are cleared as a best effort.
Current authorization boundary
This is possession-based command-line recovery. The separate data-owner vault or recovery bundle is also required to authorize data-shard reads, but cannot decrypt a Chalice object by itself. It does not verify an application binary or purpose, display a Persona consent request, require a one-time app release, or attest a phone enclave or laptop TPM. Existing service-access passes authorize network ports—not Chalice content-key release.
Honest limits
Custody is meaningful only when failure is named.
DaemonChalice can keep DaemonCloud from independently reconstructing an object under the configured policy. It cannot protect plaintext after a legitimate or compromised client opens it.
Endpoints still matter
Malware, screen capture, exports, crash dumps, swap, and copied plaintext sit beyond the shard threshold. A stolen data-owner vault cannot decrypt without A+B, but can copy or destroy ciphertext and deny availability.
Loss can be permanent
Intact ciphertext is useless if either the A or B threshold becomes unreachable. Restore drills are part of custody.
Metadata remains
Participants see their own grants, sizes, timing, owner keys, and requests. Tor is not proof of anonymity.
Erasure is qualified
Best-effort cryptographic erasure can make known ciphertext unusable; it cannot erase plaintext or keys someone already retained.
Removal needs fresh authority
A removed Household holder can still use old authority or plaintext they copied. Future access requires a reviewed rotation, fresh shares, and rewrapping.
Capacity is not recovery
The public aggregate reports infrastructure totals—not Chalice modes, unlocks, share health, placement, or per-object recoverability.
Release evidence
A successful unit test is the beginning of a storage claim.
Live custody requires independent cryptographic review, clean-client restores, deliberate shard and holder loss, interrupted placement and recovery tests, multi-operator deployment, repair monitoring, update/rollback evidence, and audited secret handling.
Preserve data without centralizing the decisive authority
DaemonCloud stores encrypted substance.
DaemonChalice controls reconstruction.
The strongest accurate statement today is narrower than a service promise: the protocol, client crypto/network lifecycle, and CLI are repository implemented under verification; live distributed custody and production recovery remain evidence-gated.
Aggregate capacity is exact above its publication floor and may reveal infrastructure changes. It contains no customer, Chalice, mode, unlock, key-share, or placement fields and is not evidence that an individual object can be restored.