zcash
[ZIP 339] Specify a variant of SLIP39 for Zcash
Context
SLIP-0039 : Shamir's Secret-Sharing for Mnemonic Codes
Issues with deploying SLIP39 as-is
BIP 39 and SLIP39 backups are incompatible
It is impossible to convert a BIP 39 seed phrase to a SLIP39 one or vice versa.
That is in principle fixable (explanation of the technical issue), and if we want to fix it then now would be the time to do so, while SLIP39 has not been deployed for Zcash yet.
20-word SLIP39 backups produce a seed that is too small
All implementations MUST support master secrets of length 128 bits and 256 bits:
Security Padded share value length Total share length 128 bits 130 bits 200 bits = 20 words 256 bits 260 bits 330 bits = 33 words
ZIP 32 specifies (for Sapling and for Orchard):
Let $S$ be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.
The reason why we specify a $\geq 32$-byte (i.e. $\geq 256$-bit) seed is that if the seed were any shorter, it would become a bottleneck for the entropy of all keys derived from it, most of which are $256$ bits.
Zcash has an overall security goal for the entire protocol that classical attacks should require at least $2^{125}$ operations (see slide 42 of Understanding Zcash Security), and it is impossible to achieve this with $128$-bit keys, primarily due to multi-target attacks (see [Bernstein2005] and [Zaverucha2012]).
20-word SLIP backups do not result in a seed compatible with this requirement. But the solution seems pretty straightforward: only support the 33-word option for Zcash, i.e. explicitly diverge from the above "MUST" in SLIP39.
Specification
Let's use the existing reservation ZIP 339 for this. (Wallet standards are conventionally in the ZIP 3xx range.)
Possible alternative (or complementary? not sure) by a team that is implementing Multi-Factor Key Derivation Function (MFKDF) for Zcash:
MFKDF, originally published in USENIX Security, uses conventional, commonly-used authentication factors to enable trustless client-side key management, allowing for the exact UI and UX of custodial wallets in the non-custodial setting while maintaining user security and privacy. A user study published in ACM CHI showed that users significantly prefer the UX of MFKDF-based crypto wallets over existing alternatives. While the original MFKDF was just a research prototype, we are now actively developing MFKDF2, which will be a rearchitected, production-ready implementation with a handful of security improvements and new features. We're working with the Zcash Foundation to make MFKDF2 a reality and to identify wallet providers who may be interested in implementing MFKDF2 in the future.
@nuttycom wrote:
The Blockchain Commons folks have defined a seed sharding protocol that allows you to split an existing BIP39 seed into shares, for what that’s worth. I don’t know how widely adopted it is though: https://developer.blockchaincommons.com/sskr/