September 26, 2019
Securing Your Keys: Multi-Sig Vs Shamir Secret Sharing
Cryptocurrencies work on the basic cryptographic principle of public-key and private key pairs that enables people to accept and send transactions. Public-keys can be thought of like a username of the email-id, available for everyone to see and send cryptocurrency. Whereas, private-keys are known only by the user (kind of like a password) and help the user to authorize the transaction. But when it comes to recovery, unlike passwords, private keys cannot be regenerated to regain access to the funds/accounts.
The drawback of keeping any sensitive information like private keys securely is the data security problem:
Comparing the Bitcoin blockchain to the banking system, it points us to two major differences. Firstly, the transactions are reversible in the banking system and the banks maintain the KYC/AML of the customers. So if a hacker manages to hack your account and transfer funds into his own account, the banks will be aware of the transactions. Since they have the control of the database, the transaction can be reversed and the hacker can be tracked down to take action against him. But in a Blockchain based network like Bitcoin, since there is no central authority and no KYC/AML of the users, the transactions are irreversible and there is no mapping between the real identity and the pseudo-anonymous identity on the Blockchain. Hence if a hacker gets access to your Blockchain account, the funds will be gone forever and there is no way to recover them back ever again.
DATA LOSS: Losing access to data one should have had access to.
DATA THEFT: Other people getting access to data they shouldn’t have had access to.
Let’s assume that you have to guard something valuable like the recipe of coke. You only have one copy with you. You may choose to safeguard the recipe in any of the following ways mentioned below.
  1. Taking the recipe and securing it through encryption. This method seems an obvious way to secure it, but conversely, it just shifts the attack vector from the recipe to the encryption key.
  2. Taking the recipe and storing it securely in a bank vault. This approach is inherently based on the fact that bank vaults are perceived to be very safe. But what happens in the case the vault gets destroyed due to any reason like natural calamity? You lose the recipe, and this becomes a problem since you only had one copy of the recipe. What happens in the case someone breaks into the vault and empties every locker? In such a case, not only did you lose the only copy of the recipe, someone else may have the recipe and figure out its true value. Furthermore, the recipe was so complex that you don’t remember it exactly. This approach does not solve both data loss problem and data theft problem.
  3. Deciding to make more copies of the recipe and then storing them at different vaults around the world. Now in case if any of the vaults are broken in, you still have your recipe and hence have mitigated the risk of data loss (losing the recipe in this case) due to a single point of failure. Although you still have access to the original recipe, there is someone out there who also has an exact copy of the said recipe and that person can use the recipe without your permission which is a major downside. Hence, this approach does not solve the data theft problem.
  4. Deciding to break the complex recipe in different parts and storing different parts at different locations. Now if something happens to any one of the vaults, you will only lose part of the recipe but have the rest. The downside of such an approach is that the recipe is useless in parts and only holds value as a whole. And it would be very difficult for you to replicate the missing part and thus make the recipe whole again. Hence, this approach does not solve the data loss problem.
Something similar could be argued for Blockchain private keys as well which have a single point of failure. For a more nuanced explanation, it is recommended to go through the blog where we compare a centralized architecture with a decentralized one.

Multi-Sig

Fig. Multisig | Source: en.bitcoinwiki.org

To overcome this, Bitcoin developers implemented multi-signature or multi-sig, as it is commonly known. The intuition behind the implementation of multi-sig can be understood by taking a safety-deposit box at a bank as an example. To open the box, we would need 2 keys; one from the customer and another from the bank. Similarly, using multi-sig, a person can ensure that transactions can take place only when approved by the minimum number of people that are already assigned to the keys.
Although multi-sig is very secure in its approach, there are drawbacks to it.

  • There is no standard implementation for multi-sig for different Blockchains that support it. There are different implementations done by various organizations, some of them even close-sourced. Additionally, there are risks involved with on-chain protocol changes which should ideally remain unchanged.

  • In a multi-party multi-sig setup, there is a loss of privacy around funds amongst its various co-signers. So if a user has a third-party multi-sig co-signer, they can easily track the funds which paint a target on the fund’s owners.

  • There is support for multi-sig by only certain number of Blockchains currently. Multi-sig is not a universal solution and needs to be implemented for every Blockchain separately which reduces standardization. Additionally, they cannot be used for securing other digital assets like the SSH keys in a similar way.

  • There are higher costs associated with a multi-sig transaction as compared to a transaction done through a single key.

  • There is a limit to the number of co-signers that are possible in a multi-sig setup.

  • It is much more complex to change schemes. For example, if you are using a 3 of 5 multi-sig setup and one of the private keys get compromised, you have to generate a new multi-sig address with a new private key and uncompromised private keys, fetch at least 3 out of 5 devices, make a transaction to send it to the new multi-sig address and then keep them again in remote locations.

A major alternative proposed for multi-signatures is the Shamir Secret Sharing Scheme.

Shamir Secret Sharing

Fig. SSS | Source: Ethos

Shamir Secret Sharing (SSS) allows us to split a secret into n parts such that with any m-out-of-n pieces you can reconstruct the original secret, but with only m-1 pieces, no information is exposed about the secret. This allows the user to set up a safety threshold of ‘m’ number of pieces required. The original secret is decoded by the owners after reaching threshold shares using Lagrange polynomial. Method-wise it is very similar to Multi-sig, but SSS is carried out off-chain whereas Multi-sig is completely implemented on-chain. In multi-sig, different private keys contribute towards generating a multi-sig address, whereas, in SSS, a single private key is sharded into multiple shares. To balance between accessibility and security, SSS is more preferred for individuals whereas multi-sig is preferred more for enterprises.
There are some advantages of SSS which makes it superior to multi-sig:

  • Since the computation is done off-chain, hierarchical SSS can be implemented where SSS is applied on a share itself. This enables multi-dimensional access control which is not possible in multi-sig. Due to an off-chain implementation, there is no risk of on-chain protocol changes.

  • Since SSS can be applied to any sensitive information, unlike multi-sig, standardized implementation is possible for securing any sensitive information which is not just limited to Blockchain private keys, server root keys, PGP/GPG certificates, etc.

  • Unlike multi-sig, SSS is Blockchain agnostic. The BIP39 seed phrase protection using SSS solved a single point of failure with private keys and allows securing any Blockchain private keys.

  • There is no loss of privacy if the co-signers do not know the public key in SSS.

  • Since the transaction is still carried out by a single private key, the transaction costs are comparatively lower.

  • There is no practical limit to the number of shares that can be generated using SSS.

  • It is comparatively far simpler to change schemes when using SSS. For example, if you are using a 3 out of 5 SSS setup and one of the shares get compromised, you just have to generate new shares of the private key and then keep them again in remote locations. No need to make any transactions.

At Cypherock, SSS is used in Cypherock X1 to create cryptographic shares to ensure that the recovery phase of a wallet is split among different tamper-proof devices to have an effective and fail-safe mechanism for wallet recovery. It intends to solve the Blockchain wallet recovery and inheritance problem with cryptocurrencies and wants users to have the same peace of mind and confidence in holding their own Crypto that they have with their fiat money in the banks.

Sign up for early beta today @ Cypherock.com

Connect with us:

Twitter : twitter.com/CypherockWallet

Telegram: t.me/cypherock