Banned Cryptography Removed from the Codebase

Removing banned cryptographic algorithms from the code is much harder than simply replacing banned APIs because it’s harder to confine the change. When you replace a banned API, the change is usually a one-line change. Changing a cryptographic algorithm possibly requires new key sizes, different buffer sizes for holding hash function results, and so on. Then there’s the problem of interoperability and compatibility with standards, different operating systems or a competing product, or perhaps just an older version of your product. And it all needs thorough testing! In Windows Vista we removed many instances of the security-related MD4 and MD5 hash algorithms because they are woefully insecure by today’s standards. We could not remove all instances of MD4 and MD5 because of backward compatibility; for example, the digest authentication system requires MD5. This distinct lack of crypto-agility, or the ability to change a cryptographic algorithm quickly, is worrying. We’ll explain cryptographic agility in more detail in Chapter 7, “Cryptographic Enhancements” and the list of banned cryptographic algorithms is listed at http://msdn.microsoft.com/security.

Important  

You only need to replace security-related calls to banned cryptographic algorithms. For example, if you use MD5 as a glorified checksum, then replacing it with SHA512 is probably overkill. Of course, MD5 is insecure when used to sign a document.

All instances of banned cryptographic algorithms should be triaged to determine if it is appropriate to change the algorithm to something more secure. Unfortunately, backward compatibility plays a large influence in leaving the algorithms in the code. With that said, it is important that you come up with a plan to support crypto-agility.