Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

These are the development principles of writing Cryptography in Golang. I find it cool that they take the design of Golang Cryptography seriously. There are four design principles: secure, safe, practical, and modern.

Secure is obvious but important to note. This is achieved by reducing complexity, making it readable, and conducting extensive testing and code review. When a big change is made, it is only accepted in the Cryptography libraries if there are enough maintainer resources to perform an ongoing security review. They get code professionally reviewed from time to time, such as with the FIPS 140-3 module.

Safe is the second one. The goal is to make unsafe functionality hard to use and have very explicit documentation on it. By default, only secure versions are used. Since this is done for most use cases, this limits the opportunities for issues.

Practical is the third. Libraries should provide developers with mechanisms to do what they want to do easily. By supporting common patterns as first-party, the library is easy and safe to use. This is super unique compared to other libraries that just expose RSA and AES functions directly. Instead, the library has a Hash() function that defaults to the most secure and up-to-date hash function. All of this takes away the decision-making of algorithms and implementation from the developers, which is good. I love this approach!

Finally, the cryptography should be modern. All primitives should be modern and up-to-date. Functionally, a legacy function should be marked as deprecated. Because of the slow development process, third-party projects will implement things first but that's okay. I personally don't like this a ton -- somebody is going to implement this functionality, so it should be the people who know it best. By waiting for the issues to stop, you're preventing issues from creeping into your library but you're also leaving users at risk.

The Practical section has an interesting quote: "Note that performance, flexibility and compatibility are only goals to the extent that they make the libraries useful, not as absolute values in themselves."