4 ms·
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
by briansmith 10y ago
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.
- tptacek 10y agoNo, 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.
- briansmith 10y agoHere'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.
- tptacek 10y agoThat'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?