How many times did you face resetting your password with email or phone? For a long time, this feature was unavailable for our users. Today Waves.Exchange proudly presents decentralized threshold crypto custody! This is a disruptive technology that becomes a starting point for a stand-alone open-sourced, safe, and completely decentralized data storage project.
Just imagine, all you need to log in or sign up is your email. Our decentralized technology will take care of the rest. How is it possible?
What is crypto custody and why do we need it?
Managing secret keys is hard. They are difficult to remember, easy to lose. They can be stolen, hacked or accidentally revealed to other individuals. Loss of a secret key leads to full loss of access to the user’s account and all funds associated with it. Theft of a secret key allows the perpetrator to steal funds or make other unauthorized operations pretending to come from the account owner.
Those risks and restrictions make it really hard for users, especially new ones, to interact with blockchains and other secret-key crypto systems. It also makes it difficult for existing financial systems, mostly relying on traditional authentication techniques, to integrate with secret-key systems. Finally, independent secret management involves significant risks with regard to loss or theft.
To address these issues, many crypto custody solutions have been proposed. A custodian is a system that offers secure storage of users’ secrets, abstracting away cryptography and technical complexity of underlying secret-key systems, while providing traditional authentication and authorization interfaces, such as email, password or phone.
Centralized custody problems
Most custodians available on the market are centralized. That means there are servers checking users’ identity, databases keeping full user secrets (possibly in several copies as backups), servers using full secrets to generate digital signatures, network interaction between the components, all belonging to a single person or organization.
Centralized architecture has inherent vulnerabilities. A database with secrets can be lost or stolen. A server generating signatures can get hacked and leak secret keys used in the signing process. Spyware can be inserted to watch network traffic.
And the human factor shouldn’t be ruled out, either. It is common for perpetrators to exploit human errors or malevolent intentions for their benefits. In any centralized system, there are people — system administrators, technical staff etc. — with access to important subsystems. And even a single compromised person can render the whole system compromised.
The problems described above have the same origin: centralization. A single person, a single server, a single database — if any of them fails, the whole system fails. So, how is it possible to avoid any single point of failure? By making the system decentralized.
First, let’s formulate some requirements for an ‘ideal’ system:
No single person must be able to compromise the system.
No storage containing full secrets must exist.
A full secret key must never appear on any single server or device.
The only way to satisfy the above requirements is to somehow split one key into several parts. Each part must be kept separately, in databases and servers maintained by different people. In order to execute operations, participants have to cooperate in some way, without ever revealing their secret shares to anybody.
A naive approach would be to split the key into n parts and require that all nparticipants execute an operation. However, that means a single compromised or offline participant compromises the entire system, which breaks requirement 1 and takes us back to the single point of failure issue.
Hence, the number of cooperating participants required to execute an operation on behalf of the user must be fewer than n. Let t denote the number of participants required for executing an operation.