Private key management chapter review

[Bosch-0]

Reposting from #283

Meta

• Backup is part of private key management. Each scheme should cover backups using that respective scheme rather than having a separate bitcoin backups page which has a lot of overlaps with other pages in this chapter.

Rename 'Automatic cloud backup' to 'In the cloud.'

• This scheme isn't always automatic. The difference can be distinguished in the page.
• Readers would read 'Private key management' then 'In the cloud' and it would be more clear as to what this section covers.

Rename 'Manual backup' to 'Recovery phrase.'

• Remove backup for the same reason as the cloud page backup should be changed.
• Readers would read 'Private key management' then 'Recovery phrase' and it would be more clear as to what this section covers.
• Using the term Manual doesn't really make sense as other schemes are also technically manual. Key sharing (sharding) for example involves breaking up and distributing private key pieces - is this not a manual process?

Rename 'External signing device' to 'Signing devices.'

• Split this into three sections: Hardware wallets, phones, computers.
• Cover backing up of signing devices. Most likely would overlap with recovery phrase page so maybe it could just be said that it's the same process and point back to their.

Rename 'Key sharing' to 'Key sharding.'

• This page needs a re-work as it does not correctly communicate how this works. Sharding is the more appropriate term as keys are not being shared only pieces of a key are. These pieces also don't do any signing like the page says. I've started re-writing this here. The content in red is stuff that pertains more to backups rather than signing with keys. If we distinguish the two (with the bitcoin backups page) these details would be more relevant there. Though I think backup details should be included with the scheme as previously mentioned.

Combine multi-key and shared multi-key pages and just call it Multi-Key.

• They cover similar content and would make more sense to have them together. The distinction between using it yourself or in a shared party can be made within the page.
• There isn't any details on 2-of-2 multisig wallets in this chapter when many wallets use it (Muun, greenwallet being two examples). This would be relevant in this page.

[danielnordh]

Private key schemes and backups are not one and the same.

A wallet application can use one scheme (say recovery-phrase), and the user might choose between backing that phrase up in a password manager, on paper, on metal etc. An application using split keys during signing is different from a user splitting their recovery phrase for backup purposes.

That said, we can make improvements.

This chapter is written for the wallet designer, with the aim of them choosing a scheme that is well suited for their target audience. It should provide the right trade-off between convenience and risk. It's not immediately clear how to cut the naming and stay consistent, it could be done based on several criteria.

• Hot vs cold
• Automatic vs manual
• Single vs multi
• Personal vs shared

My suggestion is that each scheme is named by the defining characteristic.
Here are my thoughts and the resulting proposed actions:

Automatic cloud backup

• The automatic nature is the main feature of this scheme

Proposed action: no change

Manual backup

• I agree that manual is not exclusive to this scheme
• The page title is 'Manual backup / recovery phrase', although the navigation only says 'Manual backup'

Proposed action: Rename to 'Recovery phrase' PR #319 (Edit: closed per discussion in PR)

External signing devices

• Agree that external doesn't add much, let's noodle on what to rename (the defining factor is that the key is not on the application device), 'Hardware wallet' might be the most recognizable but is not inclusive
• Not sure that splitting it into three sections (hardware wallets, phones, computers) makes sense, but referencing the differences where relevant can be improved
• Backing up is a separate matter and we should refer to the backup page

Proposed actions:
Rename to tbd 'Signing devices' / 'External key' / 'Key on another device' / 'Hardware wallet'
Review content to improve references to specific signing devices

Thershold signatures / Key sharing

• Agree the name can be improved - 'Split key' / 'Sharded key' instead of 'Key sharing' perhaps, but 'Threshold signatures' which is included on the page heading but not in the site navigation is pretty accurate
• I think you are confusing applications that use shared keys intrinsically by design (what this page describes) and the practice of sharding for backup purposes
• What the page describes is a design that is similar to multi-sig setups, where coordination is required for signing between several parties/parts of a key setup

Proposed actions:
Consider improving name
Consider removing the whole page (if we are not comfortable recommending this) (Edit: PR to remove #397 )

Multi-key

• Agree the split between personal and shared no longer makes sense (the chapter was split like this before recent changes)

Proposed actions:
Unify the two pages into one - PR #318 (Edit: Done)
Mention 2-of-2 schemes

[Bosch-0]

Automatic cloud backup

The automatic nature is the main feature of this scheme

Proposed action: no change

The main feature is the backup being in the cloud, not it being automatic. It can be instigated in the app in some applications. It would make more sense to call this page cloud backup then explicitly state that having this automatic is the best UX but it can be done in different ways. It's also confusing to keep backup in the this page title then have bitcoin backups page. You stated at the start that key management and backups are distinct but having backup in this title says the opposite.

Proposed actions:
Rename to tbd 'Signing devices' / 'External key' / 'Key on another device' / 'Hardware wallet'
Review content to improve references to specific signing devices

External Key is a good one! +1 for that title. Maybe just mention that these external keys can live on a multitude of devices but it's essentially the same concept (HWW being the most recommended though for best UX). Three sections is probably overkill on second thought!

Agree the name can be improved - 'Split key' / 'Sharded key' instead of 'Key sharing' perhaps, but 'Threshold signatures' which is included on the page heading but not in the site navigation is pretty accurate

Split key sounds good, easy to understand, sharding sounds more technical, +1 for this.

'Threshold signatures' which is included on the page heading but not in the site navigation is pretty accurate

It isn't accurate, the fragments themselves don't do any signing so you aren't reaching a threshold on signatures like you are with multisig. Apps design the UI to make it feel like multi party signing is occurring though it isn't. This is a major security issue as the a private key exists on that device the split happens on and the one it combines on essentially turning this pseudo multisig into a hot wallet. Treating it like multisig in the UI is gives a false sense of security. There is a reason SSS isn't widely adopted.

I think you are confusing applications that use shared keys intrinsically by design (what this page describes) and the practice of sharding for backup purposes

It's the same for reasons explained above - whether splitting for backup or to be re-combined for signing in a pseudo multisig it's the same process just with a different labels attached. Backups is prob the only viable application for SSS though it's still not good, it really should never be used for signing.

What the page describes is a design that is similar to multi-sig setups, where coordination is required for signing between several parties/parts of a key setup

I think any reference to this being similar to multisig should be removed. It really isn't as no multi-party signing occurs. Saying otherwise gives a false sense of security. Not recommending this at all is probably the way to do - maybe one day if we have an Appendix of sorts we could say it's advised against and reference to it in the Appendix with the details of how it works there.

Here is some deeper dives / tools on this topic:

https://trezor.io/shamir/
https://docs.keys.casa/wealth-security-protocol/rejected-key-schemes/key-sharding-shamirs-secret-sharing
https://iancoleman.io/shamir/ (using this tool you can see no signing occurs, it just re-combines fragments into the secret).

Might not be entirely relevant for this chapter but something else that may be worth mentioning is timelocks and how they can play into private key schemes. This is probably more suited for the payments section though @johnsBeharry.

https://en.bitcoin.it/wiki/Timelock

[danielnordh]

The scheme that's described here is more like what Hexa and Zengo has implemented.
I think we agree on not really wanting to recommend this scheme to someone starting a new project.
Action: Figure out how to remove / see if any information should be salvaged elsewhere.

[Bosch-0]

SSS is mentioned as the algorithm used to achieve this on the page which isn't accurate. SSS shares can't sign and should only be mentioned in the context of backups not schemes. Hexa uses SSS for backups, not for signing.

ZenGo uses the lindell protocol and multi-party computations (MPC) to create their threshold signature scheme. It actually involves more than a single key in it's process, not parts of a single key like the page says. It seems this page is a bit of a mix of SSS and Lindell/MPC, hence why it wasn't so clear to read.

With Schnorr around the corner, threshold signatures will have no extra benefit over multisig. Not to mention threshold signature schemes are only used by ZenGo as far as I'm concerned.

Threshold signatures and SSS are both likely to fade into irrelevance - maybe both are not worth covering. Or, as threshold signatures are technically multi-key, we could add a stub to the bottom of that page saying threshold signatures are also a multi-key scheme but offer no benefits / are not widely adopted so we do not advise to use it and link to some external resources if readers are interested.

[danielnordh]

Once #397 is merged I think we can close this issue as completed.

[Bosch-0]

Yep will close, ty Daniel!