Pretty Curved Privacy
github.com
github.com
I thought one of the motivations behind this library was that you did not need to be an "expert" to use it.
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.
https://github.com/TLINDEN/pcp/blob/master/libpcp/crypto.c#L...
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.
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.
And yes I do not recommend using this for serious purposes (that is, I am the author).
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...
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. :)
Are you saying that people should use CPGB? Are you saying that CPGB is better than pcp because you think the author of CPGB is more of an expert than the author of pcp?
Did you notice the pcp author actually tried to write tests, whereas there are no tests in CPGB?
BTW, the last commit to CPGB was on Dec 19, 2011.
I've nothing against CPGB and I'm not familiar with pcp but I think this "expert" thing is ridiculous.
I've talked to way too many people that want to make contributions to improve security software, including crypto software, but get scared away because of the implied and explicit discouragement due to such appeals. It's holding our industry back and slowing us down.
In this case, though, all I'm saying is that if you want to read an ECC software package with a GPG-like interface, there actually already is one that was authored by an expert. Whatever you think about newcomer cryptography, expertise has value.
I've worked on code bases written by experts that put billions of people at risks that were avoidable with proper testing. Conversely, I've seen newcomers write very good code--yes, even crypto code--that was clearly correct because of their code clarity, documentation, and tests.
There's a lot of people who are going to interpret your comment--the one at the top of this discussion--as "Newbies shouldn't even try, and definitely shouldn't show their code to anybody." I doubt that's what you intended, but that's unfortunately the message that gets conveyed, judging from the discussions I've had with lots of newcomers. Nobody's going to write perfect crypto code right away. We can't be shooting them down before they even get started.
Like you, I've spent a lot of time looking at crypto implemented both by experts (or by teams that include at least one expert) and by non-experts. The conclusion I've come to, quite firmly, is:
* The kind of expertise needed to build secure messaging systems is extremely rare, far rarer than expertise with cryptography.
* Without expertise in cryptography, the likelihood of implementing a secure cryptosystem is very low, and almost entirely determined by the simplicity of the system.
* Secure messaging systems are deceptively complex, even more so than secure channels, which is a problem that has bedeviled software security for more than a decade.
I agree: you can't learn cryptography without writing code. But there are lots of different kinds of code one can write. One can invest time in implementing cryptographic attacks, or one can join a project lead by experts and ask lots of questions. But almost nobody does those things, because they aren't splashy.
I'll put it to you this way: sci.crypt had long had a norm that amateur efforts to design ciphers were not to be given significant attention. Those ciphers were always inferior and usually comically broken, and spending time on them wasn't just a waste of time for the cryptographers on that newsgroup, but also for the people designing the ciphers. Was that norm "shooting them down before they even get started"?
I would like to see a lot more amateur attack code, and a lot less amateur end-user crypto. Not just because the amateur end-user crypto almost invariably puts people at risk, but because designing new end-user crypto tools is a waste of time for the implementors.
Again, though: I don't even think the author of this package thinks you should use it. So my real point is just: if you're going to look at an ECC-based GPG-alike that you're not going to use anyways, check out one written by an expert.
I don't understand the value of pointing to something that died 5 years ago and where nobody even wrote a single test as a model to learn from. There's got to be better models to follow, if our goal is to point people at things to learn from. There's no need to turns things ad hominem by shifting the focus to authorship and away from the actual merits of the software: design, code quality, test coverage.
Meanwhile:
Look, you are much smarter than I am about this stuff. I'm just a pentester with a former life as a software developer. Are you honestly telling me that you think a good way to learn how to build safe crypto is to start de novo a new secure messaging application? Of all the things you could do to introduce yourself to the field, and what work in the field is really about, that's what you think smart people should be spending their time on?
At this point I'm a fan of the idea (a set of protocols to mirror some of the good parts of PGP, married with the good parts of NaCl. At least in ... theory...).
> In fact, I wrote it just to learn about the curve and see how it works.
I don't think the author seriously considers replacing PGP with this.
if you do not control your keys, then someone else does.
Forgive my ignorance, but I assume that this is to ensure that the message is from Alicia. How is this different from signing + encrypting a message in PGP?