Shared secret is longer than source

[Shulyaka]

Hi,

I have noticed that when splitting a 64-byte (512 bit) key, the result is 113 bytes long. That seems wrong. Please see the 'minimal' property of sss on Wikipedia: https://en.wikipedia.org/wiki/Shamir's_Secret_Sharing#Properties

There are two issues with that:

1. Usability limitations: you cannot use applications designed for 512-bit key. That includes sss-node itself and possibly tools like https://github.com/cryptosteel/cryptosteel (not exactly this one).
2. If the actual size of the sharded secret is 512 bit, but it is stored in a 904 bit string, that might mean that the string is not random enough. That might have security implications (someone might guess that sss-node tool was used to produce it and start looking for other shares).

[dsprenkels]

I think you may find the Technical details useful.

In any case, this is intended. You can use the keyshares API to split secrets in a minimal fashion (256 bits, because most cryptographic keys are 256 bits long). You will get shares of 33 bytes (256 bits y-coordinate and 8 bits x coordinate).

The normal API splits secrets in a different way: It generates a random key and encrypts the secret with this key. This allows you to secret-share arbitrary secrets.

Usability limitations: you cannot use applications designed for 512-bit key. That includes sss-node itself and possibly tools like https://github.com/cryptosteel/cryptosteel (not exactly this one).

For this purpose, use the keyshares API. Generate a random key and use this key as the key for some kind of AEAD scheme.

If the actual size of the sharded secret is 512 bit, but it is stored in a 904 bit string, that might mean that the string is not random enough. That might have security implications (someone might guess that sss-node tool was used to produce it and start looking for other shares).

So the fact that the hybrid approuch is taken is (simplified) because the secret shared string might nog contain enough randomness to guarantee the integrity of the secret. We have to generate some (in this case 256 bits) randomness, such that an attacker cannot break the integrity requirement.

[Shulyaka]

Thank you for the response!

I think that the keyshares API is what I need. I have one more question though.

You will get shares of 33 bytes (256 bits y-coordinate and 8 bits x coordinate).

Is x coordinate randomized? Could it be just the number of the share? My goal is to get exactly the same share length as in the original secret.

[dsprenkels]

Is x coordinate randomized? Could it be just the number of the share? My goal is to get exactly the same share length as in the original secret.

No. The x coordinate is a counter and the Shamir secret sharing scheme cannot function without it. It is not possible (theoretically) to create shares that have the same size as the secret, unless the threshold is equal to the number of shares.

Also, be advised that, in the keyshares API, y must be a completely random value.

[Shulyaka]

Thank you!

[dsprenkels]

No problem!