Non-Compliant, So What?

Cryptography feels like black magic. When auditing code at QuarksLab, there are many little things that they report but don't just kill the security of the implementation immediately. In this article, they explain the little things and why they're still important to fix. Not standard means that something out of the ordinary is being done. For instance, using a untested/less used primitive like a MARs cipher. Although they may not pose a threat at the moment, things that are not battle tested may have unexpected issues. Non-standard usage is using a primitive in a weird/wrong way. An common example of this is using a bad random number generator. Or, generating an IV via a key generation function. Next, they talk about things that are Low security, still technically secure. These are things that have no impact at the moment but may in the future or if changes are made. An example of this is using RSA keys that are smaller than the maximum amount that has been currently factored or using a non-standard amount of iterations (200 vs 210 for instance). The most interesting to me was safety net saves all. This is where there is a vulnerability in part of the implementation but some feature, intended or unintended, or use case saves the day. This is akin to having multiple walls that are low security. I've seen the safety net saves all on multiple occasions but absolutely hate it. A section of code may be secure given the current use case but insecure in another. Down the road, the developers may use it in the insecure way, forgetting what was said about it. At the end, they mention that some clients have asked them to change the attacker model to make the system feel more secure. For instance, if the server in the middle was fully trusted, using a third party solution or a plain rewrite. Overall, a good post on minimal impact issues and how to talk about them with clients.