Pretty Curved Privacy • Hacker News Board

Re: Pretty Curved Privacy

#41

Post by tptacek » Tue, Jul 05, 2016, 9:35 PM UTC

briansmith wrote: post #40

tptacek wrote: post #39

Earlier quoted context omitted.

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.

Re: Pretty Curved Privacy

#42

Post by briansmith » Tue, Jul 05, 2016, 9:51 PM UTC

tptacek wrote: post #41

briansmith wrote: post #40

Earlier quoted context omitted.

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 softwar…

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.

Re: Pretty Curved Privacy

#43

Post by tptacek » Tue, Jul 05, 2016, 9:59 PM UTC

briansmith wrote: post #42

tptacek wrote: post #41

Earlier quoted context omitted.

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 softwar…

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 avoidabl…

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.

Re: Pretty Curved Privacy

#44

Post by briansmith » Tue, Jul 05, 2016, 10:21 PM UTC

tptacek wrote: post #43

briansmith wrote: post #42

Earlier quoted context omitted.

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 avoidabl…

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 exp…

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.

Re: Pretty Curved Privacy

#45

Post by tptacek » Tue, Jul 05, 2016, 10:54 PM UTC

briansmith wrote: post #44

tptacek wrote: post #43

Earlier quoted context omitted.

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 exp…

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…

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?

Re: Pretty Curved Privacy

#46

Post by sigcode » Wed, Jul 06, 2016, 2:52 AM UTC

tptacek wrote: post #34

sigcode wrote: post #27

Earlier quoted context omitted.

Agreed. Now kindly point to the mistakes the author has made so others can learn from them.

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? 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…

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.

Re: Pretty Curved Privacy

#47

Post by screw-loose » Wed, Jul 06, 2016, 2:07 PM UTC

tptacek wrote: post #34

sigcode wrote: post #27

Earlier quoted context omitted.

Agreed. Now kindly point to the mistakes the author has made so others can learn from them.

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? 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…

Good find, I'll take a look into that.

And yes I do not recommend using this for serious purposes (that is, I am the author).