“I recommend that you apply extra-strength peer review to any code snippets you absorb into your project from the bathroom wall of code.”
Surely the recommendation should be to not copy and paste from the internet. (I thought that was the point of your modest proposal). There’s no guarantee that any amount of peer reviews would find a problem like this, because by definition the peers are going to be as clueless as the one who had to crib from the internet. If it’s a security issue it really needs to be reviewed by a security expert, and if you are copying random snippets I would have thought a lawyer should be checking it.
Worth note, a wrong piece of code is more likely to be mentioned and quoted around the interwebs, precisely because it’s wrong. So I’d guess popular code snipets on google have in average more chances of being wrong than those on page two.
(I only skimmed the comments, so forgive me if I’m being redundant).
The irony in this is that someone will inevitably end up here for
sample encryption code and blindly copy/paste your flawed code.
Copy/paste without using your brain is definetly not the good thing to do, but I strongly believe than it is very instructive to read other’s mistake.
This is why I’ve designed a mini website to show the most common programming error: http://www.badprogramming.com.
I think the real problem with your bad code is not that people will cut and paste code from the internet without trying to understand it. It’s that they will waste time trying to understand something that’s broken, and perhaps drawing incorrect conclusions in the meantime.
This is one of the main reasons I prefer open source libraries to random code snippets. Open source code is tested and updated, nobody updates or maintains code snippets.
Thou shall always try and use a respected, peer reviewed piece of software to solve your security problem before rolling your own. If you are rolling your own continue down this list.
Thou shall not roll their own cryptosystem - but if you really must:
Thou shall not create their own cipher.
Thou shall not use ECB.
Thou shall always use a MAC when using a cipher.
Thou shall always use time-stamps and unique message counters to avoid replays.
Though shall always MAC all previous messages together with the new message, if possible.
Thou shall not use MD5 or SHA-1.
Thou shall not use DES-56.
Thou shall understand the difference between a stream cipher and a block cipher.
Thou should hire someone who knows what they’re doing to analyse their system.
@MW -
Yeah, what Jeff said. Arguments certainly are boring when you assume a stupid argument.
Here’s my point - that Debian OpenSSL problem was found and fixed in 2006. The bad code Jeff and team used is still floating around out there, and won’t be fixed.
There was a personal failure as well – repeating the broken code in a well-linked-to-blog without clearly indicating close to (or in) the code that “HEY! THIS IS BROKEN”.
You did it for drama and suspense sure, but it’s still irresponsible and a personal failure.