What is DeRec

DeRec (Decentralized Recovery) is an open standard for protecting and recovering sensitive secrets using a threshold-based, multi-party model.

It defines how an entity can:

• Protect a secret using cryptography

• Distribute recovery material across independent parties

• Reconstruct the secret only when a defined threshold is met

• Interoperate across independent implementations

DeRec is not a product or hosted service.

It is a protocol specification and reference implementation ecosystem.

What the Standard Defines

The DeRec standard specifies:

• A protocol for coordinating protection and recovery flows between an Owner identity (one or more devices) and multiple Helpers

• A cryptographic model where the Secret itself is split into shares using a threshold secret-sharing scheme

• A structured message format (protobuf-based) for interoperability

• A role model (Owner, Helper, and Replica) that defines responsibilities and trust boundaries

The protocol governs how shares are created, transmitted, stored, verified, and recovered.

The Problem

Applications that manage high-value secrets — such as:

• Wallet seed phrases

• Private signing keys

• Enterprise signing infrastructure

• Credentials

• Encrypted backup data

All of them face a fundamental trade-off:

Approach	Failure mode
Self-custody (single device backup)	Loss results in permanent loss
Cloud backup	Custodian compromise results in catastrophic breach
Informal social recovery	Weak guarantees and no interoperability

Systems must choose between availability and security, often sacrificing one for the other.

The DeRec Approach

DeRec addresses this trade-off using a threshold-based cryptographic design.

At a high level:

1. The Secret is split into cryptographic shares using a threshold secret-sharing scheme.

2. Each share is distributed to an independent Helper.

3. Recovery succeeds only when a defined threshold of shares is retrieved and combined.

4. The original Secret is reconstructed locally by the Owner from the recovered shares.

Important properties:

• Helpers never receive the Secret itself — only one share each.

• No single Helper can reconstruct the Secret on its own.

• Shares are stored independently by multiple Helpers.

• Recovery requires coordinated threshold participation.

Security derives from mathematics, not trust in a single custodian.

An Owner identity can also extend across multiple devices via the optional replica feature — additional devices under the same Owner identity that each hold a synchronized copy of the Secret. The cryptographic guarantees above are unchanged; replicas are an availability mechanism, not a relaxation of the threshold model. See Replicas in the Concepts section for the full discussion.

Post-quantum by design

The cryptographic choices that ground DeRec are deliberately post-quantum:

• The pairing handshake between any two participants uses ML-KEM-768 (the NIST-standardised module-lattice KEM) alongside an ECIES leg. ML-KEM is the long-lived key-establishment primitive; the ECIES leg is composed defensively but is not the post-quantum anchor.

• Threshold secret sharing is information-theoretically secure: fewer than t shares yield no information about the secret, regardless of an attacker's compute budget — classical, quantum, or otherwise. There is no computational hardness assumption to break.

• Channel encryption uses AES-256-GCM under per-channel symmetric keys. Symmetric primitives at this strength remain practically secure under known quantum attacks (Grover's algorithm only halves the effective key length).

• Share-possession proofs use SHA-384 commitments. Pre-image resistance at this digest size remains practically intact under known quantum attacks.

The intent is that a DeRec Secret recorded today, captured wholesale and stored by an adversary, remains unrecoverable even if cryptographically relevant quantum computers become available later. The protocol is one of the few recovery designs that does not rely on a "store now, decrypt later" assumption being unfavourable to the attacker.

The standard does not redesign the cryptographic primitives — it composes well-known ones in a way that places every long-lived secret behind either a post-quantum primitive or an information-theoretic boundary. The Cryptography details, including the exact composition during the pairing handshake, are documented in the protocol specification.

Design Objectives

The DeRec standard is designed to make secret recovery:

• Decentralized — no single point of failure.

• Threshold-secured — recovery requires multi-party participation.

• Interoperable — multiple independent implementations can communicate.

• Auditable — cryptographic mechanisms and protocol rules are explicit and publicly reviewable.

• Extensible — protocol evolution does not depend on a single vendor.

What DeRec Is Not

To avoid confusion, DeRec is not:

• A wallet

• A storage provider

• A blockchain

• A custody service

• A proprietary SDK

It does not mandate:

• A specific hosting model

• A specific authentication scheme

• A specific user experience

DeRec defines how recovery works at the protocol level, not how applications must be built.