NIST approved cryptographic hash functions standard
Approved hash functions are defined in FIPS 180.
OWASP Cheat Sheets · all subjects
key management & cryptography
27 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Hash function use cases in cryptography
Hash functions are used as components in digital signature algorithms (FIPS 186), Keyed-Hash Message Authentication Codes (HMAC) (FIPS 198), key-derivation functions (NIST SP 800-56A, 800-56B, 800-56C and 800-108), and random number generators (NIST SP 800-90A). They are building blocks for data authentication and integrity services, message compression for digital signatures, key derivation in key-establishment algorithms, and deterministic random number generation.
NIST basic classes of approved cryptographic algorithms
According to NIST SP 800-57 Part 1, there are three basic classes of approved cryptographic algorithms: hash functions, symmetric-key algorithms, and asymmetric-key algorithms. These classes are defined by the number of cryptographic keys that are used in conjunction with the algorithm.
Symmetric-key algorithm definition and uses
Symmetric-key algorithms (also known as secret-key algorithms) transform data in a way that is fundamentally difficult to undo without knowledge of a secret key. The key is 'symmetric' because the same key is used for a cryptographic operation and its inverse (e.g., encryption and decryption). They are used to provide data confidentiality, authentication and integrity services in the form of Message Authentication Codes (MACs), as part of key-establishment processes, and to generate deterministic random numbers.
Asymmetric-key algorithm definition and uses
Asymmetric-key algorithms, commonly known as public-key algorithms, use two related keys (a key pair): a public key and a private key. The public key may be known by anyone; the private key should be under the sole control of the entity that 'owns' the key pair. Knowledge of the public key does not reveal the private key. They are used to compute digital signatures, establish cryptographic keying material, and generate random numbers.
Message Authentication Codes (MACs) definition and purpose
Message Authentication Codes (MACs) provide data authentication and integrity. A MAC is a cryptographic checksum on data that provides assurance that the data has not changed and that the MAC was computed by the expected entity. MACs can provide a recipient with assurance that the originator of the data is a key holder (an entity authorized to have the key).
Digital signatures standard specification
Digital signatures are used to provide authentication, integrity, and non-repudiation. FIPS 186 specifies algorithms that are approved for the computation of digital signatures.
Key-wrapping keys definition
Symmetric key-wrapping keys are used to encrypt other keys using symmetric-key algorithms. Key-wrapping keys are also known as key encrypting keys.
Elliptic Curve key length requirements for modern security
When moving to Elliptic Curve-based algorithms, choose a key length that meets or exceeds the comparative strength of other algorithms in use within your system. Refer to NIST SP 800-57 Table 2 for specific guidance.
Key encryption strength requirement
When encrypting keys for storage or distribution, always encrypt a cryptographic key with another key of equal or greater cryptographic strength.
Key generation cryptographic module compliance
Cryptographic keys shall be generated within a cryptographic module with at least FIPS 140-2 or FIPS 140-3 compliance. Any random value required by the key-generating module shall be generated within that module; the Random Bit Generator shall be implemented within a cryptographic module with at least FIPS 140-2 or FIPS 140-3 compliance. Hardware cryptographic modules are preferred over software cryptographic modules for protection.
Key distribution security requirements
Generated keys shall be transported (when necessary) using secure channels and shall be used by their associated cryptographic algorithm within at least a FIPS 140-2 or FIPS 140-3 compliant cryptographic module.
Key storage best practices
Keys must be protected on both volatile and persistent memory, ideally processed within secure cryptographic modules. Keys should never be stored in plaintext format. All keys must be stored in a cryptographic vault, such as a hardware security module (HSM) or isolated cryptographic service. If storing keys in offline devices/databases, encrypt keys using Key Encryption Keys (KEKs) prior to export, where KEK length and algorithm should be equivalent to or greater in strength than the keys being protected. Ensure keys have integrity protections applied while in storage (consider dual purpose algorithms that support encryption and Message Code Authentication). Ensure that keys and cryptographic operations are done inside the sealed vault. Standard application level code should never read or use cryptographic keys; use key management libraries instead.
Key backup and escrow requirements
Secure key backup capability is essential, especially for applications that support data at rest encryption for long-term data stores. When backing up keys, ensure the database used to store keys is encrypted using at least a FIPS 140-2 or FIPS 140-3 validated module. Never escrow keys used for performing digital signatures, but consider escrowing keys that support encryption. Escrow can be performed by the Certificate Authority (CA) or key management system, or separate APIs may be needed.
Single key usage principle
According to NIST, a single key should be used for only one purpose (e.g., encryption, authentication, key wrapping, random number generation, or digital signatures). Using the same key for two different cryptographic processes may weaken the security provided by one or both processes. Limiting key use limits the damage if the key is compromised. Some uses of keys interfere with each other, as retention requirements and time lengths of key use may differ for different data types.
Memory management for keys
Keys stored in memory for a long time can become 'burned in'. This can be mitigated by splitting the key into components that are frequently updated. Loss or corruption of the memory media on which keys and/or certificates are stored requires recovery planning according to NIST SP 800-57.
Perfect Forward Secrecy via ephemeral keys
Ephemeral keys can provide perfect forward secrecy protection, which means a compromise of the server's long term signing key does not compromise the confidentiality of past sessions.
Cryptographic module definition
According to NIST SP 800-133, cryptographic modules are the set of hardware, software, and/or firmware that implements security functions (including cryptographic algorithms and key generation) and is contained within a cryptographic module boundary to provide protection of the keys.
Key compromise implications
Key compromise can mean: (1) unauthorized disclosure of a key used for confidentiality protection means all information encrypted by that key could be exposed; disclosure of a Certificate Authority's private signature key means an adversary can create fraudulent certificates and CRLs; (2) compromise of key integrity means the key is incorrect or has been modified or substituted, questioning the integrity of all protected information; (3) compromise of key usage or application association means the key could be used for the wrong purpose or wrong application; (4) compromise of key association with owner means identity cannot be assured; (5) compromise of key association with other information means the association is lost or incorrect, causing cryptographic services to fail or security to be compromised.
Key compromise prevention measures
Limiting the amount of time a symmetric or private key is in plaintext form; preventing humans from viewing plaintext symmetric and private keys; restricting plaintext keys to physically protected containers (key generators, key-transport devices, key loaders, cryptographic modules, key-storage devices); using integrity checks to ensure key integrity has not been compromised; employing key confirmation to help ensure the proper key was established; establishing an accountability system tracking each access to keys in plaintext form; providing cryptographic integrity checks on the key (using MAC or digital signature); using trusted timestamps for signed data; destroying keys as soon as they are no longer needed.
Compromise-recovery plan required contents
A compromise-recovery plan must contain: (1) identification and contact info of personnel to notify; (2) identification and contact info of personnel to perform recovery actions; (3) the re-key method; (4) an inventory of all cryptographic keys and their use (e.g., location of all certificates in a system); (5) education of all appropriate personnel on recovery procedures; (6) identification and contact info of all personnel needed to support recovery procedures; (7) policies that key-revocation checking be enforced to minimize compromise effect; (8) monitoring of re-keying operations to ensure all required operations are performed for all affected keys; (9) any other recovery procedures including physical inspection of equipment, identification of compromised information, identification of invalid signatures, distribution of new keying material if required.
Trust store security controls
Design controls to secure the trust store against injection of third-party root certificates, with access controls managed and enforced on an entity and application basis. Implement integrity controls on objects stored in the trust store. Do not allow export of keys held within the trust store without authentication and authorization. Setup strict policies and procedures for exporting key material from applications to network applications and other components. Implement a secure process for updating the trust store.
Cryptographic library requirements
Use only reputable crypto libraries that are well maintained and updated, as well as tested and validated by third-party organizations (e.g., NIST/FIPS).
Key accountability and audit requirements
Accountability involves identification of those who have access to or control cryptographic keys throughout their lifecycles. The key management system should account for all individuals able to view plaintext cryptographic keys. More sophisticated systems may account for all individuals authorized to access or control any cryptographic keys, whether in plaintext or ciphertext form. Accountability aids in determining when compromise occurred and which individuals were involved, protects against compromise (as individuals with access know it is known), and helps in recovery by knowing where the key was used and what data/keys were protected. Principles include: uniquely identifying keys, identifying the key user, identifying dates and times of key use and protected data, identifying other keys protected by the key. Two types of audit should be performed: (1) security plan and supporting procedures should be periodically audited to ensure they continue supporting the Key Management Policy (NIST SP 800-57 Part 2); (2) protective mechanisms should be periodically reassessed for security level provided and effectiveness. Human actions using, operating and maintaining the system should be reviewed to verify continued compliance with established security procedures. Highly unusual events should be noted and reviewed as possible indicators of attempted attacks.
Keep npm packages up-to-date with npm audit
Regularly update packages to patch known vulnerabilities. Starting with npm v6, use `npm audit` to identify vulnerable packages and `npm audit fix` to upgrade affected packages. Also use OWASP Dependency-Check and Retire.js to check for known vulnerabilities. Using components with known vulnerabilities is in the OWASP Top 10.
Public-key signature key management
Do not reuse the key pair for another purpose (e.g., for encryption). Using the same key for authenticating different types of JWTs is fine as long as this does not introduce a risk of token type confusion. Do not publish the private key.
Hardware-backed key storage for authenticators
For many authenticators including platform passkeys, the private key is generated and stored by the operating system's secure key manager. Keys may be protected using hardware-backed components such as Trusted Platform Module on Windows, Secure Enclave on Apple devices, Android Keystore/StrongBox on Android, or software-based mechanisms. Private keys are typically non-exportable and bound to the authenticator.