Welcome to SSS32 Discussions!

[roconnor-blockstream]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions about SSS32.
• Share ideas.
• Engage with other community members.

[BenWestgate]

I wrote a comment to someone asking for use cases when public key derivation and signatures are not easy by hand.

Here are 4 current use cases:

1.) validating the integrity of cold storage seeds/shares without electronics.
2.) know your shares used real randomness and won't leak the seed.
3.) generating replacements for lost shares without electronics.
4.) generating a new set of shares after some are stolen without sweeping funds to a new seed or needing electronics.
5.) creating a multi-seed backup for up to T airgapped electronic devices using one set of shares by interpolating between each airgapped device's seed with this paper computer.

The advantage is minimizing the "touch points" between your secret and electronic computers over the lifetime of the backup.

[BenWestgate]

Technically the wallet should only store the master xprv which can't be reversed into the seed or share. But there is the risk of the HWW being compromised such that the seed/share entered is stored and/or leaked.

In that case a compromised device would count as a compromised share and you could not enter more than threshold k shares/secrets into compromised devices without compromising the whole backup.

So a paper one-way function still has a good use case when more than k wallets are needed.

[apoelstra]

Technically the wallet should only store the master xprv which can't be reversed into the seed or share

This is a really interesting observation. Given this, I think the security model might actually be reasonable .... though unfortunately I think it's a bit too complicated to be usable. A danger with all this volvelle stuff is that you have only so much complexity before your scheme is unusable by anybody but you (no matter how detailed the instructions in your book-length estate-planning document are). And complexity counts even when it's only "abstract" complexity about the security model etc.

Also, given @ganrama's progress in the other thread, I'm optimistic that we'll be able to hand-compute chacha20, or a variant of it, to solve this usecase without needing to make assumptions about what HWWs are storing and leaking.

[ganrama]

Very interesting indeed. Specifically, from BIP39:

To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).

Are we sure that hardware/software wallets generally discard the seed phrase? (as in, "This is the overwhelming standard behavior" vs "Some do, some don't")

I think it's worth considering, given that SSSS derivation is about 1 hour with checksumming, while tweaked chacha20 will be around 5 hours, with double-checking but no checksum. That's a trade-off where you gain time by delegating the derivation security to the wallet, but it's much better than we thought because at least, if the wallet does that well, then it's not possible to weaken the k-of-n scheme after the fact.

For the inheritance case, ideally one would print a copy of the secretcodex32 and that would suffice (assuming access to the shares). Proposing two possible derivation schemes in production would be a source of confusion. It's better to think this through and propose something straightforward, generic, and long-lasting to the end-user.

[BenWestgate]

Are we sure that hardware/software wallets generally discard the seed phrase? (as in, "This is the overwhelming standard behavior" vs "Some do, some don't")

I think it's worth considering, given that SSSS derivation is about 1 hour with checksumming, while tweaked chacha20 will be around 5 hours, with double-checking but no checksum. That's a trade-off where you gain time by delegating the derivation security to the wallet, but it's much better than we thought because at least, if the wallet does that well, then it's not possible to weaken the k-of-n scheme after the fact.

My research results:

This seems to be overwhelming standard behavior for cold storage wallets.

Ledger, Trezor, Cold Card, Electrum, Mycellium, Bitcoin Core (descriptor wallets) cannot recover a lost seed even with the wallet and PIN/passphrase.

On the other hand:
Blockstream Green stores recovery phrases both for new and recovered wallets.

Since there aren't codex32-enabled wallets yet, it can be made part of the wallet recovery spec to never write the seed, codex32 secret or codex32 shares to non-volatile storage and to wipe them from memory after a wallet is restored.

[ganrama]

Cool, that's good to know most wallets respect that. Actually it make sense security-wise. Why a wallet would not do that?

Since there aren't codex32-enabled wallets yet, it can be made part of the wallet recovery spec to never write the seed, codex32 secret or codex32 shares to non-volatile storage and to wipe them from memory after a wallet is restored.

I think that would be good. Also when even while using a paper hash function: that function will have the minimum required security margin so we don't need to trust the device; but then a genuine device can still add a second layer of hashing for the cost of a mere second.

However, now that I thought about it, this solution can't be "the" standard one because it requires the user to think deep about security considerations, attack model, and proper execution. I think that's more like a power user solution than a one-size-fit-all thing, right?

[BenWestgate]

Cool, that's good to know most wallets respect that. Actually it make sense security-wise. Why a wallet would not do that?

For daily spending wallets from Bitcoin Design: Daily Spending Wallet > First use:

"...wallet prompts the user to make a backup during their first use. However, they are given the option to opt-out at this point. Many users may skip the backup during their first use. This is fine, as they may simply want to try out the wallet and see if it has the features they want before fully committing to using it.

However, once they have received funds for the first time, they certainly have an incentive to perform a backup at that point. This wallet reminds the user to make their backup once they have received funds."

Bitcoin Desgin: Daily spending wallet > backup and recovery > when to talk about backup

In order to offer an opt-out option such wallets MUST store the seed. They would NOT have to store the seed when it is restored, but Blockstream Green does, perhaps to make a consistent user experience between new wallets and restored wallets, or to allow creating extra paper backups without access to the recovery phrase.

However, now that I thought about it, this solution can't be "the" standard one because it requires the user to think deep about security considerations, attack model, and proper execution. I think that's more like a power user solution than a one-size-fit-all thing, right?

A paper secure hash function is more tolerant of compromised wallets since the codex32 backup does not lose its confidentiality no matter how many derived keys evil wallets are fed. It's also more flexible if a share is stolen, the shares could be revoked and rotated without sweeping funds to restore the original threshold of security. The downside is no error detection for hashing with paper.

Using share indexes 's', 't', 'u', etc as additional bip32 seeds for wallets is only secure while less than k "seeds" have been imported to compromised wallets. Additionally, each compromised "seed" effectively reduces the security threshold of the shares by 1. On news of a compromised share, shares can only be rotated if less than k "seeds" were imported, otherwise funds must be swept to new seeds from a new codex32 backup. The upside is deriving a new share is faster and has error detection.

The paper hash function has superior security but that should be weighed against practical concerns like additional time and chance of error when picking "the" standard solution.

If vast majority of users doing paper computations need k minus 1 or less bip32 wallets from their codex32 backup or may lack the time and accuracy to use the hash safely, then using unused shares is better practically.

If most codex32 wallets are generated electronically, then the hash should be used, giving the cool property that the derived key can later be restored (but without any error detection) entirely by hand.

[ganrama]

If vast majority of users doing paper computations need k minus 1 or less bip32 wallets from their codex32 backup or may lack the time and accuracy to use the hash safely, then using unused shares is better practically.

Agreed. But considering the 2-of-3 case, then k-1 = 1, which take us back the secret share S scenario. With 3-of-5 that gives use S and T, and so on. Let's compare the effort of deriving two sub-keys from a 2-of-3, vs. creating a new 3-of-5 with two secrets.

• Random shares: k * 2 * 221 operations
• Deriving a share : k * 45 + 221 operations
• Hashing a secret : 2 * 1344 operations (hashing twice, for error verification)

Deriving two keys: 5687 operations

• 1 derivations (S) = 311 ops (2 * 45 + 221)
• 2 hashes = 5376 ops (2 * 2 * 1344)

3-of-5, 2 secrets: 2750 operations

• 3 random shares = 1326 ops (3 * 2 * 221)
• 4 derivations (D, E, S, T) = 1424 ops (4 * (3 * 45 + 221))

We can see that deriving takes about twice as long per secret. This is not factoring the time that goes into shares management; Now it may sound silly, but even a casual user may want to create more than a couple wallet over a decade and in case 2 you get 5 new shares every time. Etching 5 metal plates takes time.

In term of time spent, I think a casual user will be around 500ops/hour. After spending a few hours with this, she might approach 1000ops/hour.

[ganrama]

It turns out that hardware wallets don't erase the BIP39 mnemonic phrase. From the ledger recover whitepaper:

To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).

This seed can be later used to generate deterministic wallets using BIP-0032 or similar methods.

In Ledger Recover, what gets encrypted then split using Pedersen Shamir Secret Sharing is the initial entropy itself. When restoring the seed, the BIP39 algorithm will be applied to the recombined entropy to restore the seed of the use

This is not specific to Ledger: any hardware wallet that offers the option to change the optional BIP39 passphrase (25th word) have to keep the mnemonic phrase to do so. I think that's pretty much all hardware wallets.

Also from BIP39:

A user may decide to protect their mnemonic with a passphrase. If a passphrase is not present, an empty string "" is used instead.

To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).