But since neuralyzers don’t exist in real life (or do they?), managing our secrets has been one of those “damned if you do, damned if you don’t” situations. Either we share them in some way (including writing them down on paper) that theoretically protects us against the loss of those secrets or, at the risk of our own digital or financial peril, we don’t share them at all. 

Unfortunately, in the “damned if you do” column, history has proven that axiom to be true. When it comes to our passwords and blockchain credentials – two of the most important types of digital secrets we keep – the human race has been both damned if it does, and damned if it doesn’t. 

All of us have gone through the standard website registration workflow where we’re asked to supply a password with our user ID, the latter of which is frequently our email address. Regardless of whether the password is scrambled (via encryption, hashing, etc.) or not, when we share confidential information like a password with a service provider, security experts refer to that password as a “shared secret” (see What are Shared Secrets and Why are they So Tough To Manage?). For the purposes of establishing and using an account on the operator’s systems, we’re sharing a secret with that service provider. 

However, as the website Have I Been Pawned? infamously demonstrates, as long as the parties with whom we’ve shared our secrets are not dead (and their records are not destroyed), those secrets are vulnerable to discovery. Even worse is when the same secret is re-used across multiple service providers as a component of your password management strategy. Who of us is not guilty of the practice? If that secret is revealed to a malicious actor by way of compromise to one of those multiple service providers, that actor could also gain access to your other accounts (with those other service providers).

In January 2025, the risk management solution provider Upguard published its list of the 72 Biggest Data Breaches of All Time further demonstrating how risky it has been to share confidential information with supposedly trustworthy brands. Most of these and other breaches involve a common architectural feature that’s symptomatic of the risk. Whenever a single provider is a custodian of shared secrets (which is most often the case), that provider’s systems appear to malicious actors as one big juicy centralized attack surface; a single entry point through which a trove of secrets and other sensitive information can be exfiltrated.

In the “damned if you don’t” (don’t share your secrets with another party) column are the billions of dollars of cryptocurrency that are trapped for eternity in public distributed ledger accounts that are no longer accessible to the associated account holders or their families. Since 2021, the blockchain research outfit Chainalysis has estimated that roughly 20% of the Bitcoin in circulation (approximate current USD value of $400 billion) is trapped for eternity in accounts that are no longer accessible largely due to the loss of the keys associated with those accounts. And that’s just Bitcoin. Never mind Ethereum and all the other public distributed ledgers.

Unlike with service providers that might offer a centralized recovery process for lost credentials, public blockchains do not involve a central authority that can restore a lost private key. Because of their decentralized nature, If a blockchain account key and any other secrets that go with it (ie: wallet passwords or mnemonic recovery  phrases) are irrecoverably lost, so too are the balances of cryptocurrencies and other assets associated with that account. 

In the name of not sharing secrets, when cryptocurrency account holders choose to keep their account secrets to themselves (at the risk of losing access to their funds), they are said to be “self-custodying” their crypto and other blockchain-based assets (eg: non-fungible tokens). They are the custodian of their crypto much the same way they’d be the custodian of their cash if they kept all their cash under their mattress. As dangerous as it sounds, one reason to self-custody your crypto is that you might not trust a centralized party like an exchange to do it for you. In the world of traditional finance, centralized parties like banks have a long and shady history of harming customers who thought they could be trusted.

Alternatively, one of the benefits of using a centralized exchange as your custodian is that, like other centralized service providers, if you lose access to your account, there’s usually a recovery process for regaining access. But going with a centralized custodian represents a return to the “damned if you do” scenario where, once again, secrets must be shared. One needn’t look back very far to recall how the customers of FTX lost access to $8 billion after the centralized exchange went bankrupt in 2022. It wasn’t until February 2025 when, amid further controversy, some of those customers started to get some of their money back.

So, what’s the answer? What’s the middle ground between damned if you do and damned if you don’t? To some extent, the answer lies in the resulting architecture should you do the equivalent of hiding your money under your mattress. It’s still a centralized approach. You’re trusting a central provider – yourself – to protect those assets. It’s not all that different from trusting a bank or a cryptocurrency exchange. Not only is it too easy to make a terrible mistake, to malicious actors, you represent a single attack surface. If all of your money is stuffed underneath your mattress, it just takes one break-in into your residence to lose it all. The answer is to pick a different architecture. Instead of centralizing the responsibility of protecting your secrets with another party or yourself, decentralize that responsibility in a way that your secrets are neither under your sole protection nor are they shared in their entirety with any outside party.

Read What is Meant By “Decentralization” and Why It Matters to the Protection and Recovery of Secrets to gain a better understanding of the pros and cons of centralized vs. decentralized approaches

To make this decentralized architectural approach to protecting secrets and assets of all types (passwords, blockchain private keys, recovery codes for two-factor authentication, important images and documents, etc) possible, the DeRec Alliance is enabling developers to enhance their wares with the Decentralized Recovery (DeRec) Protocol. 

The DeRec Protocol is an open and 100% royalty-free protocol that can be incorporated into any application or web service and its premise is simple. It takes any secret or digital item (a file, image, etc.), splits it into encrypted pieces called “DeRec Shares” (see our FAQ: What is a DeRec Share?) that are indiscernible from one another, and distributes those Shares across a group of handpicked protection and recovery assistants known as DeRec Helpers (see our FAQ: What is a DeRec Helper?). 

A DeRec Helper can be anybody – a family member, a friend, an organization that you already do business with – that wants to help and is willing to run a DeRec Helper-enabled app or service. Helpers have no way of knowing how many other Helpers you are using or who they are. The Shares that are distributed across your Helpers are encrypted using quantum-proof cryptography. However, even if a malicious actor was able to somehow break into an encrypted share, it wouldn’t do them any good. They’d have to find at least half of the total number of Shares and break into those before the secret could be reconstructed. 

In addition to offering the protocol on open and unencumbered terms, the DeRec Alliance also makes its software development libraries available under the Apache 2.0 open source license. With these libraries, app and web service developers can freely build some or all of the DeRec Protocol capabilities into their wares. For example, whereas some developers may choose to enable their software with DeRec Helper capability, others can enable their end-users with the ability to securely split their secrets and distribute the resulting DeRec Shares to their handpicked Helpers. 

In order to drive global adoption of the DeRec standard, the DeRec Alliance is looking for new Alliance member organizations as well as developers who want to contribute to the development of DeRec software development kits across a variety of languages. Visit DeRecAlliance.org for more information on the DeRec Alliance.