Hacker News Reader

Comment by e79 | Hacker News Reader

While SSSS provides information theoretic security, there are a couple of security gotchas. One example is that it leaks the length of a secret unless padding is used. In practice this isn’t usually an issue, since many applications (like this one) use SSSS for sharing fixed-size symmetric keys.

A more concerning gotcha is that this scheme doesn’t produce verified shares (i.e., shares lack integrity). An adversarial or forgetful share holder can submit a bad share and within this scheme, you’d have no way of being able to prove that they did this. All any of the participants would know is that the resulting secret is wrong, whatever that means for the application (e.g., the AES key doesn’t successfully decrypt a ciphertext).

View on HN

Can't these problems be solved with another layer like signing with a pubkey where the private is thrown away after issuance? And then maybe some error correcting algorithm to avoid forgetful users?

Signing the shards was the first thing I thought of as well. This will completely thwart bad shards from being mixed into the decryption.

For those interested, there's a whole literature on "verifiable secret sharing", and they generally require some substantial cryptographic heavy lifting and provide computational guarantees

https://en.wikipedia.org/wiki/Verifiable_secret_sharing

If you have any algorithm or source at hand I would be really happy to add this!

Or even better: If you got some time spare, feel free to help out with s4 :D https://github.com/simonfrey/s4

> While SSSS provides information theoretic security, there are a couple of security gotchas. One example is that it leaks the length of a secret unless padding is used. In practice this isn’t usually an issue, since many applications (like this one) use SSSS for sharing fixed-size symmetric keys.

I also believe that also in theory, using SSSS + fixed-size symmetric keys gives you all the same security properties of SSSS and no leaking of the message length, assuming that the symmetric cipher you're using is secure. What exactly do you mean by "this isn't usually an issue" (emphasis is mine).

SSSS isn’t always used with fixed-size symmetric keys, in which case length can leak something important. But in practice it often is, since share size increases with message size and that can get unwieldy. So it isn’t usually an issue.

My point is that there is no reason why you wouldn’t used fixed-size symmetric keys which are more performant, prevent leaking message size, and have all the other security properties that you’d get if you just used SSSS.

If you're secret-sharing a symmetric key then you're dealing with computational security anyway, but you do get some notion of integrity for free. As you said, given a reconstructing set of shares you can tell whether all shares are correct, or whether they aren't (but you are not able to identify the bad share). However, if you have additional good shares (enough good shares to reconstruct), then you will be able to identify the bad shares.

You could also use digital signatures on the shares to get integrity for individual shares.

wouldn't an easy fix for verifiability be that you include a list of hashes of every valid share along with each individual key?

Would love to hear other opinions about that, but that sounds like a good idea in my opinion. But still there would be the problem that you do not know which of the shares is the wrong one, as if there is 4 shares and 2 are right, 2 wrong you don't know which ones are the right ones.

Or am I wrong here?

Reply on news.ycombinator.com