This project seems to be the culmination of a rhetorial question that the author posed a while ago: if the advice is 'don't roll your own crypto' [1], then how does any crypto ever come into being? [2]
So perhaps the marketing is off: I don't view this as a "small, secure, auditable, easy to use crypto library"; I view this as a practical and ongoing study in investigating how to make small, secure, auditable, easy-to-use crypto libraries. To be fair, the page mentions that it's "not ready for production" and needing external review a quarter of the way down, but if the point is to prove that a sufficiently dedicated individual can learn the material, endure some criticism, and produce quality software following the example of well-acclaimed experts, then own this point, bare your disclaimers in the beginning, and make it more prominent.
And once you phrase it that way -- which is arguably consistent with the author's previous posts (and HN comments) on the topic, it's suddenly a lot more palatable, and regardless of its ultimate outcome, I can only applaud.
[1] I use an interpretation of "don't roll your own crypto" that's slightly less circular than the author's. In my opinion, it's shorthand for 'defer to the opinion of experts, use ready-made constructs when possible, and if not, then exercise caution when hooking crypto primitives together in unproven ways'. Originally posted here: [3]
"Don't roll your own" doesn't mean "never build any crypto". It does affect recommendations for using this library for example. One thing that matters there is risk: how much are you losing by not just using existing, extremely similar tools, and how much do you gain from the codebase being smaller? (My professional opinion: balance in favor of libsodium).
That changes when the software does things previously impossible or hard. NaCl and libsodium were interesting not because you couldn't do strong and safe AEAD before (OCB is from 2012, AES-CBC + HMAC-SHA256 EtM have been available for almost two decades) -- it's because you finally had a realistic chance of getting random programmers to do AEAD in some code and have it be OK.
Noise, hence is interesting because it gives you a transport with interesting new properties, including forward and backward security that you don't get out of the box with NaCl/libsodium. E.g. if you build a naive session protocol with libsodium, odds are you're vulnerable to KCI attacks. That's not a bug in libsodium because it never promised to do that, but it would be a bug in Noise.
Similarly: STROBE! New, exciting! Low-footprint crypto! Strong tools! Also not recommending anyone suddenly use STROBE for everything (especially not in software, but we can talk if you have embedded hardware problems).
I would be careful with statements like this, largely because the question of what 'bug free' means is real.
Do you mean that the crypto algorithms work as advertised? e.g. would DES after public knowledge of differential cryptanalysis be okay?
Do you mean that you have implemented algorithms exactly as specified?
Do you mean that you have implemented algorithms exactly as specified that are also constant time so that they resist timing attacks?
Do you mean that you have implemented algorithms exactly as specified that are not vulnerable to cache eviction attacks on shared hardware?
Do you mean that you have implemented algorithms exactly as specified that resist bit-flip attacks or SDR attacks, or audio attacks, or other Van Eck style listening?
I'm actually not trying to be down on your work. It's hard work, and the world needs more people who actually do it. I'm just saying it is VERY hard to feel confident, and as someone who has a passing interest in this kind of security, I worry when I read statements like you made.
Exactly as specified, and immune to timing attacks including cache eviction. I make no claim about other side channels, or the strength of the primitive themselves —though I did pick strong primitives.
Probably not what you had in mind, but if there's a 0.1% that you have a bug in any given line (let's assume that includes bugs in how lines interact as well) - there's about a 63% chance there's at least one bug for every 1000 lines of code, if my math isn't off.
That's mostly to say: I agree with your assessment that you (and me and everyone) need help to review code and look for bugs.
So perhaps the marketing is off: I don't view this as a "small, secure, auditable, easy to use crypto library"; I view this as a practical and ongoing study in investigating how to make small, secure, auditable, easy-to-use crypto libraries. To be fair, the page mentions that it's "not ready for production" and needing external review a quarter of the way down, but if the point is to prove that a sufficiently dedicated individual can learn the material, endure some criticism, and produce quality software following the example of well-acclaimed experts, then own this point, bare your disclaimers in the beginning, and make it more prominent.
And once you phrase it that way -- which is arguably consistent with the author's previous posts (and HN comments) on the topic, it's suddenly a lot more palatable, and regardless of its ultimate outcome, I can only applaud.
[1] I use an interpretation of "don't roll your own crypto" that's slightly less circular than the author's. In my opinion, it's shorthand for 'defer to the opinion of experts, use ready-made constructs when possible, and if not, then exercise caution when hooking crypto primitives together in unproven ways'. Originally posted here: [3]
[2] http://loup-vaillant.fr/articles/rolling-your-own-crypto
[3] https://news.ycombinator.com/item?id=12400040