Protocol Lifecycle

The DeRec protocol defines a structured lifecycle describing how a Secret is protected and later recovered. This lifecycle describes how an Owner, a set of Helpers, and (optionally) one or more Replicas interact over time through protocol-defined flows. This section is conceptual and non-normative. The formal message structures and state transitions are defined in the Protocol Specification.

Phase 1: Initialization and Pairing

Before shares can be distributed, the Owner must establish a relationship with each Helper. This phase includes identity establishment, configuration exchange, and secure cryptographic communication setup according to the protocol definition.

During this phase:

• The Owner selects the Helper set.

• The recovery threshold (t) and total Helpers (n) are configured.

• Per-channel Shared Keys are derived through the pair handshake — one per Helper channel.

• Protocol version compatibility is verified.

The Owner may also pair additional devices as Replicas to extend the Owner identity across more than one device. Replica pairing uses the same cryptographic handshake plus a fingerprint cross-confirmation gate and a shared-key handover into the replica group — see Pairing replicas.

The outcome of this phase is a valid, trusted communication context between the Owner identity (Owner + any paired Replicas) and each Helper.

Phase 2: Protection (Share Distribution)

In this phase, the Owner prepares the Secret for recoverability and distributes it across the Owner identity.

Conceptually:

• The Owner splits the Secret into n shares using a threshold secret-sharing scheme.

• Each share is transmitted to its corresponding Helper.

• Helpers validate and persist their assigned share.

• In parallel, the full Secret is sent to every paired Replica so the Owner identity stays in sync across all its devices.

Helpers store only their assigned share and associated metadata. The Secret itself is never transmitted to any Helper.

Phase 3: Verification

The protocol may include verification flows that allow the Owner (or any Replica acting on its behalf) to confirm that Helpers:

• Have correctly stored the share

• Can participate in recovery

• Are reachable and operational

Verification typically uses a challenge-response mechanism that allows the requester to confirm share possession without reconstructing the Secret. Verification improves operational assurance while preserving the confidentiality of recovery material.

Phase 4: Recovery

Recovery is explicitly initiated by the Owner (or any Replica acting on its behalf) by requesting shares from Helpers and reconstructing the Secret once the threshold is satisfied.

Recovery involves:

• Establishing a valid recovery session

• Authenticating with Helpers

• Requesting stored shares

• Receiving and validating responses

• Reconstructing the Secret once at least t valid shares are obtained

Recovery succeeds only if the threshold requirement is met.

A Replica that holds a current snapshot of the Secret does not need to drive this flow — it already has the user-facing data locally. The Helper-quorum recovery path remains available as a fallback when the cached Secret is stale or absent. See Recovery transitivity for the three paths a Replica can use.

After recovery, it is recommended that the Owner runs a round of Sharing to refresh the version of the secret. This point in time is a good opportunitity to have the Owner reconfiguring the secret unparing with those Helpers that are not responsive any more or re-syncing with replicas.

Phase 5: Reconfiguration (Optional)

Over time, the Owner may:

• Add or remove Helpers

• Add or remove Replicas

• Change the recovery threshold

• Rotate recovery material

Each of these changes increments the Secret's version and produces a new snapshot, which is then redistributed — a fresh share to every paired Helper and the full updated Secret to every paired Replica. See Secret for the version-bump rule and Secret synchronization for the wire mechanics.

This phase ensures long-term flexibility without weakening threshold guarantees.

Lifecycle Properties

The protocol lifecycle ensures:

• Recovery authority is distributed across independent Helpers

• No unilateral recovery is possible from a single Helper share

• Protection, verification, and recovery occur through explicit protocol flows

• Threshold guarantees are preserved throughout configuration changes

• Every device under the Owner identity stays consistent with the current Secret state

The lifecycle model provides a structured mental model for implementers before examining the normative protocol flows.