12 standards
Elliptic curve Diffie-Hellman and the protocols built on it. Two parties each combine their own private key with the other's public key and arrive at the same value, which neither of them had to transmit.
Also searched as ECDH, Diffie-Hellman, Schnorr, point multiplication.
A way for two parties to compute the same shared secret from their own private key and the other party's public key, without either private key being sent anywhere.
Open in the glossary12 standards, spread across 4 of the 12 topics.
Revealing a shared secret is only useful if the recipient can confirm it is the right one, and handing over the key that proves it defeats the point. This lets the prover demonstrate correctness without revealing anything more.
Filed under Key derivation
Shared secrets is the main subject of this one.
Revealing a shared secret is only useful if the recipient can confirm it is the right one, and handing over the key that proves it defeats the point. This lets the prover demonstrate correctness without revealing anything more.
These are about something else, and deal with shared secrets on the way.
Two parties who want to exchange private data normally have to agree on a key first, and looking after that key is where most systems go wrong. This lets an application ask a wallet to encrypt something for one specific recipient without the application ever handling a key itself.
Reusing one key for everything links all your activity together, and agreeing a fresh key for every interaction is impractical. This lets two parties generate an unlimited supply of keys for each other, where the sender can produce a key only the recipient can later unlock.
An encrypted message is only portable if the recipient can work out how to decrypt it from the message itself. This defines a self-describing container so an encrypted message can be stored or forwarded and still be opened later.
Two people who want to transact need each other's public key, and sending it over a channel someone could tamper with is a real risk. This uses a short code shared out of band to confirm the key really came from the right person.
An earlier way of revealing how two parties' keys are linked asks the recipient to take the claim on faith. This sets out plainly what a verifier cannot check for themselves, as the case for something better.
Different proof systems will be used to back up key-linkage claims, and hard-coding one of them makes the format a dead end. This defines a container that names which proof type it carries, so new ones can be added later.
A single key is a single point of failure: lose it and everything is gone, and copying it multiplies the chance of theft. This splits it into pieces where a chosen number of them rebuild it and any fewer reveal nothing.
If you want a backup copy of a wallet's secret key material held outside the wallet, there has never been a common way for different storage providers to speak the same language. Without it, a wallet app would have to hand-roll a custom recovery API for every provider, and users would end up trusting a single company with their entire recovery path. This makes it possible to spread recovery pieces across independent services that all understand the same request and response shapes.
Wallet users end up locked into one backup method forever. If your wallet was set up with a written-down word phrase, you cannot later split your backup into shares you hand to trusted people, and if it was set up with shares, you cannot get a word phrase out of it. Someone switching wallets or wanting both options at once has been stuck picking one at creation time.
Sometimes a document should stay secret while its owner is alive and active, but come out automatically if that owner goes silent, like a journalist's files or a will. Before this, whoever held the decryption key could open the file whenever they liked, or lose it, and there was no way to tie "open it now" to a believable signal that the owner had actually stopped checking in. This makes it possible to split that trust across several people and have the release depend on an on-chain pattern of activity rather than on one person's word.
Some multi-party card and shuffle games need each player to secretly scramble and later unscramble shared data using a private number only they know, in a way that works no matter what order players apply or remove their scrambling. Normal wallet features can derive keys or encrypt data, but there was no way to ask a wallet to multiply an arbitrary point someone else gave you by your own secret number without ever learning that number or exposing it to the app.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic