While NaCl/Sodium does simplify the crypto aspect in particular, it's dangerous to assume that it entirely solves the broader problem of writing secure code. Implementing anything securely is hard enough before involving crypto that the level of expertise required doesn't change all that much. (Most catastrophic vulnerabilities in security software aren't directly in the cryptographic implementations.)
Even using NaCl, one needs to understand enough of what's happening under the hood to properly reason about the security of the whole system they've built.
Am I allowed to be concerned that this is C code that opens up random files to be decrypted, slurps a 32 bit integer directly out of the file, passes that value to malloc, and then just a few lines later loops memcpy'ing into that buffer?
That's, like, 5 minutes worth of looking, most of it spent working out how to get from main() to the part of the code that actually starts taking attacker-controlled inputs; we're about 10 lines into the code that handles those inputs. Is that a real vulnerability? Hell if I know, but I'm scared of this code.
Which is not to say I don't like it. There's a small utility function in there I'm stealing! The author is clearly smart and I hope this was an interesting project for them. But I don't recommend using this for real --- and I think neither does the author.
You are allowed to be concerned. I probably read too much into your comment. But I think you all understand my point. I was concerned that some mortals might be scared off from experimenting with NaCl. "Experts only."
Some years ago, there was another fellow who wrote a set of NaCl utilities that were very simple, UNIX filters. While I was "scared of the code" because he's not a renown cryptographer (does he need to be?), I was thankful for a simple, working example. There really weren't any publicly available at the time.
I really appreciate when people share these self-learning projects.
That's a nice way to put the fallacy. That one is so common it needs its own name and Wikipedia page with list of hacked products that used the fallacy. Anyone already do that with a link?
On my end, I always tell them any system or scheme is to be assumed vulnerable until proven otherwise through analysis and pentesting. If they doubt that, I show them plenty of stuff made by pro's and associated CVE's. Then ask if their people were better and with more budget for security. Usually a no...
I've written my fair share of vulnerable code throughout the years. Two key indicators for me: Do they learn from their mistakes? Are they proactive at preventing mistakes?
I wasn't actually commenting on this project in particular or whether or not the author happens to be an expert (tptacek may have more to say about that), just on the idea of NaCl as a replacement for expertise.
NaCl/libsodium solve a low-level problem that even very few talented engineers with years of software security experience can be expected to get right on their own.
Using these features should still be done under the guidance of someone who knows what they're doing. There's a larger number of developers who can use libsodium than there are developers who could replace it on their own.
In a sense, NaCl/libsodium can be viewed as a "replacement for expertise" that is so rare it's nigh-nonexistent. (To wit: these libraries were created by multiple authors.) Rather, it places the capability to build solid application-layer crypto into the hands of mere mortals.
That doesn't obviate the need for good mortals. :)
Even using NaCl, one needs to understand enough of what's happening under the hood to properly reason about the security of the whole system they've built.