I was sure I'd came across this on HN, but apparently I found it when I wondered if anyone had taken a crack at taking NaCl and made a PGP work-alike using the primitives NaCl provides. And here it is. Anyone have any experience with it? Done a cursory review?
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...).
If you need a "real" PGP, GnuPG 2.1 has had experimental support for Curve25519 since 2014. In the most recent version the experimental warning label was gone, so it should be pretty stable by now. Many keyservers still barf on the keys though.
the problem is not that "pgp doesn't use 25519" the problem is the openpgp format as per rfc4880 and the whole thing being from the naive nineties, not suited for advanced adversaries we have since then.
That example in the README.md of Alicia and Bob generating a keypair, importing each others public keys, then encrypting/descripting a simple note is really well laid out.
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.
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. :)
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?
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.
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'm sorry, I don't follow your objection. What's ridiculous here? My trust for Watson Ladd's crypto code is epsilon less than my trust for Bernstein's code. The expertise I'm appealing to here is pretty straightforward.
The appeal to expertise is exactly what I'm objecting to. Let's judge things on their technical merits: tests, clarity of code, correctness, etc.
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.
Wow, did you ever pick the wrong (or maybe the perfect) person to push that argument against. I couldn't disagree with you more. People should be discouraged from learning cryptography by building new tools for end-users to encrypt sensitive messages with. They should be encouraged to learn cryptography by actually learning cryptography.
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.
One can't really learn cryptography without writing code. IMO, people should write code and share it and get feedback on it, and experts should donate some time to help them improve, so that we can have more experts. And experts should encourage good programming practices: good testing, good design documentation, etc.
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.
No, your suspicion about the subtext of my comment was legitimate. I do think that.
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.
Here's the effect that this ultimately has, as far as I can see: The most reasonable people, who we would ultimately like to see build something that people use, get discouraged and go work on something else. The most stubborn, unreasonable people then charge ahead, and eventually a few of them break through via marketing and win millions or billions of users, with whatever they put together. It's a net loss.
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.
That's not what I see happening. What I see is a gradual shift from DIY crypto to a few vetted components and designs --- Nacl, Signal Protocol, Scrypt --- and objections, often from non-experts, when new systems avoid those components. Things look hopeful to me.
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?
My question is: People don't even use PGP and it's been around for over 20 years. What makes this more adoptable, if it all?
The problem with most encryption is, it's not transparent to the end user. The second users have to start goofing around with key generation, uploading keys, etc you lost. I get that using Curve25519 is "better" but none of this still solves the fundamental problem of end user adoption.
the problem with "transparent to the end user" is a variation of Geers Law: "Any security technology whose effectiveness can't be empirically determined is indistinguishable from blind luck."
if you do not control your keys, then someone else does.
Cool. I suspect that's going to start being a problem in the next decade or two, assuming that government entities haven't already made sophisticated quantum computers in secret.
> Please note the big difference to GPG though: both Alicia AND Bobby have to enter the passphrase for their secret key! That's the way CURVE25519 works: you encrypt a message using your secret key and the recipients public key and the recipient does the opposite, he uses his secret key and your public key to actually decrypt the message.
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?
Despite all the claims in the README, Curve25519 has in fact been standardized (at least informationally) by the IRTF CFRG in RFC 7748: https://tools.ietf.org/html/rfc7748
46 comments
[ 4.2 ms ] story [ 44.4 ms ] threadAt 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...).
https://github.com/davidlazar/flycrypt
https://github.com/wbl/cpgb
https://github.com/Spark-Innovations/SC4
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.
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. :)
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...
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).
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?
if you do not control your keys, then someone else does.
> 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.
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?