(no title)
cassonmars | 1 year ago
The arithmetic used is not constant time, meaning the actual computational steps involved leak information about the secret, were either the recombination of the shares or the initial splitting were observed via side channels.
The arithmetic does not guard against party identifiers being zero or overflowing to zero, although it is not likely to occur when used this way.
unscaled|1 year ago
I think that specific attack is pretty hard to pull off pratice (in normal scenarios, Vault secret unseals do not happen very often). But it can be a big problem if you were using a scheme where Shamir Secret sharing is used frequently (e.g. it can be triggered by a request sent by the attacker) and (I believe) with different parts of the secret every time.
It's probably safer to use an audited library, but here's a library library that has been audited by two firms, and it's still using lookup tables:
https://github.com/privy-io/shamir-secret-sharing/blob/main/...
The strangest thing is that the audit report by Cure53 mentions this issue, and says it was fixed, but it doesn't seem fixed (at least not in the way that I would expect and the way that HashiCorp fixed it, which is simply removing the tables and using constant-time math). The library maintainers seem to be very proactive and diligent about fixing other issues[1], so it really is strange.
[1] https://privy.io/blog/zero-leading-coefficients-cryptography