4 ms·

Ah thanks, I’ll fix the GF(256) bit. Yes they’re not side channel resistant —- I should add a note for that. The Nim one could be made so, but the Elixir one w

Ah thanks, I’ll fix the GF(256) bit. Yes they’re not side channel resistant —- I should add a note for that. The Nim one could be made so, but the Elixir one would be difficult due to its VM so I didn’t port the original constant time parts. I certainly wouldn’t recommend these libraries for very high security needs as is. That being said, side channel resistance isn’t a necessity for many use cases. SSS can be used for cases like making a scavenger hunt by splitting up a set of files among N USB keys. Perhaps even to give N family members Your Bitcoin wallet key in case you die or loose your key. Having a little GUI program run and present the combined data really wouldn’t benefit from side channel resistance, IMHO. So while caution is advisable with any security related code, I think the “never write crypto” prevents a lot of valid and useful applications.

nullc 4y ago
In bitcoin you can use multisig instead of secret sharing. Lots of good and well audited code for that. If you want some one key or threshold policy there isn't any transaction size overhead in the one key case anymore. I think my contention for SSS implementations has mostly been that the need/benefit seldom justifies the extra effort required to be confident you got it right. Obviously for a treasure hunt the bar is pretty low. :) It's hard to be sure when sidechannel resistance is really needed. Right now you could have some JS running in silently in a browser thats conducting a sidechannel attack to steal data. Probably not, but these attacks have been witnessed. Common issues aren't limited to sidechannels, e.g. it's pretty common for there to be "random" number generation problems that make it possible to recover the secret with fewer shares than the threshold. (the bitcoin wiki page I linked to gives two examples of that) I'd also agree that the "abstinence only" approach to cryptography doesn't work. But the underlying issue that drives that advice is real. The best alternative to overkilling the implementation is documenting the intended uses and known weaknesses, I guess!

nullc 4y ago

In bitcoin you can use multisig instead of secret sharing. Lots of good and well audited code for that. If you want some one key or threshold policy there isn't any transaction size overhead in the one key case anymore. I think my contention for SSS implementations has mostly been that the need/benefit seldom justifies the extra effort required to be confident you got it right. Obviously for a treasure hunt the bar is pretty low. :) It's hard to be sure when sidechannel resistance is really needed. Right now you could have some JS running in silently in a browser thats conducting a sidechannel attack to steal data. Probably not, but these attacks have been witnessed. Common issues aren't limited to sidechannels, e.g. it's pretty common for there to be "random" number generation problems that make it possible to recover the secret with fewer shares than the threshold. (the bitcoin wiki page I linked to gives two examples of that) I'd also agree that the "abstinence only" approach to cryptography doesn't work. But the underlying issue that drives that advice is real. The best alternative to overkilling the implementation is documenting the intended uses and known weaknesses, I guess!