Introduction
A key that never exists cannot be stolen. Article 2: Ineffable Cryptography and the Cybersecurity Fabric establishes this as the core invariant of the Tide architecture and introduces the four surfaces across which authority is dissolved: storage, use, governance, and policy logic. But declaring that a key never exists raises an immediate question: how is it created in the first place? How is it backed up? How does it survive the loss of a server, or the departure of an employee, or the exit of an entire organization from the platform?
Traditional key management answers these questions through custody - keys are generated uniformly at random, stored securely, retrieved for use, rotated on schedule, and eventually revoked. Every stage assumes the key is a discrete object that must be guarded. Even threshold systems that split keys into shards typically follow a "generate-then-split" model: a trusted dealer creates the complete key, then distributes fragments. The dealer is a single point of compromise at the most critical moment of the key's existence.
Tide's lifecycle operates on a fundamentally different premise.
Keys are born as distributed fragments - no dealer, no moment of assembly, no complete artifact at any point.
They heal when infrastructure degrades, recover when users lose access, rotate without changing their identity, and can be verifiably destroyed when an organization departs. At every stage, the complete key remains ineffable: it cannot be expressed, cannot be extracted, cannot be brought into existence. This article traces that lifecycle from birth to death.
Loading diagram...
FIGURE 5: Ineffable Key Lifecycle
Born Fragmented: Distributed Key Generation
The lifecycle begins with a guarantee: the key's first moment of existence is as 20 distributed shards across independently operated ORK nodes. The complete private key is never computed by any party.
Tide achieves this through Nested Shamir Secret Sharing, a Distributed Key Generation construction published by Hall, J. L., Hertzog, Y., et al. (2023, arXiv:2309.00915 ). Unlike generate-then-split approaches, Nested Shamir DKG has no dealer. When a new key is required - whether a CMK (user identity), VVK (vendor signing key), or CVK (user personal key) - the ceremony is orchestrated across the assigned 20-node ORK swarm. Each ORK generates its own random sub-secret, splits it into sub-shards for its peers, and distributes them over encrypted channels. Every ORK then aggregates the sub-shards it received into a single final shard. The global private key is mathematically defined as the sum of all 20 sub-secrets - but because those sub-secrets were sharded and aggregated without any node seeing another's value, no entity ever computes that sum. The public key is derived collaboratively and is the only artifact that exists in complete form.
Loading diagram...
FIGURE 6: Ineffable Key Generation
The resulting shards are distributed at a -of- threshold: any nodes can collaboratively perform a key operation, up to can be offline without degrading availability, and up to can be compromised or colluding without breaking security. Each node is operated by a different organization on independent infrastructure.
The full DKG ceremony, including the cryptographic constructions and message-level detail, is specified in the Account Creation / KeyGen protocol.
Validation Without Assembly
Generating shards without assembling the key raises an immediate verification problem: how does Tide Cybersecurity Fabric confirm that DKG completed correctly - that all shards are consistent, the derived public key is valid and that each ORK is satisfied its own shard was a component of the overall key - without reconstructing the secret?
Each ORK publishes a cryptographic commitment to its sub-secret (a public point) and provides a zero-knowledge proof of possession. After aggregation, the ORK swarm collaboratively produces a threshold group signature using the newly minted shards, signing the transaction record. If any ORK contributed invalid data, the polynomial properties will fail to align and the group signature will not verify against the public key. In addition, the SWE performs a "test run" after key generation to guarantee this process is reproducible. The Fabric validates the integrity of the unseen private key solely through the cryptographic outputs of its shards.
Healing: The System Repairs Itself
Infrastructure degrades. Servers fail, operators leave the network, hardware is decommissioned. When an ORK node becomes permanently unavailable, its shard is lost. To maintain the required threshold, the Fabric must generate a replacement shard for a new node without reconstructing the key.
Key Healing is a system-initiated process. When the Fabric detects a degraded shard set, a threshold of healthy ORKs collaboratively compute a new valid Shamir shard mapped to the replacement node's identifier. The computation leverages the homomorphic properties of the existing shards - the healthy ORKs produce the replacement shard without learning it, without combining their own shards, and without any entity computing the master secret. The key heals itself.
Healing is distinct from recovery: healing repairs the infrastructure (the shard set), while recovery reclaims user access. Both maintain the invariant that the complete key never materializes.
The full mechanism is specified in the Key Healing protocol.
Recovery: The User Reclaims Authority
When a user loses their device, forgets their password, or suspects credential compromise, they lose the ability to authenticate to the Fabric. They must reclaim authority over their key - without the key being reconstructed.
Tide's Decentralized Account Recovery treats this as a threshold-validated secondary authentication. The user initiates a recovery request, and each ORK in the swarm independently sends an email to the user's registered address containing an encrypted, self-issued recovery credential. To make this process easy, the user clicks links from a threshold of these emails, and the Secure Web Enclave collects the encrypted credentials on its own. Once a threshold is reached, the Fabric invokes the key generation machinery to produce new PRISM authentication credentials linked to the user's existing CMK - enabling the user to set a new password and regain operational control.
The full ceremony is specified in the Decentralized Account Recovery protocol.
Maintenance and Rotation
Even if no nodes fail, static shards held indefinitely represent a theoretical risk. An attacker who compromises one node per year might eventually accumulate a threshold.
Proactive Secret Sharing eliminates this vector. On a scheduled basis, or whenever a user updates their credentials (rotating the PRISM secret), the ORK swarm collaboratively refreshes all shards. The result is a completely new set of 20 shards that are mathematically incompatible with the old set - but the underlying master key remains unchanged. The public key does not change, downstream systems are unaware that rotation occurred, and an attacker who stole a shard at time gains nothing after rotation at .
Password changes - which rotate the PRISM verification secret across the entire swarm without the old or new password ever materializing in complete form - are specified in the PRISM Password Change protocol.
Disposal: The Ragnarök Protocol
A system that can never release an organization's keys is not a security tool - it is a different kind of lock-in. The Ragnarök Protocol is the sole, protocol-controlled intended deviation to the "never assemble" invariant - simply because it operates outside the Tide paradigm: a verifiable off-boarding mechanism that allows an organization to export its complete VVK and exit the Tide network.
Ragnarök is initiated by the organization's administrators and requires cryptographic quorum approval - the same signed and blind-signed consent mechanism that governs all administrative changes to key properties. When the quorum approves, the ORK swarm encrypts their respective VVK shards against a Ragnarök Generation Key (RGK) - a distinct key generated alongside the VVK and whose shards are held by the quorum administrators. The encrypted shards are delivered to the organization's sovereign environment (its TideCloak instance). Reconstruction occurs exclusively within the organization's boundary, not within the ORK network. Simultaneously, the Fabric executes cryptographic purging: all shards, metadata, and associations related to the VVK are deleted, verifiable via immutable logs.
Ragnarök demonstrates that "ineffable" is a security property enforced to protect the organization, not a constraint on its sovereignty. The full ceremony is specified in the Ragnarök: Account Disposal protocol.
Protocol Reference
| Lifecycle Stage | Protocol | What It Specifies |
|---|---|---|
| Generation | Account Creation / KeyGen | The Nested Shamir DKG ceremony producing fragmented CMK, VVK, or CVK shards across an ORK swarm |
| Maintenance | PRISM Password Change | Rotating the PRISM verification secret across the swarm without exposing old or new password |
| Healing | Key Healing | System-initiated detection and repair of degraded shard sets via replacement shard generation |
| Recovery | Decentralized Account Recovery | User-initiated threshold recovery via secondary factors, producing new credentials without key reconstruction |
| Disposal | Ragnarök: Account Disposal | Quorum-authorized VVK export to the organization's boundary followed by cryptographic shredding |
Further Reading
- Article 2: Ineffable Cryptography and the Cybersecurity Fabric - The four-layer architecture and authority dissolution framework that houses this lifecycle.
- Article 4: BYOiD - How the Agency Layer uses the CMK for password verification and threshold token signing.
- Article 5: Governance Without God Mode - How quorum-enforced cryptographic consent governs administrative changes, recovery authorization, and key policy.
- Article 6: Authority in Action - How VVK and CVK shards are exercised for threshold decryption, signing, and blind delegation.
- Article 9: Threat Model - Formal analysis of the 14-of-20 threshold, collusion bounds, and composite security.
References
- Hall, J. L., Hertzog, Y., et al. (2023). Manifesting Unobtainable Secrets: Threshold Elliptic Curve Key Generation using Nested Shamir Secret Sharing. arXiv:2309.00915. Presented at AustMS 2021.
- Herzberg, A., et al. (1995). Proactive Secret Sharing Or: How to Cope With Perpetual Leakage. CRYPTO '95. ResearchGate.Net
- Tide Foundation. Tide Developer Documentation.