Shamir’s Secret Sharing or MultiSig? (with update)

Hexa’s security scheme tries to combines the two in a new way. Let us understand the benefits and the challenges

Shamir’s Secret Sharing

This scheme, shortened as SSS, is used to secure a secret in a distributed way. The secret is split into multiple parts, called shares. A minimum quorum of these shares is needed to reconstruct the original secret. As an example, a 2-of-3 scheme or a 3-of-5 scheme. In the context of wallet backups, a mnemonic seed can be split into SSS shares such that these ‘Recovery Keys’ are kept in different locations or with different contacts. When you want to recover the wallet, you bring together the minimum number of Recovery Keys needed that regenerate the mnemonic seed.

This backup scheme on its own is excellent for resiliency. Even if you lose some of the shares, you can recreate the wallet with the others. It is also an off-chain scheme, as there is no on-chain transaction needed or fingerprint left when you are backing up or restoring the wallet. This also allows for flexibility in the backup scheme. For example, users can change their backup scheme from a 1-of-1 to a 2-of-3 to a 3-of-5 as they use the wallet more. All this without any on-chain impact. This also does not impact how they sign their transactions as it involves only one seed or one master private key.

However, there is a problem. Creation of these shares (Recovery Keys) during backup and combining them during recovery happens on a single device. So if that device is compromised in any way, the whole mnemonic will be exposed.

MultiSig Based Backup

A MultiSig based backup has the same resiliency properties as SSS, but these rules are enforced with an on-chain script. The scheme involves multiple mnemonic seeds. One of the benefits of this approach is that the signing devices (that produce the separate mnemonics) can create and sign the script independently without any single device being exposed to all parts at any point in time.

One of the issues with this approach is that the user will need the same number of signers even when they want to send a simple transaction, as they would need for recovery. It is also very complex, if at all possible, for the user to move from a specific backup scheme to another without doing on-chain transactions and, in the process mixing up the UTXOs, which has its privacy implications. So if a user goes from 2-of-3 MultiSig to a 3-of-5 MultiSig, they will have to send all the bitcoin to the new script. This will mean that they will mix all the UTXOs, which will be a massive privacy leak.

Comparison

Here we try to compare the two scheme for their security parameters and guarantees. While both offer resiliency in case of loss and no single point of failure/ attack in case of theft, there are other tradeoffs in using both these schemes.

Using Both

What about using both? How, you ask? The key idea here is to separate the backup need of the wallet (ability to restore the wallet) with the signing need of the wallet (ability to send transactions). These can be achieved using the same mechanism (in the case of MultiSig), but they are fundamentally different needs. Backups are needed significantly less frequently, while transaction signing is needed more frequently. The backup needs to have more resilience as you use it less often, while transaction signing has its resiliency in the form of the backup itself. If you cannot sign a transaction because you lost your wallet, you can restore it.

SSS is an off-chain scheme; it can be used to shard the backup while MultiSig can fulfil the needs of transaction security. However, how do you back up the mnemonic for two different private keys? Does that mean the user will have to manage two backup schemes? Else we will get back to the same problem where a single device, if compromised, can be a security hole for the wallet.

The digram here tries to depict the solution. The magic ingredient here is to use another device to generate the secondary mnemonic and send the shards of that mnemonic directly to the backup without it ever touching the primary device. So even if any one of the two devices is compromised, the user cannot steal funds from the MultiSig account. This is the technology behind Hexa’s Savings Account.

The Result

A backup system that:

1. Is upgradable from Level 1 ( 1-of-1) to Level 2 (2-of-3) to Level 3 (3-of-5)
2. Without doing any on-chain transaction of moving all UTXOs from one script to another (no fee)
3. No UTXO mixing as you do not need to lump all the UTXOs together to send to the new script
4. Initial entropy (mnemonic) not generated from a single device during wallet/ account creation
5. The restore process does not need both mnemonics to be brought together as you only need the xPub to generate the MultiSig account, while the signing can happen on separate devices

Challenges

Most system improvements come with their tradeoffs, and we would just be hiding facts if we did not spell that out.

The first is a usability issue. The scheme relies on the user having two devices. Also, the user needs to scan an additional Approval Key from the second device when needed. This is, however, good for security, as separate entropy generated from the same device will have its own demerits.

The second is that of standard practices in this space. Until a scheme like this is not more commonplace, the code behind it will have to be more thoroughly reviewed and tested. This is why the source code is open for public review, and the team spends a lot of time testing it out.

Please take the app for a spin by searching ‘Bitcoin Hexa Wallet’ on the app stores and review the code here

Update (10 June 2022)

The challenge of adoption that this scheme faces around support with other devices and Hardware Wallets/ Signers remains a big one. What we have learned is that being open source is not enough for getting the trust of the user. Being interoperable with other trusted devices is equally or more important.

Also with the introduction of Taproot and BIP 85, multiSig or muSig has improved its extensibility and privacy aspects. A way more standard and trusted approach it seems.