5 ms·
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 i
by e79 6y ago
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).
- kcolford 6y agoCan'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?
- matthewaveryusa 6y agoSigning the shards was the first thing I thought of as well. This will completely thwart bad shards from being mixed into the decryption.
- l1am0 6y agoIf 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 https://github.com/simonfrey/s4
- y7 6y agoIf 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.
- Vervious 6y agoFor 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 https://en.wikipedia.org/wiki/Verifiable_secret_sharing
- maxfan8 6y ago> 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).
- e79 6y agoSSSS 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.
- maxfan8 6y agoMy 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.
- this_was_posted 6y agowouldn't an easy fix for verifiability be that you include a list of hashes of every valid share along with each individual key?
- l1am0 6y agoWould 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?