|
|
|
|
|
|
by unscaled
499 days ago
|
|
|
Case in point: http://sbudella.altervista.org/blog/20230330-shamir-timing.h... 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 |
|
|