Is Open-Source Cryptography Really Secure?
The purpose of cryptography is to keep information private, and the purpose of open-source is to make code public… So we shouldn’t open-source our cryptography algorithms right?
I’ve been asked this several times by multiple people so I figured it is a subject worth addressing. Many developers seem to be under the impression that crypto and security systems (the application-specific implementation of cryptosystems) are more secure if their details are kept private.
This can’t be further from the truth
According to Kerckhoffs’s principle, also known as Shannon’s maxim:
The enemy knows the system. One ought to design systems under the assumption that the enemy will immediately gain full familiarity with them.
In other words, attackers should be allowed to know our algorithms inside and out. The only secret we don’t share with attackers should be the private keys used at runtime.
There are several reasons as to why this is a good rule to live by, let’s examine each one.
1. Obfuscation Isn’t Encryption
If a developer is operating under the assumption that attackers won’t know about the details of their code, they may be tempted to try to build in security that is dependent on that.
For example, they may encode data in a confusing way instead of encrypting it, assuming that the enemy will think it is encrypted, or not be able to guess HOW it was encoded.
BAD.
When something needs to be kept secret, always encrypt.

2. You Probably Suck
If you roll your own crypto, you are likely to overlook vulnerabilities that have been accounted for in open-source versions. By the way, I don’t mean that you specifically suck at writing crypto, I mean that no one person (or organization) can reasonably be responsible for vetting all possible attack vectors. Open-source allows the worldwide developer community to help expose problems with the code.

Not only are you likely to have problems in underlying mathematics and algorithms, but it is likely that your application-level implementation will also have vulnerabilities. There are no industry standard best practices to follow for your custom algorithms.
3. Get New Updates
By using popular crypto libraries that are regularly updated, your code won’t be vulnerable to the recently discovered attacks on the algorithms you are using.
Take advantage of the community, and give back by contributing when you can!
Go: Golang.org
Node: Node.js
Python: Python
Related Articles
Intro to The AES-256 Cipher
Jan 02, 2020 by Lane Wagner - Boot.dev co-founder and backend engineer
AES, or “Advanced Encryption Standard”, is an encryption specification that uses the Rijndael cipher as its symmetric key ciphering algorithm. AES encrypts a message with a private key, and no one but the key holder can decrypt the message. A great example of a good use-case for AES-256 is encrypting all the data on the hard drive of a computer when it’s not in use.
Basic Intro to Key Derivation Functions
Dec 30, 2019 by Lane Wagner - Boot.dev co-founder and backend engineer
A Key Derivation Function, or KDF, is a cryptographic algorithm that derives one or more secret keys from a secret value. If you’ve ever needed to store a password in a database or create a private key from a password, you may have used a KDF. Some examples of popular KDFs are Argon2, Scrypt, and PBKDF2.
How to Secure Your Bitcoin
Aug 30, 2019 by Lane Wagner - Boot.dev co-founder and backend engineer
If you’re new to Bitcoin and cryptocurrency, you may have heard the common phrase not your keys not your coins. While self-custody isn’t for everyone, it’s the only way to truly have exclusive control over your funds. If that’s what you’re into, read on.
Security in Dependencies
Aug 21, 2019 by Lane Wagner - Boot.dev co-founder and backend engineer
Choosing the right dependencies is a difficult task. Assuming the developer of an application is the best programmer in the world, the “best” thing to do would be to write the entire codebase alone. This would eliminate the bugs, vulnerabilities, and malicious intrusions of inferior developers.