It's conventional wisdom to software developers that you should never write your own cryptography code because too many things can go wrong. You can't test it at scale, it might be riddled with bugs, there are so many libraries already doing the same thing, and last but not least, it's a lot of code to write. You'll develop carpal tunnel before you finish the helper functions.
But you're different. You're a really good developer. You dream in binary, and stay up to date on your code katas. For developers like you, it's okay to write your own cryptography library. Besides, it's easier than ever before to write it. Advances in programming languages, A.I. models, and CPU instruction sets have made it almost trivial to write your own cryptography library. And the reasons to do it are practically endless. Reason 1: It's your code. Reasons 2-7: Others, probably.
After speaking with the top minds of a generation, we have created a list of all the reasons it's okay to develop your own cryptography library now that's it's @(dateTime.Year). Because it was just too hard way back in @(dateTime.Year-1). The list enumerates below:
- There are more websites to help you. In the past you needed large textbooks only sold on college campuses written by the professor teaching the one course on cryptography.
- Your A.I. agent will stop you before you do something really bad.
- You'll write it in a modern programming language, not some legacy language like C# or Java.
- If it's an open project, it's easy to create a cute website for the library. You can host it on GitHub Pages, when that's not down.
- If it's an internal project, no one else will see the code. That makes it practically unhackable. Practically.
- You can make extra-secure decisions, like running the code in a container.
- Your code will be new. Automatically making it better. Greenfield is better than legacy any day of the week (including Saturdays!).
With all that said, I think we can all agree that the next time you want to write your own crypto code, you shouldn't stop yourself. You should jump headfirst into the world of asymmetric encryption, digital signatures, elliptic curve pairings, and Σ-protocols (whatever those are).
All possible attacks won't affect you. No need to worry about timing attacks, buffer overflows, or rainbow tables. Just think, "I can do this and no one else can."