The famous saying that “two can keep a secret if one of them is dead” begs an interesting question: Is a secret truly a secret if two or more parties know it? According to Google (which sources its definitions to Oxford Languages), a secret is “not known or seen or not meant to be known or seen by others.” So, once a secret is known to others, what is it then? Is it still a secret? In digital security circles, such a secret is known as a “shared secret”; a piece of information that is shared among two or more parties with an implicit or explicit agreement that the information stays private and confidential to the involved parties and oftentimes, to the context in which the information was shared. For example, a doctor-patient conversation through a healthcare portal.
One reason cybersecurity experts are obsessed with the idea of shared secrets is because of their prevalence in most if not all digital interactions. For example, given how the data we send and receive across the web (from our browsers and mobile apps) is presumed confidential, it gets encrypted with the help of the internet’s Transport Layer Security (TLS) protocol. A secret key that is ultimately known to both the sender and the receiver is used to scramble and descramble transmissions between the two. Like a secret decoder ring, that key – known as a symmetrical key – is a secret that the client shared with the web server before the two could securely send and receive information to and from each other.
One obvious question is: “How is it possible for the client to transmit such an important shared secret across a public network without also making it discoverable to malicious actors?” The scrambled information could be at risk if a malicious actor came into possession of the secret key that’s needed to descramble it.
Similar to how some payload of information (eg: an airline reservation) must be encrypted prior to transmission from a web server to a web browser, the browser needs a way to securely share the symmetrical key – a decoder ring that’s common to both parties – with the server. This part of the conversation relies on an asymmetrical key – a type of key that’s commonly associated with public key cryptography. In the case of public key cryptography, the web server possesses a true secret – one that conforms to the “not known to others” part of the aforementioned Google definition. This secret, known as the private key (because it’s private to the server), is the only key that can decrypt messages that have been encrypted using something that is most definitely not a secret; a specific public key that matches the server’s secret private key. These two sibling keys are known as a “key pair.”
In a nutshell (there’s more to it), after the client says to the server “Hey, let’s talk,” the server says “OK, I’m sending you a public key that you can use to encrypt the secret symmetrical key – the shared secret – that we’ll use to securely send some data back and forth to each other.” Using the server’s public key, the client encrypts a symmetric key and sends the scrambled version back to the server. The server receives the shared secret in encrypted form and uses the matching private key (the one that only the server possesses) to descramble it. Now that both the client and server have a shared secret between them — the symmetric key – they can use it to securely transmit and receive data to and from each other.
TLS is an Internet Engineering Task Force (IETF) standard that, in addition to the web, supports other Internet applications such as email, voice-over-IP, and instant messaging. The workflow is complicated but also offers some sense of how computer scientists have obsessed over the idea of shared secrets.
Fortunately, as security mechanisms go, TLS negotiations of shared secrets are ones that automagically take place behind the scenes as we go through our daily digital lives. However, there’s another category of digital secrets whose management requires end user attention; our digital credentials.
When asked, most people will answer that the passwords to their many online accounts are only known to them (when passwords are indeed the main means of authentication). In other words, they are not believed to be shared secrets. But if you want to see a sudden look of confusion, follow-up the first question up with a second one; If your password to some online service hasn’t been shared with that service, then how can it authenticate your credentials during a login attempt?
Apart from the relatively recent appearance of the passkey standard (a standard that also relies on public key cryptography but is not yet widely supported), the majority of online credentials in use today involve shared secrets. It is our hope that when we establish or change our passwords for the online services we use, the actual passwords will be stored in encrypted form. But from one service to the next, it is impossible to know the degree to which this best practice is in use. The secret is therefore considered a shared one until, as the saying goes, the service provider is dead. As long as the service provider is operational, the secrets that have been shared are assumed to be at risk.
Additionally, for those users who rely on password managers, their secret credentials are likely to have been shared to a central online infrastructure that’s operated by the provider of their password manager. In the same way that Google’s password manager relies on Google Cloud as the conduit through which passwords are synchronized across an end-user’s various devices, Apple does the same with iCloud and the same is true for many other password managers and their dedicated clouds. Some password managers make allowances for users and organizations to substitute their own central resource in place of the default conduit.
As described in this DeRec Alliance post that delves into the pros and cons of centralized vs decentralized technologies, while there may be some benefits to the protection of passwords, blockchain keys, and other important secrets by way of centralized infrastructure and governance, such centralized approaches have historically (and painfully) revealed themselves to have their achilles heels.
When shared secrets are synchronized with the help of such centralized clouds, there is undoubtedly a measure of fault tolerance against the catastrophic loss of those secrets (one of the biggest concerns of end users). However, in leveraging the benefit of that fault tolerance, end users are also accepting the risk associated with centralizing their shared secrets behind a single and often targeted attack surface.
According to Dr. Leemon Baird, the inventor of the decentralized Hashgraph protocol and co-founder of the Hashgraph-based Hedera public distributed ledger, the risks associated with centralized password management infrastructures are less about whether external malicious actors might gain access to the actual passwords and other secrets. That information is likely to be encrypted with methods that are resistant to brute force attacks, even with access to quantum computing resources.
“It’s also about the chance that a disruption to the central service could interfere with the end-user’s access to their secrets,” said Dr. Baird. “For example, what if an attack disables the central service at the same time that one or more users need access to that service in order to synchronize their secrets to a phone or computer? Or what happens when the user’s annual payment for the service doesn’t go through? And then there’s always the insider threat. Who works on these solutions and what might have they done to compromise your secrets?”
Scenarios like these are what inspired Dr. Baird to consider a decentralized approach – the Decentralized Recovery (DeRec) Protocol – to protect and recover passwords, blockchain keys and other important secrets. “DeRec wasn’t designed to take the place of password managers” according to Dr. Baird. “They are complementary to password managers because you still need a way to recover those secrets in the event that something goes wrong with the password manager.”
As a decentralized technology, the DeRec protocol doesn’t rely on a central machine or organization to protect or recover digital secrets. Instead, the protocol, which relies on a standard algorithm known as Shamir’s Secret Sharing (SSS), sprinkles encrypted fragments of an end-user’s secret (referred to as “shares” when relying on SSS) across a network of distributed peers called DeRec Helpers (see our FAQ: What is a DeRec Helper?) in a way that no single Helper (nor an attacker against that Helper) can either decrypt or reassemble the entire secret. Possession of a single share (see our FAQ: What is a DeRec Share?) is useless because even if a malicious actor discovers that share on a DeRec Helper’s device, neither the Helper nor the malicious actor knows who the other Helpers are (nor how many Helpers exist), in turn preventing discovery of the remaining shares by anyone other than the owner of the secrets; the DeRec Owner (see What is a DeRec Owner?).
By relying on this secure and highly decentralized architecture to protect and recover secrets, the DeRec Protocol unburdens the software developer from needlessly worrying about how to manage shared secrets because no secret is ever shared in its entirety with any other entity. In fact, the DeRec Protocol is the tech industry’s first standard, open source opportunity to finally part ways with the world’s longstanding reliance on shared secrets. To better understand how password managers and other apps can be rearchitected with the help of the DeRec Protocol, be sure to read about why the DeRec Protocol is actually complementary to password managers.