V11.3.1 Avoid insecure block modes and weak padding
Requirement 11.3.1 applies at Level 1. It requires verification that insecure block modes such as ECB and weak padding schemes such as PKCS#1 v1.5 are not used.
asvs/v11-cryptography
48 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
V11.1.1 Cryptographic key management policy and lifecycle
Requirement 11.1.1 applies at Level 2. It requires verification that there is a documented policy for management of cryptographic keys and a cryptographic key lifecycle that follows a key management standard such as NIST SP 800-57. This should include ensuring that keys are not overshared, for example with more than two entities for shared secrets and more than one entity for private keys.
V11.1.2 Cryptographic inventory maintenance and documentation
Requirement 11.1.2 applies at Level 2. It requires verification that a cryptographic inventory is performed, maintained, regularly updated, and includes all cryptographic keys, algorithms, and certificates used by the application. It must also document where keys can and cannot be used in the system, and the types of data that can and cannot be protected using the keys.
V11.1.3 Cryptographic discovery mechanisms
Requirement 11.1.3 applies at Level 3. It requires verification that cryptographic discovery mechanisms are employed to identify all instances of cryptography in the system, including encryption, hashing, and signing operations.
V11.1.4 Cryptographic inventory with migration plan
Requirement 11.1.4 applies at Level 3. It requires verification that a cryptographic inventory is maintained. This must include a documented plan that outlines the migration path to new cryptographic standards, such as post-quantum cryptography, in order to react to future threats.
V11.2.1 Industry-validated cryptographic implementations
Requirement 11.2.1 applies at Level 2. It requires verification that industry-validated implementations including libraries and hardware-accelerated implementations are used for cryptographic operations.
V11.2.2 Crypto agility for algorithm upgrades
Requirement 11.2.2 applies at Level 2. It requires verification that the application is designed with crypto agility such that random number, authenticated encryption, MAC, or hashing algorithms, key lengths, rounds, ciphers and modes can be reconfigured, upgraded, or swapped at any time to protect against cryptographic breaks. Similarly, it must also be possible to replace keys and passwords and re-encrypt data. This allows for seamless upgrades to post-quantum cryptography once high-assurance implementations of approved PQC schemes or standards are widely available.
V11.2.3 Minimum 128-bits of cryptographic security
Requirement 11.2.3 applies at Level 2. It requires verification that all cryptographic primitives utilize a minimum of 128-bits of security based on the algorithm, key size, and configuration. For example, a 256-bit ECC key provides roughly 128 bits of security where RSA requires a 3072-bit key to achieve 128 bits of security.
V11.2.4 Constant-time cryptographic operations
Requirement 11.2.4 applies at Level 3. It requires verification that all cryptographic operations are constant-time, with no short-circuit operations in comparisons, calculations, or returns, to avoid leaking information.
V11.2.5 Cryptographic modules fail securely
Requirement 11.2.5 applies at Level 3. It requires verification that all cryptographic modules fail securely, and errors are handled in a way that does not enable vulnerabilities, such as Padding Oracle attacks.
V11.3.2 Use only approved ciphers and modes
Requirement 11.3.2 applies at Level 1. It requires verification that only approved ciphers and modes such as AES with GCM are used.
V11.3.3 Protect encrypted data against unauthorized modification
Requirement 11.3.3 applies at Level 2. It requires verification that encrypted data is protected against unauthorized modification preferably by using an approved authenticated encryption method or by combining an approved encryption method with an approved MAC algorithm.
V11.3.4 Nonces and initialization vectors usage restrictions
Requirement 11.3.4 applies at Level 3. It requires verification that nonces, initialization vectors, and other single-use numbers are not used for more than one encryption key and data-element pair. The method of generation must be appropriate for the algorithm being used.
V11.3.5 Encrypt-then-MAC mode for combined algorithms
Requirement 11.3.5 applies at Level 3. It requires verification that any combination of an encryption algorithm and a MAC algorithm is operating in encrypt-then-MAC mode.
V11.4.1 Use only approved hash functions for cryptography
Requirement 11.4.1 applies at Level 1. It requires verification that only approved hash functions are used for general cryptographic use cases, including digital signatures, HMAC, KDF, and random bit generation. Disallowed hash functions such as MD5 must not be used for any cryptographic purpose.
V11.4.2 Password storage using key derivation functions
Requirement 11.4.2 applies at Level 2. It requires verification that passwords are stored using an approved, computationally intensive, key derivation function also known as a password hashing function, with parameter settings configured based on current guidance. The settings should balance security and performance to make brute-force attacks sufficiently challenging for the required level of security.
V11.4.3 Hash function bit-length requirements for data integrity
Requirement 11.4.3 applies at Level 2. It requires verification that hash functions used in digital signatures, as part of data authentication or data integrity are collision resistant and have appropriate bit-lengths. If collision resistance is required, the output length must be at least 256 bits. If only resistance to second pre-image attacks is required, the output length must be at least 128 bits.
V11.4.4 Key derivation functions for password-based secrets
Requirement 11.4.4 applies at Level 2. It requires verification that the application uses approved key derivation functions with key stretching parameters when deriving secret keys from passwords. The parameters in use must balance security and performance to prevent brute-force attacks from compromising the resulting cryptographic key.
V11.5.1 CSPRNG with minimum 128-bits entropy
Requirement 11.5.1 applies at Level 2. It requires verification that all random numbers and strings which are intended to be non-guessable must be generated using a cryptographically secure pseudo-random number generator (CSPRNG) and have at least 128 bits of entropy. Note that UUIDs do not respect this condition.
V11.5.2 Random number generation under heavy demand
Requirement 11.5.2 applies at Level 3. It requires verification that the random number generation mechanism in use is designed to work securely, even under heavy demand.
V11.6.1 Approved algorithms for public key operations
Requirement 11.6.1 applies at Level 2. It requires verification that only approved cryptographic algorithms and modes of operation are used for key generation and seeding, and digital signature generation and verification. Key generation algorithms must not generate insecure keys vulnerable to known attacks, for example, RSA keys which are vulnerable to Fermat factorization.
V11.6.2 Approved algorithms for key exchange
Requirement 11.6.2 applies at Level 3. It requires verification that approved cryptographic algorithms are used for key exchange such as Diffie-Hellman with a focus on ensuring that key exchange mechanisms use secure parameters. This will prevent attacks on the key establishment process which could lead to adversary-in-the-middle attacks or cryptographic breaks.
V11.7.1 Full memory encryption for sensitive data
Requirement 11.7.1 applies at Level 3. It requires verification that full memory encryption is in use that protects sensitive data while it is in use, preventing access by unauthorized users or processes.
V11.7.2 Data minimization and encryption after use
Requirement 11.7.2 applies at Level 3. It requires verification that data minimization ensures the minimal amount of data is exposed during processing, and ensure that data is encrypted immediately after use or as soon as feasible.
V17.2.1 DTLS certificate key management
Requirement 17.2.1 applies at Level 2. The key for the Datagram Transport Layer Security (DTLS) certificate must be managed and protected based on the documented policy for management of cryptographic keys. This applies to media servers that host their own WebRTC media servers such as Selective Forwarding Units (SFUs), Multipoint Control Units (MCUs), recording servers, or gateway servers.
V17.2.2 DTLS cipher suites and DTLS-SRTP protection profile
Requirement 17.2.2 applies at Level 2. The media server must be configured to use and support approved Datagram Transport Layer Security (DTLS) cipher suites and a secure protection profile for the DTLS Extension for establishing keys for the Secure Real-time Transport Protocol (DTLS-SRTP).
CBC mode padding verification requirement
When using CBC mode, verification of the padding must be performed in constant time.
Cryptographic mechanism approval levels
The ASVS cryptography appendix defines three levels of approval for cryptographic mechanisms: Approved (A) mechanisms can be used in applications; Legacy (L) mechanisms should not be used in new applications but may be used for compatibility with existing legacy applications or code; Disallowed (D) mechanisms must not be used because they are currently considered broken or do not provide sufficient security.
V11.1 cryptographic inventory tools for Level 3
For Level 3 of V11.1 Cryptographic Inventory and Documentation, static and dynamic scanning should be used to discover the use of cryptography in applications. Tools such as SAST and DAST may help with this, but dedicated tools may be needed for more comprehensive coverage. Freeware examples include CryptoMon (Network Cryptography Monitor using eBPF written in Python) and Cryptobom Forge Tool (generating comprehensive CBOMs from CodeQL outputs).
Cryptographic parameter security strength equivalencies
Equivalent security strengths for cryptographic systems per NIST SP 800-57 Part 1: 80-bit strength uses 2TDEA (symmetric), L=1024/N=160 (finite field), k=1024 (RSA), f=160-223 (ECC); 112-bit strength uses 3TDEA, L=2048/N=224, k=2048, f=224-255; 128-bit strength uses AES-128, L=3072/N=256, k=3072, f=256-383; 192-bit strength uses AES-192, L=7680/N=384, k=7680, f=384-511; 256-bit strength uses AES-256, L=15360/N=512, k=15360, f=512+. Where L is finite field public key size, N is finite field private key size, k is RSA key size, and f is ECC key size range.
Approved random value generation mechanisms
Approved (A status) random value generators include: /dev/random on Linux 4.8+ (using ChaCha20 stream per RFC7539, also found in iOS SecRandomCopyBytes and Android SecureRandom with correct settings); /dev/urandom on Linux kernel (providing high-quality entropy from hardware randomness); AES-CTR-DRBG per NIST SP800-90A (used in Windows CNG API BCryptGenRandom with BCRYPT_RNG_ALGORITHM); HMAC-DRBG per NIST SP800-90A; Hash-DRBG per NIST SP800-90A; getentropy() from OpenBSD, Linux glibc 2.25+, and macOS 10.12+ (providing secure random bytes directly from kernel entropy source).
HMAC-DRBG and Hash-DRBG underlying hash function requirement
When using HMAC-DRBG or Hash-DRBG for random value generation, the underlying hash function must be approved for this usage.
Approved symmetric cipher algorithms in preference order
Approved (A status) symmetric key cipher algorithms in order of preference: AES-256, Salsa20, XChaCha20, XSalsa20, ChaCha20, AES-192. Legacy (L status): AES-128. Disallowed (D status): 2TDEA, TDEA (3DES/3DEA), IDEA, RC4, Blowfish, ARC4, DES.
AES cipher modes approval status and restrictions
AES cipher modes in order of preference with approval status and restrictions: GCM (authenticated, NIST SP 800-38D, A status); CCM (authenticated, NIST SP 800-38C, A status); CBC (not authenticated, NIST SP 800-38A, L status, requires associated hashing MAC algorithm and Encrypt-Then-Hash method, must ensure constant-time padding verification); CCM-8 (authenticated, D status, 64-bit MAC tag insufficient for requirement 11.2.3); ECB (not authenticated, D status); CFB (not authenticated, D status); OFB (not authenticated, D status); CTR (not authenticated, D status). For disk encryption, encryption without authentication is typically accepted using XTS, XEX, or LRW modes, but disk encryption is out of scope for ASVS.
CBC mode encryption and authentication requirements
When using CBC mode, encrypted messages must be authenticated. For ANY use of CBC mode there MUST be an associated hashing MAC algorithm to validate the message. In general, the Encrypt-Then-Hash method must be applied, though TLS 1.2 uses Hash-Then-Encrypt instead. If this cannot be guaranteed, CBC must not be used. The only application where encryption without a MAC algorithm is allowed is disk encryption.
AES key wrapping requirements
For key wrapping operations, AES-256 MUST be used following NIST SP 800-38F and considering forward-looking provisions against quantum threat. Approved (A status) key wrapping modes: KW (NIST SP 800-38F) and KWP (NIST SP 800-38F). AES-192 and AES-128 MAY be used if the use case demands it, but the motivation MUST be documented in the entity's cryptography inventory.
Authenticated encryption requirement and schemes
With the exception of disk encryption, encrypted data must be protected against unauthorized modification using authenticated encryption (AE) scheme, usually an authenticated encryption with associated data (AEAD) scheme. Applications should preferably use an approved AEAD scheme or alternatively combine an approved cipher scheme and approved MAC algorithm with Encrypt-then-MAC construct. MAC-then-encrypt is still allowed for legacy application compatibility and is used in TLS v1.2 with old cipher suites.
Approved AEAD mechanisms
Approved (A status) AEAD mechanisms: AES-GCM (SP 800-38D), AES-CCM (SP 800-38C), ChaCha-Poly1305 (RFC 7539), AEGIS-256, AEGIS-128, AEGIS-128L, Encrypt-then-MAC. Legacy (L status): MAC-then-encrypt.
Approved hash functions for general use cases
Approved (A status) hash functions for general cryptographic use: SHA3-512, SHA-512, SHA3-384, SHA-384, SHA3-256, SHA-512/256, SHA-256, SHAKE256, BLAKE2s, BLAKE2b, BLAKE3. Legacy (L status) with restrictions: SHA-224, SHA-512/224, SHA3-224 (not suitable for HMAC, KDF, RBG, digital signatures), SHA-1 (not suitable for HMAC, KDF, RBG, digital signatures). Disallowed (D status): CRC (any length), MD4, MD5. Hash functions with less than 254 bits of output have insufficient collision resistance and must not be used for digital signature or applications requiring collision resistance, though they may be used for verification with legacy systems only.
Approved general key derivation functions
Approved (A status) general KDFs: HKDF (RFC 5869). Legacy (L status): TLS 1.2 PRF (RFC 5248). Disallowed (D status): MD5-based KDFs (RFC 1321), SHA-1-based KDFs (RFC 3174 and RFC 6194).
Approved password-based key derivation functions with parameters
Approved (A status) password-based KDFs with required parameters: argon2id (RFC 9106) with t=1 m≥47104 (46 MiB) p=1, t=2 m≥19456 (19 MiB) p=1, t≥3 m≥12288 (12 MiB) p=1; scrypt (RFC 7914) with p=1 N≥2^17 (128 MiB) r=8, p=2 N≥2^16 (64 MiB) r=8, p≥3 N≥2^15 (32 MiB) r=8; PBKDF2-HMAC-SHA-512 (iterations≥210,000); PBKDF2-HMAC-SHA-256 (iterations≥600,000). Legacy (L status): PBKDF2-HMAC-SHA-1 (iterations≥1,300,000).
V11.6 key exchange schemes security strength requirement
A security strength of 112 bits or above MUST be ensured for all key exchange schemes, and their implementation MUST follow the parameter choices specified for each scheme.
Approved key exchange schemes and parameters
Approved (A status) key exchange schemes: Finite Field Diffie-Hellman (FFDH) with L≥3072 and N≥256 (supports forward secrecy); Elliptic Curve Diffie-Hellman (ECDH) with f≥256-383 (supports forward secrecy). Disallowed (D status): Encrypted key transport with RSA-PKCS#1 v1.5 (no forward secrecy). Where k is RSA key size, L is finite field public key size, N is finite field private key size, and f is ECC key size range.
Key exchange schemes compliance requirement
Any new implementation of key exchange schemes MUST NOT use any scheme that is NOT compliant with NIST SP 800-56A and B and NIST SP 800-77. Specifically, IKEv1 MUST NOT be used in production.
Approved Diffie-Hellman groups
Approved (A status) Diffie-Hellman groups: P-224 (secp224r1), P-256 (secp256r1), P-384 (secp384r1), P-521 (secp521r1), K-233 (sect233k1), K-283 (sect283k1), K-409 (sect409k1), K-571 (sect571k1), B-233 (sect233r1), B-283 (sect283r1), B-409 (sect409r1), B-571 (sect571r1), Curve448, Curve25519, MODP-2048, MODP-3072, MODP-4096, MODP-6144, MODP-8192, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192.
Approved message authentication code algorithms
Approved (A status) MAC algorithms: HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, KMAC128, KMAC256, BLAKE3 (keyed_hash mode), AES-CMAC, AES-GMAC, Poly1305-AES. Legacy (L status): HMAC-SHA-1. Disallowed (D status): HMAC-MD5.
Approved digital signature algorithms
Approved (A status) signature algorithms: EdDSA (Ed25519, Ed448), XEdDSA (Curve25519, Curve448), ECDSA (P-256, P-384, P-521), RSA-RSSA-PSS. Disallowed (D status): RSA-SSA-PKCS#1 v1.5, DSA (any key size). Signature schemes MUST use approved key sizes and parameters per NIST SP 800-57 Part 1.
Post-quantum encryption standards references
Post-quantum cryptography (PQC) implementations should follow FIPS-203, FIPS-204, and FIPS-205. The proposed mlkem768x25519 post-quantum hybrid TLS key agreement method is supported by major browsers including Firefox release 132 and Chrome release 131. It may be used in cryptographic testing environments or when available within industry- or government-approved libraries.