Libsodium has been audited

Usable Cryptography in this context means secure API design. Accessible Cryptography in this context means it's actually available in their programming environment.
Post Reply
CiPHPerCoder
Posts: 7
Joined: Tue Aug 15, 2017 11:30 pm

Wed Aug 16, 2017 3:42 pm

Libsodium is an easy-to-use, secure-by-default cryptography library based on NaCl. PIA had Matt Green's team audit libsodium 1.0.12 and 1.0.13, and this is their results:

https://www.privateinternetaccess.com/b ... it-results

User avatar
nadim
Site Admin
Posts: 11
Joined: Tue Aug 15, 2017 7:57 pm
Location: Paris, France
Contact:

Wed Aug 16, 2017 6:20 pm

So essentially a highly competent cryptographer audits a library written by highly competent cryptographers. No wonder the findings are mild.

This is a welcome change from how the ecosystem looked like just a few years ago. I noted on Twitter just yesterday that low-level primitives in production applications were increasing in quality. :-)

CiPHPerCoder
Posts: 7
Joined: Tue Aug 15, 2017 11:30 pm

Thu Aug 17, 2017 7:41 am

Even the mild findings were debatable. I don't believe libsodium should offer curve448 or P521, for example.

User avatar
nadim
Site Admin
Posts: 11
Joined: Tue Aug 15, 2017 7:57 pm
Location: Paris, France
Contact:

Thu Aug 17, 2017 7:42 am

CiPHPerCoder wrote:
Thu Aug 17, 2017 7:41 am
I don't believe libsodium should offer curve448 or P521, for example.
I agree. Do we both think this for the same reason, namely that one standard curve (X25519) is enough?

CiPHPerCoder
Posts: 7
Joined: Tue Aug 15, 2017 11:30 pm

Thu Aug 17, 2017 1:48 pm

Yes, for exactly that reason. I'm wary of proposals for algorithm agility. If X25519 and/or Ed25519 is broken, then it'll call for an entire protocol/library upgrade IMO. (This may happen when pqcrypto actually wraps up, if not in libsodium, then in another project.)

Mikalai
Posts: 3
Joined: Fri Aug 18, 2017 1:52 pm

Fri Aug 18, 2017 2:05 pm

3.5.2 SD-02: Possible null pointer dereference in key exchange API
Makes me think about Rust right away.
3.5.6 SD-06: Lack of elliptic curves at higher security levels
... This would provide sufficient curve options at different security levels for application developers.
I thought it was NaCl's point to just provide conservatively strong primitives, so that I, a mere developer, would not have to choose. So, this "finding" seems to pull us back into confused-developer era, away from boring crypto.

CiPHPerCoder
Posts: 7
Joined: Tue Aug 15, 2017 11:30 pm

Fri Aug 18, 2017 8:25 pm

Mikalai wrote:
Fri Aug 18, 2017 2:05 pm
3.5.2 SD-02: Possible null pointer dereference in key exchange API
Makes me think about Rust right away.
3.5.6 SD-06: Lack of elliptic curves at higher security levels
... This would provide sufficient curve options at different security levels for application developers.
I thought it was NaCl's point to just provide conservatively strong primitives, so that I, a mere developer, would not have to choose. So, this "finding" seems to pull us back into confused-developer era, away from boring crypto.
Happy to hear that I'm not alone in taking issue with that "finding". :)

Mikalai
Posts: 3
Joined: Fri Aug 18, 2017 1:52 pm

Sun Aug 20, 2017 2:46 pm

CiPHPerCoder wrote:
Thu Aug 17, 2017 1:48 pm
algorithm agility
Developer should be told that a key can be used with one lib (prepackaged set of crypto primitives) only. Then "algorithm agility" turns into a lib agility. Developer keeps in key's json a field that identifies which lib (prepackaged set of crypto primitives) is used with the key. That's it. When post-quantum version of NaCl comes, we re-key accordingly. No worries. Situation is upgrade-able.

Post Reply