Key objects

The DeRec protocol is built around a small set of core objects that define how protection and recovery operate. These objects are referenced throughout the protocol flows, message schemas, and reference implementations.

Secret

The Secret is the central protocol-level object an Owner identity protects. It carries everything the Owner identity needs in order to operate the protocol: the user-facing data the application is protecting, the roster of paired Helpers (with the per-Helper shared keys), the roster of paired Replicas (with the replica-group shared key) and a version that increments whenever any of this changes.

The protocol has two views of it:

• At the primitives level, a Secret is an opaque bag of bytes — the threshold secret-sharing scheme treats it as a single value to be split into shares.

• At the protocol level, a Secret is a self-contained structured object:

{
  "secret_id": "...",
  "version":   "...",
  "secret": {
    "helpers":  [],
    "replicas": [],
    "secrets":  []
  }
}

The user-facing data lives inside content.secrets. Examples of what an application might place there:

• Wallet seed phrases

• Private signing keys

• Credentials

• Encrypted backup material

A Secret is self-contained: it carries every key, roster, and configuration value the Owner identity needs to drive the protocol. A device that holds the current Secret can act as the Owner identity in full — see Secret for the field-by-field treatment.

Helpers never receive the Secret itself — they receive shares of it. Only the Owner — and any Replica devices under the same Owner identity — hold the full Secret.

Shared Key

A Shared Key is a symmetric key that authenticates and encrypts every message exchanged on a channel between two participants. Every message — pair handshakes excepted — is sealed under a Shared Key; without it, an inbound envelope cannot be decrypted.

How a Shared Key is obtained:

• Through the pair handshake. When two participants pair for the first time, the cryptographic handshake (a hybrid ECIES + ML-KEM key agreement) yields a symmetric key both sides derive independently.

• Through inheritance, for Replicas joining an existing group. When a new Replica joins a replica group that already shares a key among itself, the new Replica derives a temporary key from its pair handshake, uses it only for the initial Secret sync, and then switches to the group's existing Shared Key (which it discovers inside the synced Secret).

How a Shared Key is used:

• Per-Helper Shared Key. Each Owner ↔ Helper channel has its own Shared Key, established at pairing. It encrypts every protocol message on that channel. Because the key lives inside the Secret's content.helpers roster, every Replica synced with the Owner also holds it, and can talk to that Helper as the Owner identity.

• Replica-group Shared Key. All Replicas in the same group communicate among themselves under a single shared key. The key lives inside the Secret's content.replicas roster. A device that holds the current Secret holds this key by construction.

A Shared Key is never sent on the wire as plaintext. It is derived independently on each side of a pair handshake, then propagated to other Replicas only through the synced Secret, which is itself transmitted under encryption.

Secret Identifier (secret_id)

Each protected Secret is assigned a Secret Identifier (secret_id). The secret_id uniquely identifies a Secret within the protocol and is fixed for the lifetime of the Owner identity. It is used to coordinate every protocol flow that touches that Secret — share storage, verification, recovery, replica synchronization.

An application may run multiple independent protocol instances within the same environment, each managing its own Secret with its own secret_id.

Secret Version (version)

The Secret's version is a monotonic counter that increments whenever content changes — for example:

• User secrets are added, removed, or rotated

• Helpers are added to or removed from the Helper Set

• Replicas are added to or removed from the replica set

• The threshold configuration changes

Every version increment triggers a synchronization round to every paired Helper (a fresh VSS share) and to every paired Replica (the full updated Secret). The (secret_id, version) pair uniquely identifies a specific protected state of the Secret.

Shares

Shares are fragments of the Secret produced by a threshold secret-sharing algorithm. If n is the total number of shares and t is the threshold, then:

• Any set of at least t shares can reconstruct the Secret.

• Any set of fewer than t shares provides no information about the Secret.

Helpers store one share for each (secret_id, version) they have been distributed.

Threshold secret sharing ensures that fewer than t shares reveal no information about the Secret — there is no separate encryption key to attack.

Committed Shares

In the DeRec protocol, shares are transmitted and stored together with cryptographic commitments that allow their correctness to be verified.

A committed share contains:

• The share itself

• A commitment to the share

• Proof material allowing validation during recovery

Committed shares enable the requester (the Owner, or any Replica acting on its behalf) to detect invalid or malicious shares during recovery.

Threshold (t)

The Threshold defines the minimum number of valid shares required to reconstruct the encryption key.

Recovery condition:

shares ≥ t

Security guarantee:

shares < t → reconstruction of K is not possible

The threshold is configured by the Owner and determines the balance between availability and resistance to collusion.

Helper Set

The Helper Set is the collection of Helpers selected by the Owner for a given protection configuration. It is defined by:

• Total number of Helpers (n)

• Threshold (t)

• Communication and pairing parameters

Changes to the Helper Set require redistributing shares and creating a new secret version.

Replica

A Replica is an additional device under the same Owner identity that holds a synchronized copy of the Secret. Replicas extend the Owner's reach across multiple devices without requiring each device to pair separately with every Helper.

Key properties:

• All Replicas share the Owner's trust boundary — see Roles.

• Every Replica receives every Secret version through synchronization.

• Once synced, any Replica can act toward the Helpers on the same footing as the Owner.

See Replicas in the Concepts chapter for the pair handshake, the synchronization mechanics, and the security implications.

Recovery Session

A Recovery Session is the protocol-governed process during which a participant (the Owner, or any Replica under the same Owner identity) retrieves shares from Helpers and reconstructs the Secret. It includes:

• Establishment of valid protocol sessions

• Share requests

• Validation of responses

• Reconstruction of the Secret from the recovered shares

Recovery succeeds only if at least t valid shares are obtained.

Protocol Messages

Protocol Messages are structured data objects exchanged between participants. They are defined using message schemas (e.g., protobuf) and encode:

• Share storage operations

• Verification flows

• Recovery requests and responses

• Secret synchronization between Replicas

• Error conditions

Structured messages ensure interoperability across independent implementations.

Object Relationship Overview

The object model ensures that the Secret is never sent to any Helper, that Helpers store only the minimal information required to enable threshold-based recovery, and that any participant under the Owner identity can drive recovery without depending on any specific device.