Type of Secret in SSKR

[mhofman]

The type of secret sharded by SSKR doesn't seem to be encoded anywhere. The paper suggests encoding the master seed, and all examples do just that, but other types of secret can also be encoded. Since no space is given to indicate the type of secret, an out of band method is required to capture this, which may lead to loss or incompatibilities between usages of SSKR.

For example, if I wanted to shard a specific hdkey for recovery / estate planning, but wanted to do so in a durable manner (e.g. on steel), I'd have to find a way to include in the same durable storage the content is an hdkey and not a seed. Or if I wanted to simply indicate which type of seed is encoded (bip39 vs bip32).

In a future where SSKR becomes more widely supported, different tools could parse a standardized type encoding to figure out what to do with the secret.

I'm not sure what the best approach would be to keep compactness, maybe something based on CBOR tag of the secret?

[ChristopherA]

In v0 of SSKR (there are some version bits) the secret that is sharded has some limits. It must be between 128 and 256 bits (16 or 32 bytes), and to be safe must have high entropy (i.e. be a truly random number). As these are the same requirements that we have for cryptographic seed material, its use for seeds is quite convenient. (There were some slightly more secure options to shard larger secrets and take more advantage of Shamir's strength, but the community that designed it felt that the compactness allowed of this solution was the right tradeoff.)

That being said, there are a number of things that we would like to shard that are larger than 32 bytes — in particular hd-keys which are ~64 bytes. We'd also like to shard additional metadata, in particular for account maps for multisig and lightning channels.

The solution we are working on is to use the secret not directly as a cryptocurrency seed, but instead as a symmetric encryption key. Then we can package any length of bytes and encrypt it using well-vetted IETF symmetric security standards, where to decrypt you first have to reconstruct the asymmetric secret using SSKR, then decrypt the rest of the package.

We've not released this yet as we are also investigating the ability to sign these encrypted packages, as well as some interesting ideas to allow for multiple asymmetric Diffie-Helman permits that can also decrypt the symmetric key — this allows you to not do just do SSKR to get the symmetric key to decrypt packages, but also allows you to have encrypted packages that can also be decrypted by someone who you've received a public key from or know about, and use your private key to encrypt it only for them. For this latter feature, we are inspired by the MiniLock file format https://45678.github.io/miniLock-file-format/2.html

We are making progress, but some other items on our roadmap have had greater funding from our sponsors, and to do this properly we'll need to pay for a third-party cryptographic security review (Bitmark sponsored a security review of v0). But I do hope to have this larger architecture available this fall, as well as at least a reference implementation of SSKR encrypted packages.

Also on our roadmap are alternatives to Shamir, in particular, there is a form of VSS for maybe v2 that has some real advantages in Bitcoin combined with taproot-Schnorr, as you can use it with musig.

If you'd like to see this project accelerated, we welcome participation by cryptographic engineers, or help for us get some more project sponsors so we can prioritize this work and get it security reviewed.

-- Christopher Allen