4 ms·
I love seeing projects like this and I hope that a sane alternative to OpenSSL emerges. A big dream of mine is that we'll eventually have a comprehensive and h
by jf 9y ago
I love seeing projects like this and I hope that a sane alternative to OpenSSL emerges.
A big dream of mine is that we'll eventually have a comprehensive and hyper-detailed set of automated tests that we can use to validate cryptographic libraries [0]. Someday I hope that every new CVE for a cryptographic library will also come with a corresponding automated test to check for that vulnerability.
Footnotes:
0: Wycheproof is the closest I've seen to this ideal yet: https://github.com/google/wycheproof https://github.com/google/wycheproof
- bno1 9y agoThere is an ongoing project [0] implementing a formally verified and performant TLS1.3 library. They already have verified and optimized assembly for AES and SHA256. I think it will be a big game changer if it succeedes. [0] https://project-everest.github.io/ https://project-everest.github.io/
- jf 9y agoThis is great, thanks for sharing it!
- extrapickles 9y agoSome of the vulnerabilities are harder to test as they are side channels specific to the hardware the code is running on. Sure you can check that basic timing side channels don’t exist, but the more esoteric ones would require a bunch of hardware to make sure they aren’t leaking data via power use and other channels.
- jf 9y agoCan you go into more details on situations that would be hard to test? This has all only been a thought experiment for me so far, and in my thought experiment I handwave these sort of issues away by thinking "that's what emulation/simulation is for" – but I hadn't considered leading data via power use, so clearly I need to learn more there.