In particular, the advice was originally intended to mean “don’t invent/write your own primitives or modes”. It has morphed into “don’t write crypto code period”. Case in point: JWT.
With libraries like sodium (or even OpenSSL if you tread carefully), there is no reason why a developer can’t safely encrypt a cookie.
History has shown that most people who think they can safely encrypt a cookie screw up the MAC and open themselves up to all sorts of heinous cookie forgery vulns.
Exactly. The whole task has to be designed and reviewed by security experts due to composition errors. There’s also sometimes assumptions that primitive builders assume others will know but don’t document. Related to that, there’s system/environment aspects that might need considering such as whether it has swap or hibernate which can put keys on hard disks. Lots of little things I don’t trust a non-security engineer to know.
I love this. These kinds of attitudes have always bothered me. While in some situations ‘don’t reinvent the wheel’ might be appropriate, I find more often than not it is terrible advice, and it is taken too far (like many things, e.g. the premature optimisation quote). We don’t really have ‘wheels’ in programming. A wheel (the concept at least) is very simple and difficult to improve. The same is not true of much in the world of computing.
One thing I’d like to ask the author: do you need “to lead instead of follow” in order to want to learn something? Or was that just a rhetorical device?
It was contextual. Same for “to create instead of build.”
Nothing against builders or followers. But I was aiming against the usual, “don’t do that!” response I see to everyone trying new things. Specifically the recent article doing the rounds about running a website in C++ (spoiler alert: aside from this forum, my site runs on C++ code.)
I was saying, do you want to follow others’ advice, or try something new and learn for yourself? Maybe C++ ends up going badly for you, in which case you learn why, and can apply those lessons going forward, instead of just parroting others’ advice not to even try. Maybe it goes well for you, in which case you have something exciting and potentially innovative on your hands.
I was saying, do you want to just incrementally build websites based on what everyone else has done? Eg maintain yet another Wordpress blog, maybe monkey patch in a client feature request or two? To copy everyone else and try to deploy whatever JS framework is handy this week? Or would you rather work on a framework and understand your craft on a more fundamental level?
My own experiences are that the deeper I go into computer science, the more sheer fun I have. The most exciting time I can remember programming was working on a language of my own. It didn’t bear fruit, but what I learned transformed my GUI toolkit (among other things) into something far more robust. And the more I work on these things, the more I recognize how unbelievably bloated every last thing in computer science has become. It’s refreshing to shed away decades of cruft and just start fresh. To see how much you can do with 1/20th the code. Eg I just wrote a fancy cross-platform CRUD application with lots of input validation in 400 lines … of C++ code! I can parse PNG images in 16KiB of code from two headers … no need for 400KiB of zlib and 300KiB of libpng. I have a functional IPv4+6 web server in 200 lines of code. A high-quality audio IIR filter in 3.8KiB of code. A delta-patching format you can describe in full on a postcard. And every time I hear, “but you could have just used $library!” And yeah, I could have. And I would have added lots of dependencies making the code harder to build, and I will have learned nothing meaningful in the process. No thank you.
I understand there are coders that just wanna get paid. Surely, the least amount of work is the easiest way to do that. But I was appealing to people who enjoy programming as an art: don’t let other people convince you to be a worker bee when you could have so much more fun experimenting. One thing is for certain: nobody’s ever going to remember the 9-5 office worker who maintained blog.generic-company.com. But they sure will remember Daniel Bernstein, or John Carmack, or Bjarne Stroustrup.
I also understand it’s not a good idea to deploy your own homegrown Caeser cipher out at your job at Wells Fargo. I’m talking about applications where safety and job security aren’t on the line here. Someone has to learn how to write crypto libraries. If we all leave it to the OpenSSL guys then we get a software monoculture that screws us all when, surprise!, they’re not perfect either and now everyone has to deal with Heartbleed.
But, look how fast my site loads. You click that article link and the page is there in 20 milliseconds. Now go try a web 3.0 darling like Slack, and you’re sitting there twiddling your thumbs for 20 seconds while the chat loads. Is my C++ on the web approach really worse than that?
This one doesn’t mean that you shouldn’t write any, it means that you shouldn’t use your own crypto for security reasons, but you still can learn !
In particular, the advice was originally intended to mean “don’t invent/write your own primitives or modes”. It has morphed into “don’t write crypto code period”. Case in point: JWT.
With libraries like sodium (or even OpenSSL if you tread carefully), there is no reason why a developer can’t safely encrypt a cookie.
History has shown that most people who think they can safely encrypt a cookie screw up the MAC and open themselves up to all sorts of heinous cookie forgery vulns.
Exactly. The whole task has to be designed and reviewed by security experts due to composition errors. There’s also sometimes assumptions that primitive builders assume others will know but don’t document. Related to that, there’s system/environment aspects that might need considering such as whether it has swap or hibernate which can put keys on hard disks. Lots of little things I don’t trust a non-security engineer to know.
I love this. These kinds of attitudes have always bothered me. While in some situations ‘don’t reinvent the wheel’ might be appropriate, I find more often than not it is terrible advice, and it is taken too far (like many things, e.g. the premature optimisation quote). We don’t really have ‘wheels’ in programming. A wheel (the concept at least) is very simple and difficult to improve. The same is not true of much in the world of computing.
One thing I’d like to ask the author: do you need “to lead instead of follow” in order to want to learn something? Or was that just a rhetorical device?
I linked this thread to the author, and he replied: