ERC-3450: Standard for Applying Shamir's to BIP-39 Mnemonics

EIPs
21

I think we may be missing one another on terminology and that may be leading us to miss on the scope of this as well.

I’m using my terms directly from BIP-39, as interoperability with BIP-39 is the primary goal here.

  1. Entropy - A set of psuedorandom bits
  2. Mnemonic - An encoding of the entropy into words (bips/bip-0039.mediawiki at master · bitcoin/bips · GitHub)
  3. Seed - Derived from the mnemonic (bips/bip-0039.mediawiki at master · bitcoin/bips · GitHub)
  4. Wallets or Keys - Derived from the seed, following any of a variety of specifications (not covered by BIP-39).

The current EIP, 3450, is only concerned with 1 and 2. Although BIP-39 has an opinion on 3, this EIP does not.

The goal is to store the entropy more securely by creating shares of it. We use mnemonics on top of the entropy to make it more user friendly.

This EIP has no opinions on how the seed is generated from the mnemonic or how wallets are derived from the seed. This is intentional. It allows us to support different wallet derivations algorithms.

I’m pretty intent on keeping the scope here to storing shares of the entropy as mnemonics. Anything around deriving wallets or signing is out of scope, in my opinion.

it would have been definitely useful if we have shares of sk direclty

If we shared the sk directly, we would need to have an opinion on how the keys are derived and we would only support a single wallet. Instead, we share the entropy and we can derive however many sks we want by any algorithm we want.

threshold signatures

This is very interesting, but, in my opinion, out of scope here. Once again, it would require the EIP to have opinions on how keys are derived.

verifiable shares

This is also very interesting, and while it doesn’t imply any opinions on how keys are derived, it does increase the scope here. Both for this EIP and for associated UIs.

I think I’m fine with assuming a trusted distributor here.

22

Hope I’m not coming out of left field here, but have you considered the downsides of key splitting?

Specifically:

  • single point of failure. single device combining keys may be exposed to malware or malicious user of device
  • poor auditability. cannot tell which shares were used to recreate the key

Thoughtfully explained by jameson lopp here Shamir's Secret Sharing Shortcomings

It seems some (Fireblocks, Zengo) are moving in the direction of Secure Multiparty Computation with threshold signatures.

23

Great article, thanks for the link!

I agree with pretty much everything the article raises.

I think Shamir’s Secret Sharing (and a number of other things, RNGs for example), suffer from a property where they are just complex enough that people are excited to implement them often for little good reason, and then they are complex enough (or have few enough reasons to invest significant time) they implement them poorly

  • Gregory Maxwell

I feel seen :sweat_smile:

The initial motivation for this ERC was a more secure way to store validator keys. Initially, the options seemed quite limited, with the eth2-cli tool only providing a mnemonic.

But, I feel like things are evolving, the options for storing validator keys are improving, and this proposal may become obsolete.

24

We’re all learning out in the open! And please don’t let my comment alone dissuade you. Hopefully we can hear from others – esp security researchers.

Also stumbled on this (didnt realize Trezor has supported Shamir since 2019)

25

I am a big lover for Shamir Secret Sharing!

I can clearly see the downside of Ian Coleman’s tool as you have mentioned above.

Just curious - what’s the disadvantages of Trezor’s implementation in your opinion?

Personally I think it’s essential for different wallets adopting the same standard (just like BIP39). Then the seed(both Shamir or non-Shamir) can be compatible.

26

Shamir’s on it’s own isn’t an issue (as a non-security researcher). However, lets say you are creating a 3 of 4. Initially all 4 shards are on a single device. Is this device connected to the internet? Can you be sure isn’t free of malware? Then you are sending 3 of the shards to “different locations.” Are you recording this on paper and physically transferring it? Or are you sending these shards over HTTP(S)? All this creates additional attack vectors on your key.

So not bad in theory, but a poor implementation can get you in trouble.

27

Primarily that it isn’t compatible with BIP-39: slips/slip-0039.md at master · satoshilabs/slips · GitHub.

I do like a lot about what SLIP-39 does. But for the use case here, where I already have a BIP-39 mnemonic and no simple way of migrating to another system (like SLIP-39), I’d like a standard focused specifically on BIP-39 mnemonics.

28

Great questions! And, I’ve been working on a UI in conjunction with this that I hope would make some of these interactions easier (though, I’ve been swamped with work and unable to give it as much time as I’d like).

The UI is intended to be used on an air-gapped computer and it would provide a prompt asking for confirmation of this. I think running Ubuntu “live” may be a good option for this as well. I am not a security research either, and am hoping for more feedback on this before calling it “secure”.

Then, after the initial mnemonic is recovered, I’d expect the user to use it on the air-gapped machine. For example, if they wanted to add another validator, they could generate the keys and save the deposit credentials to thumb drive and then upload them from a different, connected computer.

This is far from perfect though. There is still the single point of failure: the mnemonics are combined on a single computer. As well as many of the other issues raised in the link you posted.

But, it may be better than having a single mnemonic. After splitting, the shares can be located in different locations and, if one is lost, not all is lost.

29

Hm I see your point.
But I am convinced by SatoshiLab’s reasoning for “not compatible” with BIP-39

30

In that scenario, you won’t be able to use GF(256) the Field is small and discrete log is not hard. However, Discrete log is hard in GF(2^128) and GF(2^256).

Word of warning: discrete log is not-so-hard in composite fields (like GF(2^128) and GF(2^256)). If you intend to rely on a verifiable secret sharing scheme that requires that discrete log be hard (e.g. Feldman’s scheme), please choose a prime-order field.

One thing that’s nice about using a large field is that you can derive the coefficients from a hash of the secret and use this fact to verify that the secret were recovered correctly. Of course, this destroys the information theoretic security of the scheme, reducing it to the security of the hash algorithm, but you were probably relying on that anyways.

I’ve produced a research-quality implementation of the above concept in Python: GitHub - duncancmt/shamir . Particularly note this check here. No attempt was made to optimize for side-channel resistance or for speed. Under the (reasonable) assumption that the device on which the secret is reconstituted is fully trusted, it’s probably airgapped and therefore neither performance (beyond a few seconds) nor side-channel resistance is a priority. The implementation was intended to be as simple as possible to make examination and re-implementation easy. Of course, Python’s built-in bignum support and extensive standard library made this implementation much more concise than it might have been in other languages.

I chose

x^256 + x^10 + x^5 + x^2 + 1
x^224 + x^12 + x^7 + x^2 + 1
x^192 + x^15 + x^11 + x^5 + 1
x^160 + x^5 + x^3 + x^2 + 1
x^128 + x^7 + x^2 + x + 1

as the primitive polynomials for this implementation. Each of those polynomials is the one with the lowest coefficients chosen from those with the lowest Hamming weight (incidentally 5 in each case) for each order.

31

For anyone still monitoring this thread, I updated my research-quality implementation to implement Shao’s hash-based VMSS scheme. So now the recovery process can identify which shares given are invalid. Of course, now it depends on some metadata about the shares in order to perform the recovery, but under the assumption of a computationally-bounded adversary (and that SHAKE-256 isn’t broken), making this metadata public is fine.

1 Like