Hacker News Reader

Comment by commandlinefan | Hacker News Reader

Well I don't fully follow what "digital signatures inside Postgres" really means, but if it means essentially the same thing as digital signatures in, say, a Java program or a Python program or any other Turing-complete programming language, what about... writing code? Ha! I said it! Roll your own crypto! The title is "Programming: mostly a hate story", but it should be "Managing dependencies and trying to live up to this ridiculous pipe dream of reusing code and never writing any of your own because somebody on the internet said 'never roll your own': Mostly a hate story"

View on HN

The case against rolling your own crypto is that bugs can hide in crypto software without symptoms. Everything will seem to function perfectly. The verifier will o.k. valid signatures and reject invalid ones. The signatures themselves will look like gibberish to the eye.

But the bug will still be there, waiting for an actual attack.

Unless you do it right.

The issue with this is the same thing that happens with all sorts of data breaches, regardless of whether it was caused by negligence.

Of course there's no problem if you do it right. It's just that guaranteeing you did it right is never possible with 100% certainty if you wrote the code, evaluated the code, and published the code.

More eyes means less mistakes. More hands makes less work. If you roll your own templating system, and you mess up, then some text on a page is displayed wrong. If you roll your own crypto to protect customer data and you mess up, whoops, that customer data is out there.

I agree that people are often too zealous about "don't do it yourself", whether in the name of security or preventing duplicate work. md5 hashing unsalted passwords is bad, but so is critically misconfiguring an off-the-shelf password tool you didn't understand. Not Invented Here Syndrome is bad, but so is breaking the entire internet because you didn't want to write 20 lines of NPM left-pad yourself.

That said, I think there's still a major difference between roll-your-own-crypto and other "unless you do it right" topics. Securely storing passwords and preventing XSS are things that can look ok and be insecure unless you do it right, but I'm not (always) against people (carefully) handling those things themselves. Rolling your own signatures or encryption are infamous because a "best practices" list and good code review won't save you; even if you root out all the actual bugs, your process can still be cripplingly vulnerable. As Schneier said, anyone can create an alogorithm they can't compromise.

Did you ever typo a character in your code and didn't notice, causing a fast compile or runtime error, then promptly fixed it? If it had compiled and ran with no visible symptoms, would you ever catch that typo? That's the level of gotcha in rolling your own crypto.

Yeah, sort of like playing the lottery is a bad investment, unless you win.

Author here. This was an unusual setup. The database server is directly accessible to users but they were only given INSERT and SELECT privileges on the table. The users need flexible querying with SQL so that they can use existing BI tools like Metabase.

This system is minimal, is running almost perfectly and has > 100 happy users. There isn't sufficient justification to introduce custom code layer and break all the existing functionality.

pgcrypto already does support PGP encryption after all, just not ECDSA.

>Ha! I said it! Roll your own crypto!

Isn't this the #1 anti-pattern in cryptography?

Reply on news.ycombinator.com