4 ms·

> "Just Libsodium" doesn't work on anything smaller than a Raspberry-Pi, or pretty much any embedded system out there. There are alternatives out there And the

> "Just Libsodium" doesn't work on anything smaller than a Raspberry-Pi, or pretty much any embedded system out there. There are alternatives out there And the same author provides a solution for those systems as well with libhydrogen. Though that doesn't look so super hot anymore given the recent advances on Gimli[1,2,3], but it'll likely still hold up in practice. > but sometimes your only choice is to code and optimise it yourself That is a critical shortcoming of the ecosystem. If you reach that point, you should be hiring a cryptographer/experienced implementer. Your follow-up question might be “Where do the cryptographers come from, then?” and the answer to that is: “PhD programs at universities, ideally”. Curiously, however, many (most?) cryptography libraries that are used in practice appear to be written by people with barely any academic background. We should be working to rectify that one way or another (send the implementers to university or pull more people from theory into implementation practice). > you don't need to know all the attacks to protect yourself from them. What you need to know is the relevant classes of attacks, and how to void them Some attacks, however, can be quite surprising or virtually impossible to mitigate without deep knowledge of the specific problem domain. Are we sure how to mitigate software implementations of EC scalar multiplication against differential power analysis yet? And that's before you get to protocol design, where there are new, mysterious ways to shoot yourself in the foot (use TLS, use TLS, use Noise). [1] https://eprint.iacr.org/2020/561.pdf https://eprint.iacr.org/2020/561.pdf [2] https://eprint.iacr.org/2020/591.pdf https://eprint.iacr.org/2020/591.pdf [3] https://eurocrypt.iacr.org/2020/rump/ec2020rump-paper23-slides-presentation.pdf https://eurocrypt.iacr.org/2020/rump/ec2020rump-paper23-slid...

loup-vaillant 6y ago
> Some attacks, however, can be quite surprising or virtually impossible to mitigate without deep knowledge of the specific problem domain. Are we sure how to mitigate software implementations of EC scalar multiplication against differential power analysis yet? This particular attack is not really about ECC, and more about the processor & program you use. One "easy" way to immunize yourself against power analysis is to have your implementation be "constant power". That is, no information must flow from secrets to power. The first step is coming up with hardware with constant-power operations. Then the cryptographic engineer must make sure the power-variable instruction never have secret inputs. That may require compiler support, writing assembly code by hand, or formal analysis. That can be wickedly hard indeed, but it also has little to do with ECC specifically. The deep knowledge required there is about hardware, compilation techniques, formal methods… The only ECC specific part is identifying the secrets, and that's comparatively trivial.
- api 6y ago
  I want to point out just so people understand that NO popular platforms meet these criteria for any algorithm whatsoever. Any CPU with any form of branch prediction or speculative execution can't be made truly totally secure against these attacks, and that is all high performance CPUs. I suspect these sorts of issues are why black box hardware units like NSA type I encryptors are used for the most sensitive communication. What you can do with popular platforms is try to mitigate the most egregious and easily exploitable variants by (a) not branching on secret data and (b) avoiding lookup tables or other memory access patterns that depend on secrets. The latter much harder to achieve and is why AES sucks on chips without hardware AES support. (But on chips with that support, it becomes better than alternatives!) There are other competing practical concerns though like power use, speed, and standards compliance. This stuff is hard. Edit: these sorts of attacks do matter and are worth trying to mitigate if your code will ever run in the cloud. In that case it will run on multi tenant machines where there may be malicious neighbors who can analyze timing on shared hardware.
api 6y ago
Its oddly worse than you say. Most crypto code I have seen is of below median code quality. It seems to be written by people with neither a strong academic crypto background nor a solid practical coding background. Compare e.g. OpenSSL, the most widely used library, with SQLite, the most widely used embedded database. OpenSSL is a mess under the hood with a hideous API on the surface, while SQLite is beautiful code with an API that is a joy to use. Newer trendier stuff like libsodium are better but they still feel unpolished to me.

loup-vaillant 6y ago

> Some attacks, however, can be quite surprising or virtually impossible to mitigate without deep knowledge of the specific problem domain. Are we sure how to mitigate software implementations of EC scalar multiplication against differential power analysis yet? This particular attack is not really about ECC, and more about the processor & program you use. One "easy" way to immunize yourself against power analysis is to have your implementation be "constant power". That is, no information must flow from secrets to power. The first step is coming up with hardware with constant-power operations. Then the cryptographic engineer must make sure the power-variable instruction never have secret inputs. That may require compiler support, writing assembly code by hand, or formal analysis. That can be wickedly hard indeed, but it also has little to do with ECC specifically. The deep knowledge required there is about hardware, compilation techniques, formal methods… The only ECC specific part is identifying the secrets, and that's comparatively trivial.

api 6y ago
I want to point out just so people understand that NO popular platforms meet these criteria for any algorithm whatsoever. Any CPU with any form of branch prediction or speculative execution can't be made truly totally secure against these attacks, and that is all high performance CPUs. I suspect these sorts of issues are why black box hardware units like NSA type I encryptors are used for the most sensitive communication. What you can do with popular platforms is try to mitigate the most egregious and easily exploitable variants by (a) not branching on secret data and (b) avoiding lookup tables or other memory access patterns that depend on secrets. The latter much harder to achieve and is why AES sucks on chips without hardware AES support. (But on chips with that support, it becomes better than alternatives!) There are other competing practical concerns though like power use, speed, and standards compliance. This stuff is hard. Edit: these sorts of attacks do matter and are worth trying to mitigate if your code will ever run in the cloud. In that case it will run on multi tenant machines where there may be malicious neighbors who can analyze timing on shared hardware.

api 6y ago

Its oddly worse than you say. Most crypto code I have seen is of below median code quality. It seems to be written by people with neither a strong academic crypto background nor a solid practical coding background. Compare e.g. OpenSSL, the most widely used library, with SQLite, the most widely used embedded database. OpenSSL is a mess under the hood with a hideous API on the surface, while SQLite is beautiful code with an API that is a joy to use. Newer trendier stuff like libsodium are better but they still feel unpolished to me.