41–50 of 51 posts
I’ve written ones based off Vault’s Go version in both Nim and Elixir:
Earlier quoted context omitted.
> This scheme implies you trust this distributor not to make copies of the key for himself (queue sauron references...). I've wondered if there's a scheme that does NOT trust the distributor of the key. What you describe still trusts the distributor - you just found a way to make the distributor easy to trust. I'd be more interested in a mechanism that is mathematically correct, like some of the papers referenced els…
Even if you avoid trusting the distributor, the quorum of share holders still will end up having to reconstitute the shared key into the memory of a computer somewhere at some point to do cryptographic operations with it. There is no avoiding standing up computers all parties trust and if you are going to do that anyway then you might as well use them for key generation and distribution too.
Implementing SSS is fun. It’s short and covers using modulo integer arithmetic to compute invertible integer functions. It also overlaps with error correction methods a bit. I’ve written ones based off Vault’s Go version in both Nim and Elixir: - keyxn https://github.com/elcritch/keyxn - keyx https://github.com/elcritch/keyx
Should be GF(256). 255 isn't a prime power and can't be a field.
I dunno anything about nim but the GF arithmetic code appears to contain branching on values, so this implementation isn't sidechannel resistant and could reduce the users security if otherwise their use of cryptography would be sidechannel resistant.
I didn't look further, it's common for SSS implementations to contain cryptographic flaws that degrade or destroy their security entirely for the same reason people are advised to not home-roll their own constructions of other cryptosystems.
Here is a great talk on new SSS library from Daan Sprenkels at 34C3: https://www.youtube.com/watch?v=ojMFCpUt7OU Implementation: https://github.com/dsprenkels/sss
I have not reviewed it (beyond a glance), but based on the readme I'm confident that this one has a good chance of being secure, which is a vast improvement over most.
I still think in general SSS has very limited real use (except embedded into a larger cryptosystem), but if you're going to use it at least use a version that doesn't introduce vulnerabilities!
I'd recommend using libgfshare over ssss, if you're looking for a command-line application.
this has obvious timing and cache sidechannels on the secret data.
(IIRC SSSS is even worse, however.)
Implementing SSS is fun. It’s short and covers using modulo integer arithmetic to compute invertible integer functions. It also overlaps with error correction methods a bit. I’ve written ones based off Vault’s Go version in both Nim and Elixir: - keyxn https://github.com/elcritch/keyxn - keyx https://github.com/elcritch/keyx
> GF(255). Should be GF(256). 255 isn't a prime power and can't be a field. I dunno anything about nim but the GF arithmetic code appears to contain branching on values, so this implementation isn't sidechannel resistant and could reduce the users security if otherwise their use of cryptography would be sidechannel resistant. I didn't look further, it's common for SSS implementations to contain cryptographic flaws th…
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.
Earlier quoted context omitted.
Even if you avoid trusting the distributor, the quorum of share holders still will end up having to reconstitute the shared key into the memory of a computer somewhere at some point to do cryptographic operations with it. There is no avoiding standing up computers all parties trust and if you are going to do that anyway then you might as well use them for key generation and distribution too.
Well, now you've just turned your locked box into a key distribution machine, and there's a big difference in the security profile of each.
Earlier quoted context omitted.
> GF(255). Should be GF(256). 255 isn't a prime power and can't be a field. I dunno anything about nim but the GF arithmetic code appears to contain branching on values, so this implementation isn't sidechannel resistant and could reduce the users security if otherwise their use of cryptography would be sidechannel resistant. I didn't look further, it's common for SSS implementations to contain cryptographic flaws th…
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…
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!
Earlier quoted context omitted.
Well, now you've just turned your locked box into a key distribution machine, and there's a big difference in the security profile of each.
What is the point of generating a cryptographic key that you can never safely use?
I mean, if we all agreed to perform the decryption, the secret's out anyway. But not before then.