Failure Modes

The DeRec protocol defines clear threshold-based guarantees. However, real-world systems encounter operational failures. This page describes common operational failure modes and their impact on recovery.

This section is conceptual. Normative behavior is defined in the Protocol Specification.

Helper Unavailability

One or more Helpers may be offline, unreachable, or non-responsive during recovery.

Impact:

• Recovery succeeds if the number of reachable Helpers ≥ t.

• Recovery fails if reachable Helpers < t.

  This is an availability failure, not a security failure.

  The system tolerates up to n - t unavailable Helpers.

Helper Data Loss

A Helper may lose its stored share for a specific version due to storage corruption, operational error, or misconfiguration.

Impact:

• If enough other valid shares exist (≥ t), recovery succeeds.

• If total valid shares across all Helpers drop below t, recovery becomes permanently impossible.

  Mitigation:

  • Choose n and t with redundancy margin.

  • Implement verification flows.

Share Corruption

A Helper may return an invalid or corrupted share.

Impact:

• Reconstruction fails if invalid shares reduce the number of usable shares below t.

• Reconstruction succeeds if at least t valid shares are obtained.

  The protocol’s validation rules and cryptographic checks detect invalid shares.

Corrupted shares do not compromise security but may reduce availability.

Threshold Misconfiguration

Improper selection of n and t weakens either availability or security.

Examples:

• t too low → easier collusion

• t too high → fragile recovery

This is an operational risk rather than a protocol flaw.

Collusion at or above Threshold

If t or more Helpers collude and combine their shares independently of the Owner, reconstruction of the Secret becomes possible.

Impact:

• The Secret can be reconstructed directly from the colluding shares.

Security therefore relies on Helper independence.

Compromised Owner or Replica During Recovery

If any device under the Owner identity (the Owner or any paired Replica) is compromised during recovery:

• The reconstructed Secret may be exposed.

The protocol does not separate Replicas from the Owner cryptographically and does not protect against a malicious or fully compromised device under the Owner identity.

Compromised Owner or Replica Before Protection

If any device under the Owner identity is compromised before share generation:

• The Secret may already be exposed.

This scenario falls outside the protocol's threat model.

Network Failure

Network disruption during recovery may prevent communication with enough Helpers.

Impact:

• Recovery temporarily fails if reachable Helpers < t.

This does not weaken security guarantees and recovery may succeed once connectivity is restored.

Protocol Version Mismatch

Owner and Helper implementations may run incompatible protocol versions.

Impact:

• Pairing may fail.

• Protocol messages may be rejected due to validation errors.

• Recovery may be impossible between incompatible implementations.

Proper version negotiation and compatibility management are required.

Helper Refusal to Participate

A Helper may refuse to respond to recovery requests even if it still holds a share.

Impact:

• Operationally equivalent to Helper unavailability.

• Recovery succeeds only if enough other Helpers respond to satisfy the threshold.

Helper Set Change Without Reconfiguration

Helpers are removed or replaced without redistributing shares:

Impact:

• Some shares may become inaccessible.

• The effective number of available Helpers may decrease.

If the effective n becomes less than t, recovery becomes permanently impossible. Proper Helper set changes require redistributing shares and typically creating a new secret version.

Replica Synchronization Failures

Replicas extend the Owner identity across multiple devices via the Secret synchronization mechanism. The following failures are specific to that mechanism.

Stale Replica

A Replica device may hold a Secret version older than the current one — for example, if the device was offline when newer versions were published, or if it was paired before the most recent change but has not yet received the sync.

Impact:

• Reading the user-facing data from the stale Secret yields outdated information.

• Driving recovery against Helpers using snapshotted addressing may fail or return shares for an older version if the Helper roster has been rotated since the snapshot was taken.

The Replica catches up on the next Secret sync round.

Concurrent Writes from Different Replicas

Two Replicas may independently produce the same version of the Secret before either has seen the other's write — for example, due to network partitions or offline operation.

Impact:

• The Helper-side state holds both writes side-by-side, distinguished by replica_id.

• The conflict surfaces via Discovery (or via owner_replica_id on a subsequent sync between the Replicas).

• Application policy decides the winner; the protocol does not.

See Conflict resolution for the detection surfaces and the resolution flow.

Loss of a Replica Device

A Replica device may be lost, destroyed, or otherwise permanently unavailable.

Impact:

• Other devices under the Owner identity continue to operate normally — the Secret is held in full by every remaining Replica.

• The lost device's local Secret cache is unrecoverable but does not need to be: the same data lives on every other device under the identity.

• If the application wants the lost device to stop receiving syncs, it must explicitly unpair the device from the rest of the group.

Process Restart During In-Flight Flows

A process running the protocol holds short-lived in-flight state for outstanding requests — verification challenges awaiting their responses, unpair acknowledgements still pending, recovery accumulators tracking how many shares have arrived, share-distribution rounds tracking which Helpers have confirmed. This state lives in process memory while the flow is in progress.

If the process restarts between sending a request and receiving the matching response, that state is lost. Inbound responses then arrive with no in-flight entry to bind to, and the protocol safely drops them as nothing actionable. The peer side is unaffected — it has already serviced the request — only the initiator's bookkeeping is gone.

Impact:

• Verification challenges, unpair acknowledgements, and recovery sessions in flight at restart must be re-initiated by the application after the process resumes.

• Replay safety is preserved — captured responses delivered after the restart still fail to bind, because the binding state is empty rather than carrying a stale entry an attacker could match.

• The cost is availability of the specific in-flight flow, not security.