- 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.
- 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.
- 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.
- 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.
Fig. Multisig | Source: en.bitcoinwiki.org
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.
Shamir Secret Sharing
Fig. SSS | Source: Ethos
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.