I had Matt's answer already, see below, but then I recognized that the group was not cc:-d, so I repeat:

It would help on the user interface to include into individual shares:

1. Number of shares needed
2. A few bytes fingerprint of the secret so shares that likely belong together can be identified.

I wonder how others weight security vs. usability in these questions.

Regards,

Tamas Blummer
http://bitsofproof.com

On Saturday, 29 March 2014, at 6:22 pm, Tamas Blummer wrote:
It might make sense to store the number of shares needed. I know it is not needed by math, but could help on user interface to say,
you need x more shares..

I intentionally omitted that information because it's a security risk. If an adversary gains control of one share and can see exactly how many more shares he needs, he may be able to plan a better attack. If he is clueless about how many shares he needs, then he may not be able to execute an attack at all because he may not know whether his information about what shares exist and where is complete.

On 29.03.2014, at 17:54, Matt Whitlock <bip@mattwhitlock.name> wrote:

On Saturday, 29 March 2014, at 9:44 am, Tamas Blummer wrote:
I used Shamir's Secret Sharing to decompose a seed for a BIP32 master key, that is I think more future relevant than a single key.
Therefore suggest to adapt the BIP for a length used there typically 16 or 32 bytes and have a magic code to indicate its use as key vs. seed.

I have expanded the BIP so that it additionally applies to BIP32 master seeds of sizes 128, 256, and 512 bits.

https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki

The most significant change versus the previous version is how the coefficients of the polynomials are constructed. Previously they were SHA-256 digests. Now they are SHA-512 digests, modulo a prime number that is selected depending on the size of the secret.