Suppose you’re looking at a tool or library that uses cryptography. At this point in time, the majority of developers unfortunately don’t have the skill set required to use cryptography securely. With that in mind, how can you tell whether or not this tool is safe to use?
There are a number of “red flags” that I use to quickly get a sense of the author’s familiarity with cryptography. If I spot any of them, I know that this software isn’t safe to use, and I move on to the next option.
This is a heuristic that I use to help estimate the author’s proficiency with cryptography. Some red flags do not indicate vulnerabilities themselves – instead, they indicate with high probability that serious problems lurk elsewhere in the code.
Here’s a non-exhaustive list of red flags:
- Rijndael: This block cipher was renamed “AES” when it won the AES competition in 2001. A lot has happened in the cryptography world since 2001, so code or documentation that says “Rijndael” instead of “AES” is definitely a red flag.
- One-time pad: Oh boy, this one probably deserves its own blog post. Suffice it to say that most (all?) “one-time pad” implementations are actually messy concoctions of homemade crypto, unsuitable for real-world use.
- Obselete ciphers: DES, 3DES, Blowfish, Twofish, Serpent, RC4. Some of these are broken, all of them have gone way out of style.
- Obselete hash functions: MD4, MD5, SHA-1, RIPEMD. Exceptions: HMAC-MD5 and HMAC-SHA1 are not necessarily a red flag.
- AES-ECB, or any other block cipher in ECB mode.
- RSA or Diffie-Hellman under 1024 bits: 1024 bits is almost never enough, so less than that is a guaranteed red flag. 256-bit RSA is an immediate fail.
It’s important to note that the absence of red flags does not at all indicate security. This is just my “fizzbuzz” for crypto code, which helps me to decide for or against further investigation.