3 ms·

"don't roll your own crypto" is good advice, but it's also against the hacker ethos. It's another way of saying "you'll never really understand this so don't tr

"don't roll your own crypto" is good advice, but it's also against the hacker ethos. It's another way of saying "you'll never really understand this so don't try, just rely on a mysterious cabal of experts". May be true, but not exactly a great message.

IncRnd 4y ago
>It's another way of saying "you'll never really understand this so don't try, just rely on a mysterious cabal of experts". It's more along the lines of, "you absolutely can understand this if you try, buy trying will take years of your life to learn and apply all attack vectors and their mitigations." The admonition not to roll your own crypto isn't so that people don't look at crypto. Take a look, fiddle, and hack all you want - just not in production. The saying comes from crypto people noticing avoidable security issues that get created many times people have touched or used crypto code - because even 100% correct crypto code is often also broken in practice.
woodruffw 4y ago
I think it's closer to "don't think you can half-ass your way into an understanding," rather than "you'll never be able to understand this." That "cabal of experts" all had to learn at some point, too. In general, I think DRYAC is excellent advice, and that we should apply similar reasoning to unsafe programming languages. And that is not to say that people shouldn't use them; only that we, as a community, should be making ourselves more half-ass-resistant.
- chmod600 4y ago
  Most of what I've learned has been by overconfidently trying to do something I didn't understand, and then learning better ways incrementally. Granted, this is a bad idea when it comes to nuclear engineering. But it's sad when we say it's bad for software engineering, even crypto. The fact that you want to apply that to C programming is really sad. That's effectively saying that people can play with web apps, but not operating systems. I am not saying you are wrong. Just that you're no fun at all.
  - woodruffw 4y ago
    I think you've misunderstood. There are at least two separate things are stake here: there's professional software engineering, and then there's hobbyist programming. Software engineering has been undergoing professionalization (in terms of processes and safety standards) for the last 70 years. It's one of the few ways in which software really is an engineering practice: our standards are written in blood (or fraud), just like every other engineering discipline. In this context, DRYAC and "don't write it in C" are excellent principles: we've successfully professionalized and compartmentalized beyond the need for the bad old ways, except in limited cases (corresponding to domain expertise or specific, legacy requirements). Then there's hobbyist programming, where you can do whatever you please. I write C for fun. I implement hilariously outdated block ciphers for fun[1]. I couldn't write a web app if my life depended on it. The key understanding with hobbyist programming is that it's (1) adequately disclaimed as not usable in professional contexts, or (2) adheres to the same standards as professional, potentially critical, software engineering. Open source started as case (1) above, and is slowly turning towards case (2) where it matters. And where it matters is cryptography and, increasingly, memory unsafe code. In other words: you're more than welcome to build a model train set (I do it), but it doesn't qualify either of us to run a railroad. What qualifies us is learning and performing everything else involved in the safe and normal operation of a modern railroad, including knowing not to build steam engines anymore. [1]: https://github.com/woodruffw/skipjack.rs https://github.com/woodruffw/skipjack.rs

IncRnd 4y ago

>It's another way of saying "you'll never really understand this so don't try, just rely on a mysterious cabal of experts". It's more along the lines of, "you absolutely can understand this if you try, buy trying will take years of your life to learn and apply all attack vectors and their mitigations." The admonition not to roll your own crypto isn't so that people don't look at crypto. Take a look, fiddle, and hack all you want - just not in production. The saying comes from crypto people noticing avoidable security issues that get created many times people have touched or used crypto code - because even 100% correct crypto code is often also broken in practice.

woodruffw 4y ago

I think it's closer to "don't think you can half-ass your way into an understanding," rather than "you'll never be able to understand this." That "cabal of experts" all had to learn at some point, too. In general, I think DRYAC is excellent advice, and that we should apply similar reasoning to unsafe programming languages. And that is not to say that people shouldn't use them; only that we, as a community, should be making ourselves more half-ass-resistant.

chmod600 4y ago
Most of what I've learned has been by overconfidently trying to do something I didn't understand, and then learning better ways incrementally. Granted, this is a bad idea when it comes to nuclear engineering. But it's sad when we say it's bad for software engineering, even crypto. The fact that you want to apply that to C programming is really sad. That's effectively saying that people can play with web apps, but not operating systems. I am not saying you are wrong. Just that you're no fun at all.
- woodruffw 4y ago
  I think you've misunderstood. There are at least two separate things are stake here: there's professional software engineering, and then there's hobbyist programming. Software engineering has been undergoing professionalization (in terms of processes and safety standards) for the last 70 years. It's one of the few ways in which software really is an engineering practice: our standards are written in blood (or fraud), just like every other engineering discipline. In this context, DRYAC and "don't write it in C" are excellent principles: we've successfully professionalized and compartmentalized beyond the need for the bad old ways, except in limited cases (corresponding to domain expertise or specific, legacy requirements). Then there's hobbyist programming, where you can do whatever you please. I write C for fun. I implement hilariously outdated block ciphers for fun[1]. I couldn't write a web app if my life depended on it. The key understanding with hobbyist programming is that it's (1) adequately disclaimed as not usable in professional contexts, or (2) adheres to the same standards as professional, potentially critical, software engineering. Open source started as case (1) above, and is slowly turning towards case (2) where it matters. And where it matters is cryptography and, increasingly, memory unsafe code. In other words: you're more than welcome to build a model train set (I do it), but it doesn't qualify either of us to run a railroad. What qualifies us is learning and performing everything else involved in the safe and normal operation of a modern railroad, including knowing not to build steam engines anymore. [1]: https://github.com/woodruffw/skipjack.rs https://github.com/woodruffw/skipjack.rs