Decentralized Key Management Systems

• Decentralized Key Management Systems (dKMS) are architectures that distribute cryptographic key control using mechanisms like threshold secret sharing, blockchain registries, and proxy re-encryption to mitigate centralized trust risks.
• dKMS are applied in diverse domains such as PKI, messaging, encrypted storage, and device custody, enabling secure key lifecycle management without relying on a single authority.
• dKMS research illuminates practical trade-offs in performance, delegation, and recovery, offering actionable insights for designing resilient, decentralized security infrastructures.

Decentralized Key Management Systems (dKMS) are architectures in which control over cryptographic keys is not vested in a single certificate authority, key server, wallet custodian, or operational administrator. In the literature, decentralization is realized through threshold secret sharing and distributed key generation, proxy re-encryption networks, append-only key-event logs, blockchain-backed registries, witness sets, recovery-node quorums, privacy-preserving validation protocols, and hardware-isolated non-exportable shares. Across these designs, the common objective is to remove single points of failure in key generation, validation, rotation, delegation, revocation, or recovery while retaining cryptographic enforceability and, in many cases, auditability (Egorov et al., 2017, Smith, 2019, Baranski et al., 28 Feb 2025).

1. Motivation and problem setting

The motivating failure mode is concentration of trust. In the TLS ecosystem, the certificate authority’s private signing key is the key asset of the CA, and compromise of that key is a single point-of-failure with potentially disastrous consequences; this is the starting point for decentralized certificate authorities that split signing authority across multiple parties and produce signatures through secure multi-party computation without exposing the actual signing key (Jayaraman et al., 2017). More broadly, centralized PKI is described as suffering from single points of failure, trust monopolies, privacy concerns in status checking, revocation latency, and operational bottlenecks, while maintaining CAs and revocation lists is demanding in loosely connected and large systems (Herbke et al., 2024, Toorani et al., 2020).

The same critique appears outside PKI. Centralized KMS-as-a-service solutions create a trust bottleneck, and cloud-hosted key use can expose users to provider compromise or insider misuse. In decentralized storage and sharing systems, the absence of a trusted cloud operator means that encrypted data can no longer rely on a central service to mediate key release safely (Egorov et al., 2017, Li et al., 2017). In messaging and email, the problem is compounded by the absence of PKI or trusted third parties, making entity authentication and key lifecycle management difficult to automate (Sandoval et al., 2020, Sandoval et al., 2021).

This body of work suggests that dKMS is not a single protocol family but a lifecycle-oriented research area. Some systems decentralize private-key use, others decentralize public-key validation, credential status, revocation, recovery, or control provenance. The unifying theme is redistribution of trust away from any one actor that can unilaterally issue, misuse, revoke, or recover key material.

2. Trust-distribution architectures

A dominant architecture is threshold decomposition. In Federated Distributed Key Generation, each participating node $P_i$ chooses its own guardian set $\mathbb{G}_i$ of size $k$, samples a random polynomial $f_i(X)$ of degree $t-1$, defines $d_i = f_i(0)$, and publishes $E_i = d_i G$; the global public key and secret are then

$$E = \sum_{P_i \in \mathbb{D}} E_i, \qquad d = \sum_{P_i \in \mathbb{D}} d_i.$$

The protocol is explicitly two-round and replaces a single global committee with participant-chosen local trust neighborhoods (Baranski et al., 28 Feb 2025). In UC-secure Star DKG, the access structure is a $1+1$-out-of-$n$ star in which a designated service must co-sign but cannot sign alone; the construction targets non-exportable shares held inside a KeyBox and replaces classical VSS-style share opening with transcript-defined affine consistency enforced by Unique Structure Verification and Fischlin-based UC-extractable NIZKs (Sehrawat, 25 Feb 2026).

Recovery-oriented systems distribute trust differently but remain threshold-centric. Kintsugi assigns recovery power to $\mathbb{G}_i$0 recovery nodes and requires a threshold $\mathbb{G}_i$1 of them to assist in reconstructing the OPRF output needed to decrypt a shared backup; it tolerates up to $\mathbb{G}_i$2 honest-but-curious colluding recovery nodes and up to $\mathbb{G}_i$3 offline nodes in an asynchronous network model (Ma et al., 18 Jul 2025). DSKE replaces a single key server with multiple Security Hubs, each holding pre-shared random material with the clients; no single hub needs to be trusted, and confidentiality is guaranteed if the number of compromised hubs does not exceed the relevant threshold (Lo et al., 2022).

A second architecture distributes trust through verifiable histories rather than threshold shares. KERI makes self-certifying identifiers the primary root-of-trust and uses append-only chained key-event logs, witnessed key-event receipt logs, and KERI’s Agreement Algorithm for Control Establishment among witnesses. Direct mode is one-to-one, while indirect mode extends trust with witnessed receipts and threshold conditions over witness sets instead of relying on a global total-order ledger (Smith, 2019).

A third architecture uses consensus-backed registries. DBPKI removes the CA and digital certificates and registers public keys, updates, and revocations on a blockchain governed by a web-of-trust model, PBFT, and a dynamic cryptographic accumulator. VDKMS similarly combines consortium blockchain, SSI, and DIDs for Cellular V2X identity and key infrastructure (Toorani et al., 2020, Yao et al., 2023).

These architectures differ in what is decentralized: signing authority, recovery authority, validation authority, or state publication. The literature therefore treats decentralization as a property of trust allocation rather than a single implementation style.

3. Cryptographic mechanisms

Threshold secret sharing and DKG are foundational. In the MANET distributed PKI construction, standard Shamir sharing begins from

$\mathbb{G}_i$4

with shares $\mathbb{G}_i$5. The MANET-specific construction then uses symmetric bivariate polynomials $\mathbb{G}_i$6, aggregates them as

$\mathbb{G}_i$7

and defines the MANET secret as

$\mathbb{G}_i$8

with public key

$\mathbb{G}_i$9

This realizes a decentralized CA role in a network with no fixed infrastructure (Kumar et al., 2018).

Proxy re-encryption is the other major primitive family. NuCypher KMS uses local symmetric encryption for bulk data and public-key encryption for the data-encryption key: $k$0 Delegation is expressed through a re-encryption key

$k$1

so that re-encryption nodes transform encrypted DEKs without learning plaintext or the underlying symmetric key (Egorov et al., 2017). Meta-Key applies a closely related pattern in blockchain-backed storage: the owner keeps the original key $k$2, generates a recipient key $k$3, derives a transformation key $k$4, and uses the blockchain as the metadata channel while a proxy storage node transforms ciphertext from $k$5 to $k$6 (Li et al., 2017).

Password-authenticated and privacy-preserving validation mechanisms form a third cluster. PakeMail instantiates PAKE-based public-key authentication using SPAKE2 with explicit key confirmation. Alice and Bob compute blinded values

$k$7

derive a high-entropy shared key, and then MAC public-key fingerprints to bind the PAKE result to the authenticated keys (Sandoval et al., 2021). DKVE uses OPRF to hide queried usernames, OKVS to encode responder contact-key mappings without revealing labels, and SPRT to decide when enough evidence has been accumulated. Its decision boundaries are

$k$8

with sequential update

$k$9

This turns social cross-validation into a probabilistic key-validation layer with user-configurable error bounds (Song et al., 25 Jun 2026).

A fourth mechanism family uses encrypted or hardware-isolated shares rather than open threshold algebra. Tandem represents the long-term secret as

$f_i(X)$0

then derives fresh randomized shares

$f_i(X)$1

so that threshold use remains possible while the server cannot link token issuance to later anonymous use (Lueks et al., 2018). Star DKG generalizes this direction by assuming that long-term shares never leave the KeyBox boundary at all (Sehrawat, 25 Feb 2026).

4. Key lifecycle: rotation, delegation, revocation, auditing, and recovery

Rotation is treated most explicitly in KERI. An inception event establishes the initial keys, and every establishment event commits to the next key set through pre-rotation. Rotation therefore reveals a pre-committed successor key set rather than introducing arbitrary new keys post hoc, and the append-only digest chain provides end-verifiable control provenance across the entire key history (Smith, 2019).

Delegation and policy enforcement are central in server-assisted systems. CKS supports gen_key, import_key, pksign, pkdecrypt, set_policy, delegate, undelegate, audit, and delete_key. Every key has a usage policy specifying owner, permitted operation types, expiration time, and remaining operations; delegation adds per-delegatee constraints for duration and/or number of uses; and auditing records time, key identifier, operation type, input values, and output values before the cryptographic operation is executed (Kurnikov et al., 2018). NuCypher and Meta-Key extend delegation to ciphertext transformation rather than online key release, so policy is realized as the presence, expiry, or deletion of re-encryption material rather than direct possession of plaintext keys (Egorov et al., 2017, Li et al., 2017).

Revocation has several distinct realizations. In blockchain-based IoT sharing, the ledger records metadata of the form

$f_i(X)$2

where $f_i(X)$3 is a CP-ABE ciphertext encapsulating an AES-GCM key. Revocation is forward revocation via epoch rollover: instead of re-encrypting large payloads, the system rotates only the small ciphertext key and appends a new ledger record (Chiu, 5 May 2026). DBPKI treats update as revocation of the old key plus registration of the new key, committing both on-chain and updating the accumulator witness structure accordingly (Toorani et al., 2020). In credential-status management, revocation and unrevocation become part of a broader decentralized status-management layer rather than a separate certificate-side mechanism (Herbke et al., 2024).

Recovery is equally heterogeneous. Kintsugi stores a backup encrypted under a threshold OPRF output $f_i(X)$4, so the password alone is insufficient; a new device must interact with at least $f_i(X)$5 recovery nodes and reconstruct the OPRF output by Lagrange interpolation in the exponent before the backup can be decrypted (Ma et al., 18 Jul 2025). Singularity reconstructs a wallet key from a 2-of-3 shard arrangement spanning device storage, a server shard, and Torus storage, with OAuth or another third-party sign-in method acting as the user-facing recovery gate rather than a seed phrase (Vohra, 2 Jun 2025).

This lifecycle emphasis is a defining feature of dKMS research. The systems are not merely decentralized key stores; they are decentralized mechanisms for evolving authority, proving continuity, constraining use, and restoring access under controlled assumptions.

5. Representative domains and system families

Domain	Representative systems	Key-management pattern
PKI, TLS, and credential status	Decentralized CAs (Jayaraman et al., 2017); DBPKI (Toorani et al., 2020); DCSM (Herbke et al., 2024)	MPC or consensus-backed issuance, update, revocation, and status publication
Messaging and email	PAKE-based authentication and KM (Sandoval et al., 2020); PakeMail (Sandoval et al., 2021); DKVE (Song et al., 25 Jun 2026); Kintsugi (Ma et al., 18 Jul 2025)	PAKE bootstrap, privacy-preserving validation, and threshold recovery
Encrypted storage and data sharing	NuCypher KMS (Egorov et al., 2017); Meta-Key (Li et al., 2017); revocation-ready CP-ABE ledger model (Chiu, 5 May 2026)	Proxy re-encryption or ledger-published ciphertext keys
Ad hoc, MANET, and vehicular networks	Distributed PKI for MANETs (Kumar et al., 2018); HT-RCF (Murugeshwari et al., 2023); VDKMS (Yao et al., 2023)	Distributed CA role, clustered rekeying, or consortium-blockchain identity
Wallets and device-centric custody	Star DKG (Sehrawat, 25 Feb 2026); Singularity (Vohra, 2 Jun 2025); Tandem (Lueks et al., 2018)	Non-exportable shares, sharded recovery, or privacy-preserving server-assisted threshold use
Symmetric group key establishment	DSKE (Lo et al., 2022)	Pre-shared randomness with threshold reconstruction over Security Hubs

The domain diversity is notable. Some designs prioritize infrastructure-less operation and low resource use, as in MANETs, where the CA role is decentralized across nodes and paired with ECC-DH and TEA (Kumar et al., 2018). Others prioritize privacy-preserving identity and authorization, as in VDKMS, where DIDs, verifiable credentials, and consortium blockchain form the key-management substrate for Cellular V2X (Yao et al., 2023). Storage-centric systems make the blockchain or ambient network the publication layer for encrypted metadata rather than the place where keys are released in plaintext (Li et al., 2017, Chiu, 5 May 2026).

A plausible implication is that dKMS has evolved into a cross-domain systems concept rather than a niche cryptographic construction. The same research vocabulary now spans CA replacement, key transparency reduction, encrypted storage delegation, threshold wallets, secure messaging, and resource-constrained networking.

6. Performance, trade-offs, and contested boundaries

Practical performance varies widely across architectures. CKS reports approximately 6,000 signature operations per second on a single desktop PC, with 10,000 secp256r1 signatures taking 1,667 ms on average; GnuPG signing latency excluding network delay is about 15 ms, compared with 1,282 ms using a smart card (Kurnikov et al., 2018). DSKE demonstrates secret-sharing one-time-pad encryption with a data rate above 50 Mbit/s and a latency below 70 ms in an AWS-based proof-of-principle VPN (Lo et al., 2022). FDKG reports, for a setting of 100 parties, a 50% participation rate, 80% retention, and 40 guardians, 332.7 kB for the distribution phase and 416.56 kB for reconstruction, while Groth16 client-side proving took about 5 s in the distribution phase and ranged from 0.619 s up to 29.619 s in the reconstruction phase (Baranski et al., 28 Feb 2025). In blockchain-based IoT sharing, CP-ABE encryption dominates store latency at approximately 186 ms for a $f_i(X)$6 mixed-Boolean policy, whereas ledger and storage operations remain around 1–2 ms (Chiu, 5 May 2026). DKVE confirms feasibility for background operation rather than interactive latency: a single cross-validation query took 9.36 seconds, estimated average key validation on facebook with five-way parallelism was 38.55 seconds, and the protocol can detect MitM attacks with exceeding 97% for strong-to-moderate-tie networks while reducing KT query frequency by two orders of magnitude (Song et al., 25 Jun 2026).

The literature also disputes what should count as “decentralized.” CKS is explicitly centralized in trust and operation even though it is informative for policy enforcement, delegation, and auditability (Kurnikov et al., 2018). HT-RCF is described as partially decentralized because group-manager selection is local but the KDC remains central to key generation and distribution (Murugeshwari et al., 2023). Singularity is best characterized as a hybrid decentralized key management system rather than a fully trustless one, since recovery depends on Singularity-operated infrastructure, third-party OAuth identity providers, and the Torus network (Vohra, 2 Jun 2025). DKVE is explicitly not a full dKMS solution but a complementary key-validation mechanism (Song et al., 25 Jun 2026).

Several limitations recur across the corpus. Blockchain improves transparency and trust distribution but is also described as a bottleneck for parallel computation and as inefficient for heavy cryptographic computation (Herbke et al., 2024). PBFT-based registry designs gain clear fault thresholds but inherit quadratic communication costs and threshold-efficiency trade-offs (Toorani et al., 2020). Some lightweight MANET constructions acknowledge known cryptanalytic issues in TEA and do not provide formal security proofs (Kumar et al., 2018). Meta-Key’s collusion-resistance claim depends on anonymity and ciphertext-location hiding rather than solely on the underlying PRE scheme (Li et al., 2017). Star DKG, by contrast, shows that hardware-enforced non-exportability can simplify confidentiality assumptions but shifts the burden to transcript consistency and straight-line extraction (Sehrawat, 25 Feb 2026).

Taken together, these works indicate that dKMS does not converge on a single “best” architecture. The field instead partitions according to adversary model, deployment substrate, and which aspect of key control must be decentralized: issuance, usage, validation, status, delegation, or recovery. This suggests that future dKMS research will continue to be plural rather than uniform, with different trust-distribution mechanisms optimized for different operational regimes.