Use the following guidelines to ensure that your application uses algorithms, parameters, and key lengths that adhere to strict standards for encryption:

• Always use well-tested and industry-accepted cryptographic algorithms.

• In case an organization does not have approved cryptographic algorithms or key lengths, check the algorithm against the FIPS 140-3 validation list. Annex A Section 14 provides a list of approved security algorithms applicable to FIPS 140-3.

  - For example, Data Encryption Standard (DES) is not considered secure and an alternative such as Advanced Encryption Standard (AES) should be used for symmetric encryption.
  

• Use any unapproved algorithms only in conjunction with approved algorithms and implement it in a manner that does not reduce the equivalent cryptographic key strength provided by the approved algorithms.

• Do not use encoding and compression algorithms instead of encryption algorithms. For example, a common mistake is using a type of encoding to protect data, such as Base64 encoding. Base64 encoding is not an encryption algorithm and does not protect data. It can be reversed using Base64 decoding without the need for any additional shared knowledge (such as knowledge of a shared key). Techniques such as Base64, ROT13, GZip, LZW, Huffman coding, etc., should not be used for protecting data in place of encryption algorithms.
• Use a key management system that provides features for secure generation, distribution, storage, change, and retirement or revocation of cryptographic keys.
• Always initialize the initialization vectors (IVs) used in the algorithms with secure random values.
• Always use cryptographically secure random IVs when using a block cipher in cipher-block chaining (CBC) mode.

  - A predictable IV can cause an affected system to be vulnerable to plaintext attacks. 
  - Use encryption in CBC mode instead of Electronic Codebook (ECB) mode.
  

• Always incorporate an industry-accepted standard padding method, where padding is used prior to or during encryption.

• Do not reuse the same cryptographic key for multiple purposes.
• Use only approved, collision-resistant hash algorithms and methods with a salt value of appropriate strength that is generated using a secure random number generator.

Imported from SD Elements: https://redhat.sdelements.com/bunits/psse-secure-development/group-1-foundational-platform-offering-openshift/azure-storage-azcopy/tasks/phase/specifications/161-T60/

Training Modules

Defending Web Applications

• Password Management
• Protecting API Traffic in Transit

Defending .NET

• AES decryption
• AES encryption

Secure Software Design

• Designing Confidentiality

OWASP Top 10 2021

• Clear-text communication

Defending Java

• Java Cryptography Architecture (JCA) and Secure Randomness