Hacker News new | ask | show | jobs
by protz 2633 days ago
Several comments note that the headline is perhaps a little misleading; I agree, and I don't think any of us (I'm one of the cited people in the article) would've made such a strong claim.

Ignoring for a moment the fact that this is an alpha release (and that as such, a handful of minor proofs, e.g. mundane facts related to endianness conversions, have yet to be completed), there are several limitations of our work.

- Our tools themselves are not verified, so there could be a bug in F, z3, the kremlin F-to-C compiler; or a bug about the C compiler itself (unless one uses a constant-time fork of CompCert). We consider most of these to be theoretically unpleasant, but still an acceptable tradeoff.

- Specifications are extremely hard to get right: one might introduce a typo when reading an RFC, or, say, state an endianness conversion wrong. So, even before implementing an optimized version of anything, we audit and test the spec first. This is usually a good sanity check, but certainly not bulletproof (note that this is a general problem of software verification, not specific to us).

- As noted near the end of the article, our models do not account for Spectre and Meltdown; and there might be new classes of attacks that we can't guard against, for the simple reason that they haven't been found yet.

As to whether this is an attempt to get free security audits, I guess we weren't intentionally thinking of it! But we certainly would love it if people could test the code and give us feedback on what to improve to make this an even more compelling choice for whoever needs a good cryptographic library. I've written a bit about this here: https://jonathan.protzenko.fr/2019/04/02/evercrypt-alpha1.ht...

2 comments

Thank you, this looks like a great advancement.

> there might be new classes of attacks that we can't guard against, for the simple reason that they haven't been found yet.

I've also puzzled about this phrase in the article. Why "class of attack haven't been found" necessarily leads to "we can't guard against this class of attack"?

I guess we need more definitions here to clarify what we're talking about... but you're doing that already, so maybe this statement can be made more precise elsewhere?

>Why "class of attack haven't been found" necessarily leads to "we can't guard against this class of attack"?

One thing I can think of is the practice of using multiple random number generators to generate a number that is random as long as any 1 generator is random. This guards against attacks on a specific generator even if those attacks are unknown. The class of attack is known, however, and protected against.

Great perspective ... and, very impressive work!