Edit

CA5351 Do Not Use Broken Cryptographic Algorithms

  • Article
Property Value
Rule ID CA5351
Title Do Not Use Broken Cryptographic Algorithms
Category Security
Fix is breaking or non-breaking Non-breaking
Enabled by default in .NET 8 No

Note

This warning was last updated on November 2015.

Cause

Hashing functions such as MD5 and encryption algorithms such as DES and RC2 can expose significant risk and may result in the exposure of sensitive information through trivial attack techniques, such as brute force attacks and hash collisions.

The cryptographic algorithms list below are subject to known cryptographic attacks. The cryptographic hash algorithm MD5 is subject to hash collision attacks. Depending on the usage, a hash collision may lead to impersonation, tampering, or other kinds of attacks on systems that rely on the unique cryptographic output of a hashing function. The encryption algorithms DES and RC2 are subject to cryptographic attacks that may result in unintended disclosure of encrypted data.

Rule description

Broken cryptographic algorithms are not considered secure and their use should be discouraged. The MD5 hash algorithm is susceptible to known collision attacks, though the specific vulnerability will vary based on the context of use. Hashing algorithms used to ensure data integrity (for example, file signature or digital certificate) are particularly vulnerable. In this context, attackers could generate two separate pieces of data, such that benign data can be substituted with malicious data, without changing the hash value or invalidating an associated digital signature.

For encryption algorithms:

  • DES encryption contains a small key size, which could be brute-forced in less than a day.

  • RC2 encryption is susceptible to a related-key attack, where the attacker finds mathematical relationships between all key values.

This rule triggers when it finds any of the above cryptographic functions in source code and throws a warning to the user.

How to fix violations

Use cryptographically stronger options:

When to suppress warnings

Do not suppress a warning from this rule, unless it's been reviewed by a cryptographic expert.

Suppress a warning

If you just want to suppress a single violation, add preprocessor directives to your source file to disable and then re-enable the rule.

#pragma warning disable CA5351
// The code that's violating the rule is on this line.
#pragma warning restore CA5351

To disable the rule for a file, folder, or project, set its severity to none in the configuration file.

[*.{cs,vb}]
dotnet_diagnostic.CA5351.severity = none

For more information, see How to suppress code analysis warnings.

Pseudo-code examples

The following pseudo-code samples illustrate the pattern detected by this rule and possible alternatives.

MD5 Hashing Violation

using System.Security.Cryptography;
...
var hashAlg = MD5.Create();

Solution:

using System.Security.Cryptography;
...
var hashAlg = SHA256.Create();

RC2 Encryption Violation

using System.Security.Cryptography;
...
RC2 encAlg = RC2.Create();

Solution:

using System.Security.Cryptography;
...
using (AesManaged encAlg = new AesManaged())
{
  ...
}

DES Encryption Violation

using System.Security.Cryptography;
...
DES encAlg = DES.Create();

Solution:

using System.Security.Cryptography;
...
using (AesManaged encAlg = new AesManaged())
{
  ...
}