From 0a77745ec661c9f42774483dea1ea8ec23148505 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Thu, 6 Mar 2025 16:16:11 +0100
Subject: [PATCH 001/117] Specify the uniquness requirement as defined by NIST

---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index d90f791bb2e..b7f909195b0 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -11,7 +11,7 @@ Cryptography plays an especially important role in securing the user's data - ev
 
 The goal of cryptography is to provide constant confidentiality, data integrity, and authenticity, even in the face of an attack. Confidentiality involves ensuring data privacy through the use of encryption. Data integrity deals with data consistency and detection of tampering and modification of data through the use of hashing. Authenticity ensures that the data comes from a trusted source.
 
-Encryption algorithms converts plaintext data into cipher text that conceals the original content. Plaintext data can be restored from the cipher text through decryption. Encryption can be **symmetric** (encryption/decryption with same secret-key) or **asymmetric** (encryption/decryption using a public and private key pair). In general, encryption operations do not protect integrity, but some symmetric encryption modes also feature that protection.
+Encryption algorithms converts plaintext data into cipher text that conceals the original content. Plaintext data can be restored from the cipher text through decryption. Encryption can be **symmetric** (encryption/decryption with same secret-key) or **asymmetric** (encryption/decryption using a public and private key pair). Symmetric encryption operations do not protect integrity unless used together with a recommended and approved cipher mode that supports an authenticated encryption function with an appropriatly random **IV** (Initialization vector) fulfilling the “uniqueness” requirement defined in [NIST SP 800-38D](https://csrc.nist.gov/pubs/sp/800/38/d/final).
 
 **Symmetric-key encryption algorithms** use the same key for both encryption and decryption. This type of encryption is fast and suitable for bulk data processing. Since everybody who has access to the key is able to decrypt the encrypted content, this method requires careful key management and centralized control over key distribution.
 

From b3d1875c4d28a8dd8435129d42c72eb1f2e0a0b3 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Thu, 6 Mar 2025 16:18:13 +0100
Subject: [PATCH 002/117] Update with chapter number

---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index b7f909195b0..694f07ae6ac 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -11,7 +11,7 @@ Cryptography plays an especially important role in securing the user's data - ev
 
 The goal of cryptography is to provide constant confidentiality, data integrity, and authenticity, even in the face of an attack. Confidentiality involves ensuring data privacy through the use of encryption. Data integrity deals with data consistency and detection of tampering and modification of data through the use of hashing. Authenticity ensures that the data comes from a trusted source.
 
-Encryption algorithms converts plaintext data into cipher text that conceals the original content. Plaintext data can be restored from the cipher text through decryption. Encryption can be **symmetric** (encryption/decryption with same secret-key) or **asymmetric** (encryption/decryption using a public and private key pair). Symmetric encryption operations do not protect integrity unless used together with a recommended and approved cipher mode that supports an authenticated encryption function with an appropriatly random **IV** (Initialization vector) fulfilling the “uniqueness” requirement defined in [NIST SP 800-38D](https://csrc.nist.gov/pubs/sp/800/38/d/final).
+Encryption algorithms converts plaintext data into cipher text that conceals the original content. Plaintext data can be restored from the cipher text through decryption. Encryption can be **symmetric** (encryption/decryption with same secret-key) or **asymmetric** (encryption/decryption using a public and private key pair). Symmetric encryption operations do not protect integrity unless used together with a recommended and approved cipher mode that supports an authenticated encryption function with an appropriatly random **IV** (Initialization vector) fulfilling the “uniqueness” requirement defined in [NIST SP 800-38D, chapter 8](https://csrc.nist.gov/pubs/sp/800/38/d/final).
 
 **Symmetric-key encryption algorithms** use the same key for both encryption and decryption. This type of encryption is fast and suitable for bulk data processing. Since everybody who has access to the key is able to decrypt the encrypted content, this method requires careful key management and centralized control over key distribution.
 

From 5cbf042e36993b4cf8a244d4a91ad5ad2bfaeae3 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 09:45:16 +0100
Subject: [PATCH 003/117] Add recommendations for symmetric encryption and
 methods for signature generation

---
 Document/0x04g-Testing-Cryptography.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 694f07ae6ac..a819d594b02 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -11,9 +11,9 @@ Cryptography plays an especially important role in securing the user's data - ev
 
 The goal of cryptography is to provide constant confidentiality, data integrity, and authenticity, even in the face of an attack. Confidentiality involves ensuring data privacy through the use of encryption. Data integrity deals with data consistency and detection of tampering and modification of data through the use of hashing. Authenticity ensures that the data comes from a trusted source.
 
-Encryption algorithms converts plaintext data into cipher text that conceals the original content. Plaintext data can be restored from the cipher text through decryption. Encryption can be **symmetric** (encryption/decryption with same secret-key) or **asymmetric** (encryption/decryption using a public and private key pair). Symmetric encryption operations do not protect integrity unless used together with a recommended and approved cipher mode that supports an authenticated encryption function with an appropriatly random **IV** (Initialization vector) fulfilling the “uniqueness” requirement defined in [NIST SP 800-38D, chapter 8](https://csrc.nist.gov/pubs/sp/800/38/d/final).
+Encryption algorithms converts plaintext data into cipher text that conceals the original content. Plaintext data can be restored from the cipher text through decryption. Encryption can be **symmetric** (encryption/decryption with same secret-key) or **asymmetric** (encryption/decryption using a public and private key pair). Symmetric encryption operations do not protect integrity unless used together with a recommended and approved cipher mode that supports an authenticated encryption function with an appropriatly random **IV** (Initialization vector) fulfilling the “uniqueness” requirement from "NIST 800-38D" ([NIST, 2007](https://csrc.nist.gov/pubs/sp/800/38/d/final)).
 
-**Symmetric-key encryption algorithms** use the same key for both encryption and decryption. This type of encryption is fast and suitable for bulk data processing. Since everybody who has access to the key is able to decrypt the encrypted content, this method requires careful key management and centralized control over key distribution.
+**Symmetric-key encryption algorithms** use the same key for both encryption and decryption. This type of encryption is fast and suitable for bulk data processing. Since everybody who has access to the key is able to decrypt the encrypted content, this method requires careful key management and centralized control over key distribution. Currently AES is the only approved symmetric algorithm according to "NIST 800-131A" ([NIST, 2019](https://csrc.nist.gov/pubs/sp/800/131/a/r2/final)).
 
 **Public-key encryption algorithms** operate with two separate keys: the public key and the private key. The public key can be distributed freely while the private key shouldn't be shared with anyone. A message encrypted with the public key can only be decrypted with the private key and vice-versa. Since asymmetric encryption is several times slower than symmetric operations, it's typically only used to encrypt small amounts of data, such as symmetric keys for bulk encryption.
 
@@ -21,7 +21,7 @@ Encryption algorithms converts plaintext data into cipher text that conceals the
 
 **Message Authentication Codes** (MACs) combine other cryptographic mechanisms (such as symmetric encryption or hashes) with secret keys to provide both integrity and authenticity protection. However, in order to verify a MAC, multiple entities have to share the same secret key and any of those entities can generate a valid MAC. HMACs, the most commonly used type of MAC, rely on hashing as the underlying cryptographic primitive. The full name of an HMAC algorithm usually includes the underlying hash function's type (for example, HMAC-SHA256 uses the SHA-256 hash function).
 
-**Signatures** combine asymmetric cryptography (that is, using a public/private key pair) with hashing to provide integrity and authenticity by encrypting the hash of the message with the private key. However, unlike MACs, signatures also provide non-repudiation property as the private key should remain unique to the data signer.
+**Signatures** combine asymmetric cryptography (that is, using a public/private key pair) with hashing to provide integrity and authenticity by encrypting the hash of the message with the private key. However, unlike MACs, signatures also provide non-repudiation property as the private key should remain unique to the data signer. Currently, RSA, ECDSA and EdDSA are the only approved techniques for digital signature generation according to "FIPS 186-4" ((NIST, 2023)[https://csrc.nist.gov/pubs/fips/186-5/final]), but please keep in mind that DSA only shall be used to verify previously genererated digital signatures.
 
 **Key Derivation Functions** (KDFs) derive secret keys from a secret value (such as a password) and are used to turn keys into other formats or to increase their length. KDFs are similar to hashing functions but have other uses as well (for example, they are used as components of multi-party key-agreement protocols). While both hashing functions and KDFs must be difficult to reverse, KDFs have the added requirement that the keys they produce must have a level of randomness.
 

From 1819fb942b7981ec196bd42be60d5ef98b77f92d Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 13:51:32 +0100
Subject: [PATCH 004/117] Update recommendation in regards to where to look for
 future advice on cryptography

---
 Document/0x04g-Testing-Cryptography.md | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index a819d594b02..00d15648a3d 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -13,7 +13,7 @@ The goal of cryptography is to provide constant confidentiality, data integrity,
 
 Encryption algorithms converts plaintext data into cipher text that conceals the original content. Plaintext data can be restored from the cipher text through decryption. Encryption can be **symmetric** (encryption/decryption with same secret-key) or **asymmetric** (encryption/decryption using a public and private key pair). Symmetric encryption operations do not protect integrity unless used together with a recommended and approved cipher mode that supports an authenticated encryption function with an appropriatly random **IV** (Initialization vector) fulfilling the “uniqueness” requirement from "NIST 800-38D" ([NIST, 2007](https://csrc.nist.gov/pubs/sp/800/38/d/final)).
 
-**Symmetric-key encryption algorithms** use the same key for both encryption and decryption. This type of encryption is fast and suitable for bulk data processing. Since everybody who has access to the key is able to decrypt the encrypted content, this method requires careful key management and centralized control over key distribution. Currently AES is the only approved symmetric algorithm according to "NIST 800-131A" ([NIST, 2019](https://csrc.nist.gov/pubs/sp/800/131/a/r2/final)).
+**Symmetric-key encryption algorithms** use the same key for both encryption and decryption. This type of encryption is fast and suitable for bulk data processing. Since everybody who has access to the key is able to decrypt the encrypted content, this method requires careful key management and centralized control over key distribution.
 
 **Public-key encryption algorithms** operate with two separate keys: the public key and the private key. The public key can be distributed freely while the private key shouldn't be shared with anyone. A message encrypted with the public key can only be decrypted with the private key and vice-versa. Since asymmetric encryption is several times slower than symmetric operations, it's typically only used to encrypt small amounts of data, such as symmetric keys for bulk encryption.
 
@@ -21,7 +21,7 @@ Encryption algorithms converts plaintext data into cipher text that conceals the
 
 **Message Authentication Codes** (MACs) combine other cryptographic mechanisms (such as symmetric encryption or hashes) with secret keys to provide both integrity and authenticity protection. However, in order to verify a MAC, multiple entities have to share the same secret key and any of those entities can generate a valid MAC. HMACs, the most commonly used type of MAC, rely on hashing as the underlying cryptographic primitive. The full name of an HMAC algorithm usually includes the underlying hash function's type (for example, HMAC-SHA256 uses the SHA-256 hash function).
 
-**Signatures** combine asymmetric cryptography (that is, using a public/private key pair) with hashing to provide integrity and authenticity by encrypting the hash of the message with the private key. However, unlike MACs, signatures also provide non-repudiation property as the private key should remain unique to the data signer. Currently, RSA, ECDSA and EdDSA are the only approved techniques for digital signature generation according to "FIPS 186-4" ((NIST, 2023)[https://csrc.nist.gov/pubs/fips/186-5/final]), but please keep in mind that DSA only shall be used to verify previously genererated digital signatures.
+**Signatures** combine asymmetric cryptography (that is, using a public/private key pair) with hashing to provide integrity and authenticity by encrypting the hash of the message with the private key. However, unlike MACs, signatures also provide non-repudiation property as the private key should remain unique to the data signer.
 
 **Key Derivation Functions** (KDFs) derive secret keys from a secret value (such as a password) and are used to turn keys into other formats or to increase their length. KDFs are similar to hashing functions but have other uses as well (for example, they are used as components of multi-party key-agreement protocols). While both hashing functions and KDFs must be difficult to reverse, KDFs have the added requirement that the keys they produce must have a level of randomness.
 
@@ -46,7 +46,7 @@ The names of cryptographic APIs depend on the particular mobile platform.
 Please make sure that:
 
 - Cryptographic algorithms are up to date and in-line with industry standards. This includes, but is not limited to outdated block ciphers (e.g. DES), stream ciphers (e.g. RC4), as well as hash functions (e.g. MD5) and broken random number generators like Dual_EC_DRBG (even if they are NIST certified). All of these should be marked as insecure and should not be used and removed from the application and server.
-- Key lengths are in-line with industry standards and provide protection for sufficient amount of time. A comparison of different key lengths and protection they provide taking into account Moore's law is available [online](https://www.keylength.com/ "Keylength comparison").
+- Key lengths are in-line with industry standards and provide protection for sufficient amount of time. A comparison of different key lengths and protection they provide taking into account Moore's law is available [online](https://www.keylength.com/ "Keylength comparison"). Also key an eye on NIST SP 800-131A on "Transitioning the Use of Cryptographic Algorithms and Key Lengths" [(NIST, 2024)](https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd) to align with future guidence on transitioning to the use of stronger cryptographic keys and more robust algorithms.
 - Cryptographic means are not mixed with each other: e.g. you do not sign with a public key, or try to reuse a key pair used for a signature to do encryption.
 - Cryptographic parameters are well defined within reasonable range. This includes, but is not limited to: cryptographic salt, which should be at least the same length as hash function output, reasonable choice of password derivation function and iteration count (e.g. PBKDF2, scrypt or bcrypt), IVs being random and unique, fit-for-purpose block encryption modes (e.g. ECB should not be used, except specific cases), key management being done properly (e.g. 3DES should have three independent keys) and so on.
 
@@ -54,7 +54,7 @@ The following algorithms are recommended:
 
 - Confidentiality algorithms: AES-GCM-256 or ChaCha20-Poly1305
 - Integrity algorithms: SHA-256, SHA-384, SHA-512, BLAKE3, the SHA-3 family
-- Digital signature algorithms: RSA (3072 bits and higher), ECDSA with NIST P-384
+- Digital signature algorithms: RSA (3072 bits and higher), ECDSA with NIST P-384 or EdDSA with Edwards448. 
 - Key establishment algorithms: RSA (3072 bits and higher), DH (3072 bits or higher), ECDH with NIST P-384
 
 Additionally, you should always rely on secure hardware (if available) for storing encryption keys, performing cryptographic operations, etc.
@@ -64,6 +64,21 @@ For more information on algorithm choice and best practices, see the following r
 - ["Commercial National Security Algorithm Suite and Quantum Computing FAQ"](https://cryptome.org/2016/01/CNSA-Suite-and-Quantum-Computing-FAQ.pdf "Commercial National Security Algorithm Suite and Quantum Computing FAQ")
 - [NIST recommendations (2019)](https://www.keylength.com/en/4/ "NIST recommendations")
 - [BSI recommendations (2019)](https://www.keylength.com/en/8/ "BSI recommendations")
+- NIST advises using RSA-based key-transport schemes with a minimum modulus length of at least 2048 bits according to 800-56B Rev. 2 ([NIST, 2019](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final))
+- NIST advises using ECC-based key-agreement schemes, such as Elliptic Curve Diffie-Hellman (ECDH), utilizing curves between P-224 to P-521 according to 800-56A Rev. 3 ([NIST, 2018](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final)).
+- RSA, ECDSA and EdDSA are approved techniques by NIST for digital signature generation according to "FIPS 186-4" ([NIST, 2023](https://csrc.nist.gov/pubs/fips/186-5/final)). Keep in mind that DSA only shall be used to verify previously genererated digital signatures.
+- NIST Digital Signature Standard, FIPS 186-5 (DSS) [(NIST, 2023)](https://csrc.nist.gov/pubs/fips/186-5/final)
+- Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters, NIST SP 800-186 [(NIST, 2023)(https://csrc.nist.gov/pubs/sp/800/186/final)]
+
+## Post-Quantum
+
+### Public-key encryption algorithms
+
+NIST has approved CRYSTALS-Kyber as a post-quantum key encapsulation mechanism (KEM) to establish a shared secret key over a public channel. The secret can then be used with symmetric-key cryptographic algorithms to perform encryption and decryption. This according to FIPS 203 ([NIST, 2024](https://csrc.nist.gov/pubs/fips/203/final)).
+
+## Signatures
+
+NIST has approved [SLH-DSA](https://csrc.nist.gov/pubs/fips/205/final) (NIST, 2024) and [ML-DSA](https://csrc.nist.gov/pubs/fips/204/final) (NIST, 2024) as recommended digital signature algorithm to be used in for post-quatum signatures generation and verification.
 
 ## Common Configuration Issues
 

From a0679c1aaf54d1a4f00097f3d9bf68d61c987cf7 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 14:00:36 +0100
Subject: [PATCH 005/117] Update advice regarding post-quantum

---
 Document/0x04g-Testing-Cryptography.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 00d15648a3d..9cb75d3fc20 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -50,13 +50,15 @@ Please make sure that:
 - Cryptographic means are not mixed with each other: e.g. you do not sign with a public key, or try to reuse a key pair used for a signature to do encryption.
 - Cryptographic parameters are well defined within reasonable range. This includes, but is not limited to: cryptographic salt, which should be at least the same length as hash function output, reasonable choice of password derivation function and iteration count (e.g. PBKDF2, scrypt or bcrypt), IVs being random and unique, fit-for-purpose block encryption modes (e.g. ECB should not be used, except specific cases), key management being done properly (e.g. 3DES should have three independent keys) and so on.
 
-The following algorithms are recommended:
+We recommend the following algorithms:
 
 - Confidentiality algorithms: AES-GCM-256 or ChaCha20-Poly1305
 - Integrity algorithms: SHA-256, SHA-384, SHA-512, BLAKE3, the SHA-3 family
 - Digital signature algorithms: RSA (3072 bits and higher), ECDSA with NIST P-384 or EdDSA with Edwards448. 
 - Key establishment algorithms: RSA (3072 bits and higher), DH (3072 bits or higher), ECDH with NIST P-384
 
+Please note: The Recommendations are based on current industry perception regarding what is considered to be appropriate and are in line with NIST recommendations beyond 2030, but does not necessarily take into account quantum computing advancements. For advice on post-quantum, please see **Post-Quantum** below.
+
 Additionally, you should always rely on secure hardware (if available) for storing encryption keys, performing cryptographic operations, etc.
 
 For more information on algorithm choice and best practices, see the following resources:

From c01ad2875b082a86f4f677d0f1fc81e1191efda6 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 15:19:21 +0100
Subject: [PATCH 006/117] Add

---
 Document/0x04g-Testing-Cryptography.md | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 9cb75d3fc20..ccbd307f093 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -57,7 +57,7 @@ We recommend the following algorithms:
 - Digital signature algorithms: RSA (3072 bits and higher), ECDSA with NIST P-384 or EdDSA with Edwards448. 
 - Key establishment algorithms: RSA (3072 bits and higher), DH (3072 bits or higher), ECDH with NIST P-384
 
-Please note: The Recommendations are based on current industry perception regarding what is considered to be appropriate and are in line with NIST recommendations beyond 2030, but does not necessarily take into account quantum computing advancements. For advice on post-quantum, please see **Post-Quantum** below.
+**Please note:** The Recommendations are based on current industry perception regarding what is considered to be appropriate and are in line with NIST recommendations beyond 2030, but does not necessarily take into account quantum computing advancements. For advice on post-quantum, please see **Post-Quantum** below.
 
 Additionally, you should always rely on secure hardware (if available) for storing encryption keys, performing cryptographic operations, etc.
 
@@ -111,20 +111,22 @@ If the app relies on an additional encrypted container stored in app data, check
 
 Secret keys must be stored in secure device storage whenever symmetric cryptography is used in mobile apps. For more information on the platform-specific APIs, see the "[Data Storage on Android](0x05d-Testing-Data-Storage.md)" and "[Data Storage on iOS](0x06d-Testing-Data-Storage.md)" chapters.
 
-### Weak Key Generation Functions
+### Recommended Key Generation Functions
 
 Cryptographic algorithms (such as symmetric encryption or some MACs) expect a secret input of a given size. For example, AES uses a key of exactly 16 bytes. A native implementation might use the user-supplied password directly as an input key. Using a user-supplied password as an input key has the following problems:
 
 - If the password is smaller than the key, the full key space isn't used. The remaining space is padded (spaces are sometimes used for padding).
 - A user-supplied password will realistically consist mostly of displayable and pronounceable characters. Therefore, only some of the possible 256 ASCII characters are used and entropy is decreased by approximately a factor of four.
 
-Ensure that passwords aren't directly passed into an encryption function. Instead, the user-supplied password should be passed into a KDF to create a cryptographic key. Choose an appropriate iteration count when using password derivation functions. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to consider implementation of algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2").
+Ensure that passwords aren't directly passed into an encryption function. Instead, the user-supplied password should be passed into a KDF to create a cryptographic key. Choose an appropriate iteration count when using password derivation functions. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to consider implementation of algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2"). Also see ["OWASP Password Storage Cheat Sheet"](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction) for recommendation on iteration count when using key derivation functions.
 
-### Weak Random Number Generators
+### Vulnerable Random Number Generators
 
-It is fundamentally impossible to produce truly random numbers on any deterministic device. Pseudo-random number generators (RNG) compensate for this by producing a stream of pseudo-random numbers - a stream of numbers that appear as if they were randomly generated. The quality of the generated numbers varies with the type of algorithm used. Cryptographically secure RNGs generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks (e.g. it is statistically infeasible to predict the next number produced).
+It is fundamentally impossible to produce truly random numbers on any deterministic device. Pseudo-random number generators (PRNG) compensate for this by producing a stream of pseudo-random numbers - a stream of numbers that appear as if they were randomly generated. The quality of the generated numbers varies with the type of algorithm used. Cryptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks (e.g. it is statistically infeasible to predict the next number produced).
 
-Mobile SDKs offer standard implementations of RNG algorithms that produce numbers with sufficient artificial randomness. We'll introduce the available APIs in the Android and iOS specific sections.
+PRNG can be vulnerable when developers use a regular PRNG for cryptographic purposes, instead of a cryptographically-secure PRNG (["Cryptographically secure pseudorandom number generator"](https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator), 2025.01.31). 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.
+
+Mobile SDKs offer standard implementations of PRNG algorithms that produce numbers with sufficient artificial randomness. We'll introduce the available APIs in the Android and iOS specific sections.
 
 ### Custom Implementations of Cryptography
 
@@ -143,7 +145,7 @@ Advanced Encryption Standard (AES) is the widely accepted standard for symmetric
 
 As of this writing, no efficient cryptanalytic attacks against AES have been discovered. However, implementation details and configurable parameters such as the block cipher mode leave some margin for error.
 
-#### Weak Block Cipher Mode
+#### Vulnerable Block Cipher Mode
 
 Block-based encryption is performed upon discrete input blocks (for example, AES has 128-bit blocks). If the plaintext is larger than the block size, the plaintext is internally split up into blocks of the given input size and encryption is performed on each block. A block cipher mode of operation (or block mode) determines if the result of encrypting the previous block impacts subsequent blocks.
 

From 370316fb6509876a212e80b0108d1272b79f8e46 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 15:58:54 +0100
Subject: [PATCH 007/117] Update recommendation according to what is
 recommended for key generation functions.

---
 Document/0x04g-Testing-Cryptography.md | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index ccbd307f093..5a3a3cb617b 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -111,14 +111,16 @@ If the app relies on an additional encrypted container stored in app data, check
 
 Secret keys must be stored in secure device storage whenever symmetric cryptography is used in mobile apps. For more information on the platform-specific APIs, see the "[Data Storage on Android](0x05d-Testing-Data-Storage.md)" and "[Data Storage on iOS](0x06d-Testing-Data-Storage.md)" chapters.
 
-### Recommended Key Generation Functions
+### Vulnerable Key Generation Functions
 
 Cryptographic algorithms (such as symmetric encryption or some MACs) expect a secret input of a given size. For example, AES uses a key of exactly 16 bytes. A native implementation might use the user-supplied password directly as an input key. Using a user-supplied password as an input key has the following problems:
 
 - If the password is smaller than the key, the full key space isn't used. The remaining space is padded (spaces are sometimes used for padding).
 - A user-supplied password will realistically consist mostly of displayable and pronounceable characters. Therefore, only some of the possible 256 ASCII characters are used and entropy is decreased by approximately a factor of four.
+- In cases where the user-supplied password is based on a pin, the key can be reconstructed by using the key generation function implemented on the mobile phone as an "oracle".
 
-Ensure that passwords aren't directly passed into an encryption function. Instead, the user-supplied password should be passed into a KDF to create a cryptographic key. Choose an appropriate iteration count when using password derivation functions. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to consider implementation of algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2"). Also see ["OWASP Password Storage Cheat Sheet"](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction) for recommendation on iteration count when using key derivation functions.
+Ensure that passwords aren't directly passed into an encryption function. The key that is input to a key-derivation function is called a key-derivation key (KDK). A KDK **shall** be a cryptographic key, but the KDK used as an input to one of the key-derivation functions specified in this Recommendation can, for example, be generated by an approved cryptographic random bit generator, e.g. by a deterministic random bit generator (see: [800-108r1-upd1](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final)) (NIST, [2022](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final)).
+Choose an appropriate iteration count when using password derivation functions. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to consider implementation of algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2"). Also see ["OWASP Password Storage Cheat Sheet"](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction) for recommendation on iteration count when using key derivation functions using Argon2, scrypt, bcrypt or PBKDF2.
 
 ### Vulnerable Random Number Generators
 

From 0fde7746c8e67c73423e74fae31dbc13971c1c9f Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 16:11:17 +0100
Subject: [PATCH 008/117] Add the possibility of CCM Mode

---
 Document/0x04g-Testing-Cryptography.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 5a3a3cb617b..8a6e8f65a84 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -117,7 +117,7 @@ Cryptographic algorithms (such as symmetric encryption or some MACs) expect a se
 
 - If the password is smaller than the key, the full key space isn't used. The remaining space is padded (spaces are sometimes used for padding).
 - A user-supplied password will realistically consist mostly of displayable and pronounceable characters. Therefore, only some of the possible 256 ASCII characters are used and entropy is decreased by approximately a factor of four.
-- In cases where the user-supplied password is based on a pin, the key can be reconstructed by using the key generation function implemented on the mobile phone as an "oracle".
+- In cases where the user-supplied password is based on a pin, the key can be easily reconstructed by using the key generation function implemented on the mobile phone as an "oracle".
 
 Ensure that passwords aren't directly passed into an encryption function. The key that is input to a key-derivation function is called a key-derivation key (KDK). A KDK **shall** be a cryptographic key, but the KDK used as an input to one of the key-derivation functions specified in this Recommendation can, for example, be generated by an approved cryptographic random bit generator, e.g. by a deterministic random bit generator (see: [800-108r1-upd1](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final)) (NIST, [2022](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final)).
 Choose an appropriate iteration count when using password derivation functions. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to consider implementation of algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2"). Also see ["OWASP Password Storage Cheat Sheet"](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction) for recommendation on iteration count when using key derivation functions using Argon2, scrypt, bcrypt or PBKDF2.
@@ -157,7 +157,7 @@ Block-based encryption is performed upon discrete input blocks (for example, AES
 
 Verify that Cipher Block Chaining (CBC) mode is used instead of ECB. In CBC mode, plaintext blocks are XORed with the previous ciphertext block. This ensures that each encrypted block is unique and randomized even if blocks contain the same information. Please note that it is best to combine CBC with an HMAC and/or ensure that no errors are given such as "Padding error", "MAC error", "decryption failed" in order to be more resistant to a padding oracle attack.
 
-When storing encrypted data, we recommend using a block mode that also protects the integrity of the stored data, such as Galois/Counter Mode (GCM). The latter has the additional benefit that the algorithm is mandatory for each TLSv1.2 implementation, and thus is available on all modern platforms.
+When storing encrypted data, we recommend using a block mode that also protects the integrity of the stored data, such as Galois/Counter Mode (GCM). The latter has the additional benefit that the algorithm is mandatory for each TLSv1.2 implementation, and thus is available on all modern platforms. To protect the integrity and authenticity of the data where CBC mode is used, it is recommended to combine the techniques of the Counter (CTR) mode and the Cipher Block Chaining-Message Authentication Code (CBC-MAC) into what is called CCM Mode ([NIST, 2004](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final)).
 
 For more information on effective block modes, see the [NIST guidelines on block mode selection](https://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html "NIST Modes Development, Proposed Modes").
 

From 3cd8157ee71475376f8eafdebd7ff4c79c1b84ff Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 16:16:28 +0100
Subject: [PATCH 009/117] Correct spelling error

---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 8a6e8f65a84..14991228ca0 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -46,7 +46,7 @@ The names of cryptographic APIs depend on the particular mobile platform.
 Please make sure that:
 
 - Cryptographic algorithms are up to date and in-line with industry standards. This includes, but is not limited to outdated block ciphers (e.g. DES), stream ciphers (e.g. RC4), as well as hash functions (e.g. MD5) and broken random number generators like Dual_EC_DRBG (even if they are NIST certified). All of these should be marked as insecure and should not be used and removed from the application and server.
-- Key lengths are in-line with industry standards and provide protection for sufficient amount of time. A comparison of different key lengths and protection they provide taking into account Moore's law is available [online](https://www.keylength.com/ "Keylength comparison"). Also key an eye on NIST SP 800-131A on "Transitioning the Use of Cryptographic Algorithms and Key Lengths" [(NIST, 2024)](https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd) to align with future guidence on transitioning to the use of stronger cryptographic keys and more robust algorithms.
+- Key lengths are in-line with industry standards and provide protection for sufficient amount of time. A comparison of different key lengths and protection they provide taking into account Moore's law is available [online](https://www.keylength.com/ "Keylength comparison"). NIST SP 800-131A on "Transitioning the Use of Cryptographic Algorithms and Key Lengths" [(NIST, 2024)](https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd) provides recommendations on how to align with future guidence and on transitioning to stronger cryptographic keys and more robust algorithms.
 - Cryptographic means are not mixed with each other: e.g. you do not sign with a public key, or try to reuse a key pair used for a signature to do encryption.
 - Cryptographic parameters are well defined within reasonable range. This includes, but is not limited to: cryptographic salt, which should be at least the same length as hash function output, reasonable choice of password derivation function and iteration count (e.g. PBKDF2, scrypt or bcrypt), IVs being random and unique, fit-for-purpose block encryption modes (e.g. ECB should not be used, except specific cases), key management being done properly (e.g. 3DES should have three independent keys) and so on.
 

From 35f2bdcb91fcd92d69ac00f449f09442b2f0d312 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 16:17:41 +0100
Subject: [PATCH 010/117] correct grammer

---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 14991228ca0..83e8c8b8605 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -46,7 +46,7 @@ The names of cryptographic APIs depend on the particular mobile platform.
 Please make sure that:
 
 - Cryptographic algorithms are up to date and in-line with industry standards. This includes, but is not limited to outdated block ciphers (e.g. DES), stream ciphers (e.g. RC4), as well as hash functions (e.g. MD5) and broken random number generators like Dual_EC_DRBG (even if they are NIST certified). All of these should be marked as insecure and should not be used and removed from the application and server.
-- Key lengths are in-line with industry standards and provide protection for sufficient amount of time. A comparison of different key lengths and protection they provide taking into account Moore's law is available [online](https://www.keylength.com/ "Keylength comparison"). NIST SP 800-131A on "Transitioning the Use of Cryptographic Algorithms and Key Lengths" [(NIST, 2024)](https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd) provides recommendations on how to align with future guidence and on transitioning to stronger cryptographic keys and more robust algorithms.
+- Key lengths are in-line with industry standards and provide protection for sufficient amount of time. A comparison of different key lengths and the protection they provide, taking into account Moore's law, is available [online](https://www.keylength.com/ "Keylength comparison"). NIST SP 800-131A on "Transitioning the Use of Cryptographic Algorithms and Key Lengths" [(NIST, 2024)](https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd) provides recommendations on how to align with future guidence and on transitioning to stronger cryptographic keys and more robust algorithms.
 - Cryptographic means are not mixed with each other: e.g. you do not sign with a public key, or try to reuse a key pair used for a signature to do encryption.
 - Cryptographic parameters are well defined within reasonable range. This includes, but is not limited to: cryptographic salt, which should be at least the same length as hash function output, reasonable choice of password derivation function and iteration count (e.g. PBKDF2, scrypt or bcrypt), IVs being random and unique, fit-for-purpose block encryption modes (e.g. ECB should not be used, except specific cases), key management being done properly (e.g. 3DES should have three independent keys) and so on.
 

From 21b5548c8df2946ca9fb31ce4eba1e086164c8c7 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 16:20:31 +0100
Subject: [PATCH 011/117] Move recommendation onto a separate line.

---
 Document/0x04g-Testing-Cryptography.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 83e8c8b8605..f69c8df91a1 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -46,7 +46,8 @@ The names of cryptographic APIs depend on the particular mobile platform.
 Please make sure that:
 
 - Cryptographic algorithms are up to date and in-line with industry standards. This includes, but is not limited to outdated block ciphers (e.g. DES), stream ciphers (e.g. RC4), as well as hash functions (e.g. MD5) and broken random number generators like Dual_EC_DRBG (even if they are NIST certified). All of these should be marked as insecure and should not be used and removed from the application and server.
-- Key lengths are in-line with industry standards and provide protection for sufficient amount of time. A comparison of different key lengths and the protection they provide, taking into account Moore's law, is available [online](https://www.keylength.com/ "Keylength comparison"). NIST SP 800-131A on "Transitioning the Use of Cryptographic Algorithms and Key Lengths" [(NIST, 2024)](https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd) provides recommendations on how to align with future guidence and on transitioning to stronger cryptographic keys and more robust algorithms.
+- Key lengths are in-line with industry standards and provide protection for sufficient amount of time. A comparison of different key lengths and the protection they provide, taking into account Moore's law, is available [online](https://www.keylength.com/ "Keylength comparison").
+- Through NIST SP 800-131A on "Transitioning the Use of Cryptographic Algorithms and Key Lengths" [(NIST, 2024)](https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd), NIST provides recommendations and guidence on how to align with future recommendations and how to transition to stronger cryptographic keys and more robust algorithms.
 - Cryptographic means are not mixed with each other: e.g. you do not sign with a public key, or try to reuse a key pair used for a signature to do encryption.
 - Cryptographic parameters are well defined within reasonable range. This includes, but is not limited to: cryptographic salt, which should be at least the same length as hash function output, reasonable choice of password derivation function and iteration count (e.g. PBKDF2, scrypt or bcrypt), IVs being random and unique, fit-for-purpose block encryption modes (e.g. ECB should not be used, except specific cases), key management being done properly (e.g. 3DES should have three independent keys) and so on.
 

From 8c8ee08eae962a893897a07f7db5c1087b20db14 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 16:21:42 +0100
Subject: [PATCH 012/117] Correct spelling error

---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index f69c8df91a1..04aa58f4a0e 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -47,7 +47,7 @@ Please make sure that:
 
 - Cryptographic algorithms are up to date and in-line with industry standards. This includes, but is not limited to outdated block ciphers (e.g. DES), stream ciphers (e.g. RC4), as well as hash functions (e.g. MD5) and broken random number generators like Dual_EC_DRBG (even if they are NIST certified). All of these should be marked as insecure and should not be used and removed from the application and server.
 - Key lengths are in-line with industry standards and provide protection for sufficient amount of time. A comparison of different key lengths and the protection they provide, taking into account Moore's law, is available [online](https://www.keylength.com/ "Keylength comparison").
-- Through NIST SP 800-131A on "Transitioning the Use of Cryptographic Algorithms and Key Lengths" [(NIST, 2024)](https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd), NIST provides recommendations and guidence on how to align with future recommendations and how to transition to stronger cryptographic keys and more robust algorithms.
+- Through NIST SP 800-131A on "Transitioning the Use of Cryptographic Algorithms and Key Lengths" [(NIST, 2024)](https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd), NIST provides recommendations and guidance on how to align with future recommendations and how to transition to stronger cryptographic keys and more robust algorithms.
 - Cryptographic means are not mixed with each other: e.g. you do not sign with a public key, or try to reuse a key pair used for a signature to do encryption.
 - Cryptographic parameters are well defined within reasonable range. This includes, but is not limited to: cryptographic salt, which should be at least the same length as hash function output, reasonable choice of password derivation function and iteration count (e.g. PBKDF2, scrypt or bcrypt), IVs being random and unique, fit-for-purpose block encryption modes (e.g. ECB should not be used, except specific cases), key management being done properly (e.g. 3DES should have three independent keys) and so on.
 

From e142294be1520510a1afd8e4fc11a21493ad6890 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 16:25:15 +0100
Subject: [PATCH 013/117] Update reference

---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 04aa58f4a0e..e635bf979c5 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -120,7 +120,7 @@ Cryptographic algorithms (such as symmetric encryption or some MACs) expect a se
 - A user-supplied password will realistically consist mostly of displayable and pronounceable characters. Therefore, only some of the possible 256 ASCII characters are used and entropy is decreased by approximately a factor of four.
 - In cases where the user-supplied password is based on a pin, the key can be easily reconstructed by using the key generation function implemented on the mobile phone as an "oracle".
 
-Ensure that passwords aren't directly passed into an encryption function. The key that is input to a key-derivation function is called a key-derivation key (KDK). A KDK **shall** be a cryptographic key, but the KDK used as an input to one of the key-derivation functions specified in this Recommendation can, for example, be generated by an approved cryptographic random bit generator, e.g. by a deterministic random bit generator (see: [800-108r1-upd1](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final)) (NIST, [2022](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final)).
+Ensure that passwords aren't directly passed into an encryption function. The key that is input to a key-derivation function is called a key-derivation key (KDK). A KDK **shall** be a cryptographic key, but the KDK used as an input to one of the key-derivation functions specified in this Recommendation can, for example, be generated by an approved cryptographic random bit generator, e.g. by a deterministic random bit generator (see: [800-108, rev 1](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final)) (NIST, [2022](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final)).
 Choose an appropriate iteration count when using password derivation functions. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to consider implementation of algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2"). Also see ["OWASP Password Storage Cheat Sheet"](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction) for recommendation on iteration count when using key derivation functions using Argon2, scrypt, bcrypt or PBKDF2.
 
 ### Vulnerable Random Number Generators

From 92cdb6cc35aafc6d0c6b2f988e2b5c2dbe3ba7e7 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 16:58:28 +0100
Subject: [PATCH 014/117] Update references

---
 Document/0x04g-Testing-Cryptography.md | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index e635bf979c5..744050a1c48 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -120,14 +120,14 @@ Cryptographic algorithms (such as symmetric encryption or some MACs) expect a se
 - A user-supplied password will realistically consist mostly of displayable and pronounceable characters. Therefore, only some of the possible 256 ASCII characters are used and entropy is decreased by approximately a factor of four.
 - In cases where the user-supplied password is based on a pin, the key can be easily reconstructed by using the key generation function implemented on the mobile phone as an "oracle".
 
-Ensure that passwords aren't directly passed into an encryption function. The key that is input to a key-derivation function is called a key-derivation key (KDK). A KDK **shall** be a cryptographic key, but the KDK used as an input to one of the key-derivation functions specified in this Recommendation can, for example, be generated by an approved cryptographic random bit generator, e.g. by a deterministic random bit generator (see: [800-108, rev 1](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final)) (NIST, [2022](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final)).
-Choose an appropriate iteration count when using password derivation functions. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to consider implementation of algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2"). Also see ["OWASP Password Storage Cheat Sheet"](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction) for recommendation on iteration count when using key derivation functions using Argon2, scrypt, bcrypt or PBKDF2.
+Ensure that passwords aren't directly passed into an encryption function. The key that is input to a key-derivation function is called a key-derivation key (KDK). A KDK **shall** be a cryptographic key, but the KDK used as an input to one of the key-derivation functions specified in this Recommendation can, for example, be generated by an approved cryptographic random bit generator, e.g. by a deterministic random bit generator (see: [NIST 800-108, rev 1](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST")) ([NIST, 2022](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST")).
+Choose an appropriate iteration count when using password derivation functions. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to consider implementation of algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2"). Also see ["OWASP Password Storage Cheat Sheet"](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction "OWASP Cheat Sheet Series") for recommendation on iteration count when using key derivation functions using Argon2, scrypt, bcrypt or PBKDF2.
 
 ### Vulnerable Random Number Generators
 
 It is fundamentally impossible to produce truly random numbers on any deterministic device. Pseudo-random number generators (PRNG) compensate for this by producing a stream of pseudo-random numbers - a stream of numbers that appear as if they were randomly generated. The quality of the generated numbers varies with the type of algorithm used. Cryptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks (e.g. it is statistically infeasible to predict the next number produced).
 
-PRNG can be vulnerable when developers use a regular PRNG for cryptographic purposes, instead of a cryptographically-secure PRNG (["Cryptographically secure pseudorandom number generator"](https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator), 2025.01.31). 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.
+PRNG can be vulnerable when developers use a regular PRNG for cryptographic purposes, instead of a cryptographically-secure PRNG (["Cryptographically secure pseudorandom number generator", 2025.01.31](https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator "WIkipedia")). 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.
 
 Mobile SDKs offer standard implementations of PRNG algorithms that produce numbers with sufficient artificial randomness. We'll introduce the available APIs in the Android and iOS specific sections.
 
@@ -148,7 +148,7 @@ Advanced Encryption Standard (AES) is the widely accepted standard for symmetric
 
 As of this writing, no efficient cryptanalytic attacks against AES have been discovered. However, implementation details and configurable parameters such as the block cipher mode leave some margin for error.
 
-#### Vulnerable Block Cipher Mode
+#### Recommendations for Block Cipher Mode
 
 Block-based encryption is performed upon discrete input blocks (for example, AES has 128-bit blocks). If the plaintext is larger than the block size, the plaintext is internally split up into blocks of the given input size and encryption is performed on each block. A block cipher mode of operation (or block mode) determines if the result of encrypting the previous block impacts subsequent blocks.
 
@@ -156,9 +156,9 @@ Block-based encryption is performed upon discrete input blocks (for example, AES
 
 <img src="Images/Chapters/0x07c/EncryptionMode.png" width="550px" />
 
-Verify that Cipher Block Chaining (CBC) mode is used instead of ECB. In CBC mode, plaintext blocks are XORed with the previous ciphertext block. This ensures that each encrypted block is unique and randomized even if blocks contain the same information. Please note that it is best to combine CBC with an HMAC and/or ensure that no errors are given such as "Padding error", "MAC error", "decryption failed" in order to be more resistant to a padding oracle attack.
+Verify that Cipher Block Chaining (CBC) mode is used instead of ECB. In CBC mode, plaintext blocks are XORed with the previous ciphertext block. This ensures that each encrypted block is unique and randomized even if blocks contain the same information. Please note that it is best to combine CBC with an HMAC and/or ensure that no errors are given such as "Padding error", "MAC error", "decryption failed" in order to be more resistant to a padding oracle attack. For the 
 
-When storing encrypted data, we recommend using a block mode that also protects the integrity of the stored data, such as Galois/Counter Mode (GCM). The latter has the additional benefit that the algorithm is mandatory for each TLSv1.2 implementation, and thus is available on all modern platforms. To protect the integrity and authenticity of the data where CBC mode is used, it is recommended to combine the techniques of the Counter (CTR) mode and the Cipher Block Chaining-Message Authentication Code (CBC-MAC) into what is called CCM Mode ([NIST, 2004](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final)).
+When storing encrypted data, we recommend using a block mode that also protects the integrity of the stored data, such as Galois/Counter Mode (GCM). The latter has the additional benefit that the algorithm is mandatory for each TLSv1.2 implementation, and thus is available on all modern platforms. To protect the integrity and authenticity of the data where CBC mode is used, it is recommended to combine the techniques of the Counter (CTR) mode and the Cipher Block Chaining-Message Authentication Code (CBC-MAC) into what is called CCM Mode ([NIST, 2004](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final "NIST")).
 
 For more information on effective block modes, see the [NIST guidelines on block mode selection](https://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html "NIST Modes Development, Proposed Modes").
 
@@ -168,6 +168,10 @@ CBC, OFB, CFB, PCBC, GCM mode require an initialization vector (IV) as an initia
 
 Pay attention to cryptographic libraries used in the code: many open source libraries provide examples in their documentations that might follow bad practices (e.g. using a hardcoded IV). A popular mistake is copy-pasting example code without changing the IV value.
 
+#### Using the same key for encryption and authentication
+
+One common mistake is to reuse the same key k for CBC encryption and CBC-MAC. Reuse of keys for different purposes is genarally not recommended, but in the case of CBC-MAC the mistake can lead to a MitM attack (["CBC-MAC", 2024.10.11](https://en.wikipedia.org/wiki/CBC-MAC "Wikipedia")).
+
 #### Initialization Vectors in stateful operation modes
 
 Please note that the usage of IVs is different when using CTR and GCM mode in which the initialization vector is often a counter (in CTR combined with a nonce). So here using a predictable IV with its own stateful model is exactly what is needed. In CTR you have a new nonce plus counter as an input to every new block operation. For example: for a 5120 bit long plaintext: you have 20 blocks, so you need 20 input vectors consisting of a nonce and counter. Whereas in GCM you have a single IV per cryptographic operation, which should not be repeated with the same key. See section 8 of the [documentation from NIST on GCM](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode and GMAC") for more details and recommendations of the IV.

From 4ac0e65bf00a74b6edaa6e352b022fa94bf19397 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 16:59:45 +0100
Subject: [PATCH 015/117] Correct spelling

---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 744050a1c48..4adaccfab82 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -156,7 +156,7 @@ Block-based encryption is performed upon discrete input blocks (for example, AES
 
 <img src="Images/Chapters/0x07c/EncryptionMode.png" width="550px" />
 
-Verify that Cipher Block Chaining (CBC) mode is used instead of ECB. In CBC mode, plaintext blocks are XORed with the previous ciphertext block. This ensures that each encrypted block is unique and randomized even if blocks contain the same information. Please note that it is best to combine CBC with an HMAC and/or ensure that no errors are given such as "Padding error", "MAC error", "decryption failed" in order to be more resistant to a padding oracle attack. For the 
+Verify that Cipher Block Chaining (CBC) mode is used instead of ECB. In CBC mode, plaintext blocks are XORed with the previous ciphertext block. This ensures that each encrypted block is unique and randomized even if blocks contain the same information. Please note that it is best to combine CBC with an HMAC and/or ensure that no errors are given such as "Padding error", "MAC error", "decryption failed" in order to be more resistant to a padding oracle attack. 
 
 When storing encrypted data, we recommend using a block mode that also protects the integrity of the stored data, such as Galois/Counter Mode (GCM). The latter has the additional benefit that the algorithm is mandatory for each TLSv1.2 implementation, and thus is available on all modern platforms. To protect the integrity and authenticity of the data where CBC mode is used, it is recommended to combine the techniques of the Counter (CTR) mode and the Cipher Block Chaining-Message Authentication Code (CBC-MAC) into what is called CCM Mode ([NIST, 2004](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final "NIST")).
 

From edae473557cc7b09fc450d74c8a07c2adbb85ca4 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 17:00:55 +0100
Subject: [PATCH 016/117] correct spelling error

---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 4adaccfab82..5158cbabd50 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -158,7 +158,7 @@ Block-based encryption is performed upon discrete input blocks (for example, AES
 
 Verify that Cipher Block Chaining (CBC) mode is used instead of ECB. In CBC mode, plaintext blocks are XORed with the previous ciphertext block. This ensures that each encrypted block is unique and randomized even if blocks contain the same information. Please note that it is best to combine CBC with an HMAC and/or ensure that no errors are given such as "Padding error", "MAC error", "decryption failed" in order to be more resistant to a padding oracle attack. 
 
-When storing encrypted data, we recommend using a block mode that also protects the integrity of the stored data, such as Galois/Counter Mode (GCM). The latter has the additional benefit that the algorithm is mandatory for each TLSv1.2 implementation, and thus is available on all modern platforms. To protect the integrity and authenticity of the data where CBC mode is used, it is recommended to combine the techniques of the Counter (CTR) mode and the Cipher Block Chaining-Message Authentication Code (CBC-MAC) into what is called CCM Mode ([NIST, 2004](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final "NIST")).
+When storing encrypted data, we recommend using a block mode that also protects the integrity of the stored data, such as Galois/Counter Mode (GCM). The latter has the additional benefit that the algorithm is mandatory for each TLSv1.2 implementation, and thus is available on all modern platforms. To protect the integrity and authenticity of the data using CBC mode, it is recommended to combine the techniques of the Counter (CTR) mode and the Cipher Block Chaining-Message Authentication Code (CBC-MAC) into what is called CCM Mode ([NIST, 2004](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final "NIST")).
 
 For more information on effective block modes, see the [NIST guidelines on block mode selection](https://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html "NIST Modes Development, Proposed Modes").
 

From 6995427f0767fda4a7c256b45a5ba86b984c9cb6 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 17:02:03 +0100
Subject: [PATCH 017/117] correct spelling error

---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 5158cbabd50..978ade8bb8f 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -170,7 +170,7 @@ Pay attention to cryptographic libraries used in the code: many open source libr
 
 #### Using the same key for encryption and authentication
 
-One common mistake is to reuse the same key k for CBC encryption and CBC-MAC. Reuse of keys for different purposes is genarally not recommended, but in the case of CBC-MAC the mistake can lead to a MitM attack (["CBC-MAC", 2024.10.11](https://en.wikipedia.org/wiki/CBC-MAC "Wikipedia")).
+One common mistake is to reuse the same key for CBC encryption and CBC-MAC. Reuse of keys for different purposes is genarally not recommended, but in the case of CBC-MAC the mistake can lead to a MitM attack (["CBC-MAC", 2024.10.11](https://en.wikipedia.org/wiki/CBC-MAC "Wikipedia")).
 
 #### Initialization Vectors in stateful operation modes
 

From b8cd799ac1be1d1914b6f36202c3e916ed726a24 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 17:09:34 +0100
Subject: [PATCH 018/117] Update references

---
 Document/0x04g-Testing-Cryptography.md | 27 +++++++++++++-------------
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 978ade8bb8f..636de0767d4 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -11,7 +11,7 @@ Cryptography plays an especially important role in securing the user's data - ev
 
 The goal of cryptography is to provide constant confidentiality, data integrity, and authenticity, even in the face of an attack. Confidentiality involves ensuring data privacy through the use of encryption. Data integrity deals with data consistency and detection of tampering and modification of data through the use of hashing. Authenticity ensures that the data comes from a trusted source.
 
-Encryption algorithms converts plaintext data into cipher text that conceals the original content. Plaintext data can be restored from the cipher text through decryption. Encryption can be **symmetric** (encryption/decryption with same secret-key) or **asymmetric** (encryption/decryption using a public and private key pair). Symmetric encryption operations do not protect integrity unless used together with a recommended and approved cipher mode that supports an authenticated encryption function with an appropriatly random **IV** (Initialization vector) fulfilling the “uniqueness” requirement from "NIST 800-38D" ([NIST, 2007](https://csrc.nist.gov/pubs/sp/800/38/d/final)).
+Encryption algorithms converts plaintext data into cipher text that conceals the original content. Plaintext data can be restored from the cipher text through decryption. Encryption can be **symmetric** (encryption/decryption with same secret-key) or **asymmetric** (encryption/decryption using a public and private key pair). Symmetric encryption operations do not protect integrity unless used together with a recommended and approved cipher mode that supports an authenticated encryption function with an appropriatly random **IV** (Initialization vector) fulfilling the “uniqueness” requirement from "NIST 800-38D" ([NIST, 2007](https://csrc.nist.gov/pubs/sp/800/38/d/final "NIST: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC")).
 
 **Symmetric-key encryption algorithms** use the same key for both encryption and decryption. This type of encryption is fast and suitable for bulk data processing. Since everybody who has access to the key is able to decrypt the encrypted content, this method requires careful key management and centralized control over key distribution.
 
@@ -47,7 +47,7 @@ Please make sure that:
 
 - Cryptographic algorithms are up to date and in-line with industry standards. This includes, but is not limited to outdated block ciphers (e.g. DES), stream ciphers (e.g. RC4), as well as hash functions (e.g. MD5) and broken random number generators like Dual_EC_DRBG (even if they are NIST certified). All of these should be marked as insecure and should not be used and removed from the application and server.
 - Key lengths are in-line with industry standards and provide protection for sufficient amount of time. A comparison of different key lengths and the protection they provide, taking into account Moore's law, is available [online](https://www.keylength.com/ "Keylength comparison").
-- Through NIST SP 800-131A on "Transitioning the Use of Cryptographic Algorithms and Key Lengths" [(NIST, 2024)](https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd), NIST provides recommendations and guidance on how to align with future recommendations and how to transition to stronger cryptographic keys and more robust algorithms.
+- Through NIST SP 800-131A on "Transitioning the Use of Cryptographic Algorithms and Key Lengths" [(NIST, 2024)](https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd "NIST: Transitioning the Use of Cryptographic Algorithms and Key Lengths"), NIST provides recommendations and guidance on how to align with future recommendations and how to transition to stronger cryptographic keys and more robust algorithms.
 - Cryptographic means are not mixed with each other: e.g. you do not sign with a public key, or try to reuse a key pair used for a signature to do encryption.
 - Cryptographic parameters are well defined within reasonable range. This includes, but is not limited to: cryptographic salt, which should be at least the same length as hash function output, reasonable choice of password derivation function and iteration count (e.g. PBKDF2, scrypt or bcrypt), IVs being random and unique, fit-for-purpose block encryption modes (e.g. ECB should not be used, except specific cases), key management being done properly (e.g. 3DES should have three independent keys) and so on.
 
@@ -67,21 +67,20 @@ For more information on algorithm choice and best practices, see the following r
 - ["Commercial National Security Algorithm Suite and Quantum Computing FAQ"](https://cryptome.org/2016/01/CNSA-Suite-and-Quantum-Computing-FAQ.pdf "Commercial National Security Algorithm Suite and Quantum Computing FAQ")
 - [NIST recommendations (2019)](https://www.keylength.com/en/4/ "NIST recommendations")
 - [BSI recommendations (2019)](https://www.keylength.com/en/8/ "BSI recommendations")
-- NIST advises using RSA-based key-transport schemes with a minimum modulus length of at least 2048 bits according to 800-56B Rev. 2 ([NIST, 2019](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final))
-- NIST advises using ECC-based key-agreement schemes, such as Elliptic Curve Diffie-Hellman (ECDH), utilizing curves between P-224 to P-521 according to 800-56A Rev. 3 ([NIST, 2018](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final)).
-- RSA, ECDSA and EdDSA are approved techniques by NIST for digital signature generation according to "FIPS 186-4" ([NIST, 2023](https://csrc.nist.gov/pubs/fips/186-5/final)). Keep in mind that DSA only shall be used to verify previously genererated digital signatures.
-- NIST Digital Signature Standard, FIPS 186-5 (DSS) [(NIST, 2023)](https://csrc.nist.gov/pubs/fips/186-5/final)
-- Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters, NIST SP 800-186 [(NIST, 2023)(https://csrc.nist.gov/pubs/sp/800/186/final)]
+- NIST advises using RSA-based key-transport schemes with a minimum modulus length of at least 2048 bits according to 800-56B Rev. 2 ([NIST, 2019](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final "NIST: Recommendation for Pair-Wise Key-Establishment Using Integer Factorization Cryptography"))
+- NIST advises using ECC-based key-agreement schemes, such as Elliptic Curve Diffie-Hellman (ECDH), utilizing curves between P-224 to P-521 according to 800-56A Rev. 3 ([NIST, 2018](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final "NIST: Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography")).
+- RSA, ECDSA and EdDSA are approved techniques by NIST for digital signature generation according to "FIPS 186-5" ([NIST, 2023](https://csrc.nist.gov/pubs/fips/186-5/final "NIST: Digital Signature Standard (DSS)")). Keep in mind that DSA only shall be used to verify previously genererated digital signatures.
+- Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters, NIST SP 800-186 [(NIST, 2023)(https://csrc.nist.gov/pubs/sp/800/186/final "NIST: Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters")]
 
 ## Post-Quantum
 
 ### Public-key encryption algorithms
 
-NIST has approved CRYSTALS-Kyber as a post-quantum key encapsulation mechanism (KEM) to establish a shared secret key over a public channel. The secret can then be used with symmetric-key cryptographic algorithms to perform encryption and decryption. This according to FIPS 203 ([NIST, 2024](https://csrc.nist.gov/pubs/fips/203/final)).
+NIST has approved CRYSTALS-Kyber as a post-quantum key encapsulation mechanism (KEM) to establish a shared secret key over a public channel. The secret can then be used with symmetric-key cryptographic algorithms to perform encryption and decryption. This according to FIPS 203 ([NIST, 2024](https://csrc.nist.gov/pubs/fips/203/final "NIST: Module-Lattice-Based Key-Encapsulation Mechanism Standard")).
 
 ## Signatures
 
-NIST has approved [SLH-DSA](https://csrc.nist.gov/pubs/fips/205/final) (NIST, 2024) and [ML-DSA](https://csrc.nist.gov/pubs/fips/204/final) (NIST, 2024) as recommended digital signature algorithm to be used in for post-quatum signatures generation and verification.
+NIST has approved [SLH-DSA](https://csrc.nist.gov/pubs/fips/205/final "NIST: Stateless Hash-Based Digital Signature Standard") (NIST, 2024) and [ML-DSA](https://csrc.nist.gov/pubs/fips/204/final "NIST: Module-Lattice-Based Digital Signature Standard") (NIST, 2024) as recommended digital signature algorithm to be used in for post-quatum signatures generation and verification.
 
 ## Common Configuration Issues
 
@@ -120,14 +119,14 @@ Cryptographic algorithms (such as symmetric encryption or some MACs) expect a se
 - A user-supplied password will realistically consist mostly of displayable and pronounceable characters. Therefore, only some of the possible 256 ASCII characters are used and entropy is decreased by approximately a factor of four.
 - In cases where the user-supplied password is based on a pin, the key can be easily reconstructed by using the key generation function implemented on the mobile phone as an "oracle".
 
-Ensure that passwords aren't directly passed into an encryption function. The key that is input to a key-derivation function is called a key-derivation key (KDK). A KDK **shall** be a cryptographic key, but the KDK used as an input to one of the key-derivation functions specified in this Recommendation can, for example, be generated by an approved cryptographic random bit generator, e.g. by a deterministic random bit generator (see: [NIST 800-108, rev 1](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST")) ([NIST, 2022](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST")).
-Choose an appropriate iteration count when using password derivation functions. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to consider implementation of algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2"). Also see ["OWASP Password Storage Cheat Sheet"](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction "OWASP Cheat Sheet Series") for recommendation on iteration count when using key derivation functions using Argon2, scrypt, bcrypt or PBKDF2.
+Ensure that passwords aren't directly passed into an encryption function. The key that is input to a key-derivation function is called a key-derivation key (KDK). A KDK **shall** be a cryptographic key, but the KDK used as an input to one of the key-derivation functions specified in this Recommendation can, for example, be generated by an approved cryptographic random bit generator, e.g. by a deterministic random bit generator (see: [NIST 800-108, rev 1](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")) ([NIST, 2022](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")).
+Choose an appropriate iteration count when using password derivation functions. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to consider implementation of algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2"). Also see ["OWASP Password Storage Cheat Sheet"](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction "OWASP Cheat Sheet Series: Password Storage Cheat Sheet") for recommendation on iteration count when using key derivation functions using Argon2, scrypt, bcrypt or PBKDF2.
 
 ### Vulnerable Random Number Generators
 
 It is fundamentally impossible to produce truly random numbers on any deterministic device. Pseudo-random number generators (PRNG) compensate for this by producing a stream of pseudo-random numbers - a stream of numbers that appear as if they were randomly generated. The quality of the generated numbers varies with the type of algorithm used. Cryptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks (e.g. it is statistically infeasible to predict the next number produced).
 
-PRNG can be vulnerable when developers use a regular PRNG for cryptographic purposes, instead of a cryptographically-secure PRNG (["Cryptographically secure pseudorandom number generator", 2025.01.31](https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator "WIkipedia")). 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.
+PRNG can be vulnerable when developers use a regular PRNG for cryptographic purposes, instead of a cryptographically-secure PRNG (["Cryptographically secure pseudorandom number generator", 2025.01.31](https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator "WIkipedia: Cryptographically secure pseudorandom number generator")). 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.
 
 Mobile SDKs offer standard implementations of PRNG algorithms that produce numbers with sufficient artificial randomness. We'll introduce the available APIs in the Android and iOS specific sections.
 
@@ -158,7 +157,7 @@ Block-based encryption is performed upon discrete input blocks (for example, AES
 
 Verify that Cipher Block Chaining (CBC) mode is used instead of ECB. In CBC mode, plaintext blocks are XORed with the previous ciphertext block. This ensures that each encrypted block is unique and randomized even if blocks contain the same information. Please note that it is best to combine CBC with an HMAC and/or ensure that no errors are given such as "Padding error", "MAC error", "decryption failed" in order to be more resistant to a padding oracle attack. 
 
-When storing encrypted data, we recommend using a block mode that also protects the integrity of the stored data, such as Galois/Counter Mode (GCM). The latter has the additional benefit that the algorithm is mandatory for each TLSv1.2 implementation, and thus is available on all modern platforms. To protect the integrity and authenticity of the data using CBC mode, it is recommended to combine the techniques of the Counter (CTR) mode and the Cipher Block Chaining-Message Authentication Code (CBC-MAC) into what is called CCM Mode ([NIST, 2004](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final "NIST")).
+When storing encrypted data, we recommend using a block mode that also protects the integrity of the stored data, such as Galois/Counter Mode (GCM). The latter has the additional benefit that the algorithm is mandatory for each TLSv1.2 implementation, and thus is available on all modern platforms. To protect the integrity and authenticity of the data using CBC mode, it is recommended to combine the techniques of the Counter (CTR) mode and the Cipher Block Chaining-Message Authentication Code (CBC-MAC) into what is called CCM Mode ([NIST, 2004](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final "NIST: Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality")).
 
 For more information on effective block modes, see the [NIST guidelines on block mode selection](https://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html "NIST Modes Development, Proposed Modes").
 
@@ -170,7 +169,7 @@ Pay attention to cryptographic libraries used in the code: many open source libr
 
 #### Using the same key for encryption and authentication
 
-One common mistake is to reuse the same key for CBC encryption and CBC-MAC. Reuse of keys for different purposes is genarally not recommended, but in the case of CBC-MAC the mistake can lead to a MitM attack (["CBC-MAC", 2024.10.11](https://en.wikipedia.org/wiki/CBC-MAC "Wikipedia")).
+One common mistake is to reuse the same key for CBC encryption and CBC-MAC. Reuse of keys for different purposes is genarally not recommended, but in the case of CBC-MAC the mistake can lead to a MitM attack (["CBC-MAC", 2024.10.11](https://en.wikipedia.org/wiki/CBC-MAC "Wikipedia: CBC-MAC")).
 
 #### Initialization Vectors in stateful operation modes
 

From 0f7ec6341bfbb3ec25c2266905b032100e0e622f Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 17:18:35 +0100
Subject: [PATCH 019/117] Remove whitespace

---
 Document/0x04g-Testing-Cryptography.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 636de0767d4..16ff017b253 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -55,7 +55,7 @@ We recommend the following algorithms:
 
 - Confidentiality algorithms: AES-GCM-256 or ChaCha20-Poly1305
 - Integrity algorithms: SHA-256, SHA-384, SHA-512, BLAKE3, the SHA-3 family
-- Digital signature algorithms: RSA (3072 bits and higher), ECDSA with NIST P-384 or EdDSA with Edwards448. 
+- Digital signature algorithms: RSA (3072 bits and higher), ECDSA with NIST P-384 or EdDSA with Edwards448.
 - Key establishment algorithms: RSA (3072 bits and higher), DH (3072 bits or higher), ECDH with NIST P-384
 
 **Please note:** The Recommendations are based on current industry perception regarding what is considered to be appropriate and are in line with NIST recommendations beyond 2030, but does not necessarily take into account quantum computing advancements. For advice on post-quantum, please see **Post-Quantum** below.
@@ -155,7 +155,7 @@ Block-based encryption is performed upon discrete input blocks (for example, AES
 
 <img src="Images/Chapters/0x07c/EncryptionMode.png" width="550px" />
 
-Verify that Cipher Block Chaining (CBC) mode is used instead of ECB. In CBC mode, plaintext blocks are XORed with the previous ciphertext block. This ensures that each encrypted block is unique and randomized even if blocks contain the same information. Please note that it is best to combine CBC with an HMAC and/or ensure that no errors are given such as "Padding error", "MAC error", "decryption failed" in order to be more resistant to a padding oracle attack. 
+Verify that Cipher Block Chaining (CBC) mode is used instead of ECB. In CBC mode, plaintext blocks are XORed with the previous ciphertext block. This ensures that each encrypted block is unique and randomized even if blocks contain the same information. Please note that it is best to combine CBC with an HMAC and/or ensure that no errors are given such as "Padding error", "MAC error", "decryption failed" in order to be more resistant to a padding oracle attack.
 
 When storing encrypted data, we recommend using a block mode that also protects the integrity of the stored data, such as Galois/Counter Mode (GCM). The latter has the additional benefit that the algorithm is mandatory for each TLSv1.2 implementation, and thus is available on all modern platforms. To protect the integrity and authenticity of the data using CBC mode, it is recommended to combine the techniques of the Counter (CTR) mode and the Cipher Block Chaining-Message Authentication Code (CBC-MAC) into what is called CCM Mode ([NIST, 2004](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final "NIST: Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality")).
 

From 7f0adb127f9b813def6ed03aa3701a8f641ed1c5 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 17:20:03 +0100
Subject: [PATCH 020/117] correct spelling errors

---
 Document/0x04g-Testing-Cryptography.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 16ff017b253..591f79abdd5 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -11,7 +11,7 @@ Cryptography plays an especially important role in securing the user's data - ev
 
 The goal of cryptography is to provide constant confidentiality, data integrity, and authenticity, even in the face of an attack. Confidentiality involves ensuring data privacy through the use of encryption. Data integrity deals with data consistency and detection of tampering and modification of data through the use of hashing. Authenticity ensures that the data comes from a trusted source.
 
-Encryption algorithms converts plaintext data into cipher text that conceals the original content. Plaintext data can be restored from the cipher text through decryption. Encryption can be **symmetric** (encryption/decryption with same secret-key) or **asymmetric** (encryption/decryption using a public and private key pair). Symmetric encryption operations do not protect integrity unless used together with a recommended and approved cipher mode that supports an authenticated encryption function with an appropriatly random **IV** (Initialization vector) fulfilling the “uniqueness” requirement from "NIST 800-38D" ([NIST, 2007](https://csrc.nist.gov/pubs/sp/800/38/d/final "NIST: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC")).
+Encryption algorithms converts plaintext data into cipher text that conceals the original content. Plaintext data can be restored from the cipher text through decryption. Encryption can be **symmetric** (encryption/decryption with same secret-key) or **asymmetric** (encryption/decryption using a public and private key pair). Symmetric encryption operations do not protect integrity unless used together with a recommended and approved cipher mode that supports an authenticated encryption function with an appropriately random **IV** (Initialization vector) fulfilling the “uniqueness” requirement from "NIST 800-38D" ([NIST, 2007](https://csrc.nist.gov/pubs/sp/800/38/d/final "NIST: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC")).
 
 **Symmetric-key encryption algorithms** use the same key for both encryption and decryption. This type of encryption is fast and suitable for bulk data processing. Since everybody who has access to the key is able to decrypt the encrypted content, this method requires careful key management and centralized control over key distribution.
 
@@ -69,7 +69,7 @@ For more information on algorithm choice and best practices, see the following r
 - [BSI recommendations (2019)](https://www.keylength.com/en/8/ "BSI recommendations")
 - NIST advises using RSA-based key-transport schemes with a minimum modulus length of at least 2048 bits according to 800-56B Rev. 2 ([NIST, 2019](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final "NIST: Recommendation for Pair-Wise Key-Establishment Using Integer Factorization Cryptography"))
 - NIST advises using ECC-based key-agreement schemes, such as Elliptic Curve Diffie-Hellman (ECDH), utilizing curves between P-224 to P-521 according to 800-56A Rev. 3 ([NIST, 2018](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final "NIST: Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography")).
-- RSA, ECDSA and EdDSA are approved techniques by NIST for digital signature generation according to "FIPS 186-5" ([NIST, 2023](https://csrc.nist.gov/pubs/fips/186-5/final "NIST: Digital Signature Standard (DSS)")). Keep in mind that DSA only shall be used to verify previously genererated digital signatures.
+- RSA, ECDSA and EdDSA are approved techniques by NIST for digital signature generation according to "FIPS 186-5" ([NIST, 2023](https://csrc.nist.gov/pubs/fips/186-5/final "NIST: Digital Signature Standard (DSS)")). Keep in mind that DSA only shall be used to verify previously generated digital signatures.
 - Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters, NIST SP 800-186 [(NIST, 2023)(https://csrc.nist.gov/pubs/sp/800/186/final "NIST: Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters")]
 
 ## Post-Quantum
@@ -169,7 +169,7 @@ Pay attention to cryptographic libraries used in the code: many open source libr
 
 #### Using the same key for encryption and authentication
 
-One common mistake is to reuse the same key for CBC encryption and CBC-MAC. Reuse of keys for different purposes is genarally not recommended, but in the case of CBC-MAC the mistake can lead to a MitM attack (["CBC-MAC", 2024.10.11](https://en.wikipedia.org/wiki/CBC-MAC "Wikipedia: CBC-MAC")).
+One common mistake is to reuse the same key for CBC encryption and CBC-MAC. Reuse of keys for different purposes is generally not recommended, but in the case of CBC-MAC the mistake can lead to a MitM attack (["CBC-MAC", 2024.10.11](https://en.wikipedia.org/wiki/CBC-MAC "Wikipedia: CBC-MAC")).
 
 #### Initialization Vectors in stateful operation modes
 

From eaef51fdcc054b62ccbaeefd74f2bf7117efcc0b Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 19:55:51 +0100
Subject: [PATCH 021/117] Correct spelling

---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 591f79abdd5..2badd7993ed 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -80,7 +80,7 @@ NIST has approved CRYSTALS-Kyber as a post-quantum key encapsulation mechanism (
 
 ## Signatures
 
-NIST has approved [SLH-DSA](https://csrc.nist.gov/pubs/fips/205/final "NIST: Stateless Hash-Based Digital Signature Standard") (NIST, 2024) and [ML-DSA](https://csrc.nist.gov/pubs/fips/204/final "NIST: Module-Lattice-Based Digital Signature Standard") (NIST, 2024) as recommended digital signature algorithm to be used in for post-quatum signatures generation and verification.
+NIST has approved [SLH-DSA](https://csrc.nist.gov/pubs/fips/205/final "NIST: Stateless Hash-Based Digital Signature Standard") (NIST, 2024) and [ML-DSA](https://csrc.nist.gov/pubs/fips/204/final "NIST: Module-Lattice-Based Digital Signature Standard") (NIST, 2024) as recommended digital signature algorithm to be used for post-quatum signature generation and verification.
 
 ## Common Configuration Issues
 

From aa6bcafc924cf58c54f1263e17b39fdabc7a23cd Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 19:58:01 +0100
Subject: [PATCH 022/117] Correct grammar

---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 2badd7993ed..ee01b397a7b 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -117,7 +117,7 @@ Cryptographic algorithms (such as symmetric encryption or some MACs) expect a se
 
 - If the password is smaller than the key, the full key space isn't used. The remaining space is padded (spaces are sometimes used for padding).
 - A user-supplied password will realistically consist mostly of displayable and pronounceable characters. Therefore, only some of the possible 256 ASCII characters are used and entropy is decreased by approximately a factor of four.
-- In cases where the user-supplied password is based on a pin, the key can be easily reconstructed by using the key generation function implemented on the mobile phone as an "oracle".
+- In cases where the user-supplied password is based on a pin, the key can easily be reconstructed by using the key generation function implemented on the mobile phone as an "oracle".
 
 Ensure that passwords aren't directly passed into an encryption function. The key that is input to a key-derivation function is called a key-derivation key (KDK). A KDK **shall** be a cryptographic key, but the KDK used as an input to one of the key-derivation functions specified in this Recommendation can, for example, be generated by an approved cryptographic random bit generator, e.g. by a deterministic random bit generator (see: [NIST 800-108, rev 1](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")) ([NIST, 2022](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")).
 Choose an appropriate iteration count when using password derivation functions. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to consider implementation of algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2"). Also see ["OWASP Password Storage Cheat Sheet"](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction "OWASP Cheat Sheet Series: Password Storage Cheat Sheet") for recommendation on iteration count when using key derivation functions using Argon2, scrypt, bcrypt or PBKDF2.

From 6251ea2339e7e7eef1729ffedf710ecabd0a0c76 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Fri, 7 Mar 2025 20:01:10 +0100
Subject: [PATCH 023/117] Improve language

---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index ee01b397a7b..a94138d1385 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -119,7 +119,7 @@ Cryptographic algorithms (such as symmetric encryption or some MACs) expect a se
 - A user-supplied password will realistically consist mostly of displayable and pronounceable characters. Therefore, only some of the possible 256 ASCII characters are used and entropy is decreased by approximately a factor of four.
 - In cases where the user-supplied password is based on a pin, the key can easily be reconstructed by using the key generation function implemented on the mobile phone as an "oracle".
 
-Ensure that passwords aren't directly passed into an encryption function. The key that is input to a key-derivation function is called a key-derivation key (KDK). A KDK **shall** be a cryptographic key, but the KDK used as an input to one of the key-derivation functions specified in this Recommendation can, for example, be generated by an approved cryptographic random bit generator, e.g. by a deterministic random bit generator (see: [NIST 800-108, rev 1](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")) ([NIST, 2022](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")).
+Ensure that passwords aren't directly passed into an encryption function. The key that is input to a key-derivation function is called a key-derivation key (KDK). A KDK **shall** be a cryptographic key, but the KDK used as an input to a recommended key-derivation functions can, for example, be generated by an approved cryptographic random bit generator, e.g. by a deterministic random bit generator (see: [NIST 800-108, rev 1](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")) ([NIST, 2022](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")).
 Choose an appropriate iteration count when using password derivation functions. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to consider implementation of algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2"). Also see ["OWASP Password Storage Cheat Sheet"](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction "OWASP Cheat Sheet Series: Password Storage Cheat Sheet") for recommendation on iteration count when using key derivation functions using Argon2, scrypt, bcrypt or PBKDF2.
 
 ### Vulnerable Random Number Generators

From fc3765ae99e8990e914de44dcd43eba7dad24a8b Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sat, 8 Mar 2025 09:06:11 +0100
Subject: [PATCH 024/117] shorten title

---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index a94138d1385..8197ab50010 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -51,7 +51,7 @@ Please make sure that:
 - Cryptographic means are not mixed with each other: e.g. you do not sign with a public key, or try to reuse a key pair used for a signature to do encryption.
 - Cryptographic parameters are well defined within reasonable range. This includes, but is not limited to: cryptographic salt, which should be at least the same length as hash function output, reasonable choice of password derivation function and iteration count (e.g. PBKDF2, scrypt or bcrypt), IVs being random and unique, fit-for-purpose block encryption modes (e.g. ECB should not be used, except specific cases), key management being done properly (e.g. 3DES should have three independent keys) and so on.
 
-We recommend the following algorithms:
+Recommend algorithms:
 
 - Confidentiality algorithms: AES-GCM-256 or ChaCha20-Poly1305
 - Integrity algorithms: SHA-256, SHA-384, SHA-512, BLAKE3, the SHA-3 family

From 071142930f5efcb44663161db896b874d1a4d3c9 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sat, 8 Mar 2025 09:50:48 +0100
Subject: [PATCH 025/117] Cleanup headlines

---
 Document/0x04g-Testing-Cryptography.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 8197ab50010..9e0ea445d9f 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -111,7 +111,7 @@ If the app relies on an additional encrypted container stored in app data, check
 
 Secret keys must be stored in secure device storage whenever symmetric cryptography is used in mobile apps. For more information on the platform-specific APIs, see the "[Data Storage on Android](0x05d-Testing-Data-Storage.md)" and "[Data Storage on iOS](0x06d-Testing-Data-Storage.md)" chapters.
 
-### Vulnerable Key Generation Functions
+### Key Generation Functions
 
 Cryptographic algorithms (such as symmetric encryption or some MACs) expect a secret input of a given size. For example, AES uses a key of exactly 16 bytes. A native implementation might use the user-supplied password directly as an input key. Using a user-supplied password as an input key has the following problems:
 
@@ -122,7 +122,7 @@ Cryptographic algorithms (such as symmetric encryption or some MACs) expect a se
 Ensure that passwords aren't directly passed into an encryption function. The key that is input to a key-derivation function is called a key-derivation key (KDK). A KDK **shall** be a cryptographic key, but the KDK used as an input to a recommended key-derivation functions can, for example, be generated by an approved cryptographic random bit generator, e.g. by a deterministic random bit generator (see: [NIST 800-108, rev 1](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")) ([NIST, 2022](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")).
 Choose an appropriate iteration count when using password derivation functions. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to consider implementation of algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2"). Also see ["OWASP Password Storage Cheat Sheet"](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction "OWASP Cheat Sheet Series: Password Storage Cheat Sheet") for recommendation on iteration count when using key derivation functions using Argon2, scrypt, bcrypt or PBKDF2.
 
-### Vulnerable Random Number Generators
+### Random Number Generators
 
 It is fundamentally impossible to produce truly random numbers on any deterministic device. Pseudo-random number generators (PRNG) compensate for this by producing a stream of pseudo-random numbers - a stream of numbers that appear as if they were randomly generated. The quality of the generated numbers varies with the type of algorithm used. Cryptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks (e.g. it is statistically infeasible to predict the next number produced).
 

From 99d63de2e14096e4ce712c1b8a6e747a3286fdb2 Mon Sep 17 00:00:00 2001
From: Johan Sydseter <johan.sydseter@admincontrol.com>
Date: Tue, 11 Mar 2025 13:34:39 +0100
Subject: [PATCH 026/117] Adding text to MASWE 0010, 0021, 0024, 0025 and
 replacing the word weak with more specific words like insufficent,
 predictable

---
 Document/0x04g-Testing-Cryptography.md | 45 +++++++++++++++++++++-----
 weaknesses/MASVS-CRYPTO/MASWE-0009.md  | 14 ++++----
 weaknesses/MASVS-CRYPTO/MASWE-0010.md  | 32 +++++++++++++++++-
 weaknesses/MASVS-CRYPTO/MASWE-0019.md  |  4 +--
 weaknesses/MASVS-CRYPTO/MASWE-0020.md  | 12 +++----
 weaknesses/MASVS-CRYPTO/MASWE-0021.md  | 34 +++++++++++++++++--
 weaknesses/MASVS-CRYPTO/MASWE-0023.md  | 10 +++---
 weaknesses/MASVS-CRYPTO/MASWE-0024.md  | 29 +++++++++++++++--
 weaknesses/MASVS-CRYPTO/MASWE-0025.md  | 23 ++++++++++---
 weaknesses/MASVS-CRYPTO/MASWE-0027.md  |  2 +-
 10 files changed, 166 insertions(+), 39 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 9e0ea445d9f..4dd1417bca6 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -17,7 +17,7 @@ Encryption algorithms converts plaintext data into cipher text that conceals the
 
 **Public-key encryption algorithms** operate with two separate keys: the public key and the private key. The public key can be distributed freely while the private key shouldn't be shared with anyone. A message encrypted with the public key can only be decrypted with the private key and vice-versa. Since asymmetric encryption is several times slower than symmetric operations, it's typically only used to encrypt small amounts of data, such as symmetric keys for bulk encryption.
 
-**Hashing** isn't a form of encryption, but it does use cryptography. Hash functions deterministically map arbitrary pieces of data into fixed-length values. It's easy to compute the hash from the input, but very difficult (i.e. infeasible) to determine the original input from the hash. Additionally, the hash will completely change when even a single bit of the input changes. Hash functions are used for integrity verification, but don't provide an authenticity guarantee.
+**Hashing** isn't a form of encryption, but it does use cryptography. Hash functions deterministically map arbitrary pieces of data into fixed-length values. It's easy to compute the hash from the input, but very difficult (i.e. infeasible) to determine the original input from the hash. Additionally, the hash will completely change when even a single bit of the input changes. Hash functions are used for password storage, integrity verification (e.g: digital signatures or document management) or file management. Hash functions don't provide an authenticity guarantee, but can be combined as cryptographic primitives to do so.
 
 **Message Authentication Codes** (MACs) combine other cryptographic mechanisms (such as symmetric encryption or hashes) with secret keys to provide both integrity and authenticity protection. However, in order to verify a MAC, multiple entities have to share the same secret key and any of those entities can generate a valid MAC. HMACs, the most commonly used type of MAC, rely on hashing as the underlying cryptographic primitive. The full name of an HMAC algorithm usually includes the underlying hash function's type (for example, HMAC-SHA256 uses the SHA-256 hash function).
 
@@ -111,16 +111,38 @@ If the app relies on an additional encrypted container stored in app data, check
 
 Secret keys must be stored in secure device storage whenever symmetric cryptography is used in mobile apps. For more information on the platform-specific APIs, see the "[Data Storage on Android](0x05d-Testing-Data-Storage.md)" and "[Data Storage on iOS](0x06d-Testing-Data-Storage.md)" chapters.
 
-### Key Generation Functions
+### Improper Key Derivation Functions
 
-Cryptographic algorithms (such as symmetric encryption or some MACs) expect a secret input of a given size. For example, AES uses a key of exactly 16 bytes. A native implementation might use the user-supplied password directly as an input key. Using a user-supplied password as an input key has the following problems:
+When talking about key derivation functions KDF in the context of mobile application we are usually referring to cryptographic key derivation and not password storage. This chapter mainly focus on KDF in the context of cryptographic key derivation and not KDF in the context of password storage. For general advice on password storage, please read the [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html).
+Key derivation functions derive bytes suitable for cryptographic operations from passwords or other data sources using a pseudo-random function (PRF)
 
-- If the password is smaller than the key, the full key space isn't used. The remaining space is padded (spaces are sometimes used for padding).
-- A user-supplied password will realistically consist mostly of displayable and pronounceable characters. Therefore, only some of the possible 256 ASCII characters are used and entropy is decreased by approximately a factor of four.
-- In cases where the user-supplied password is based on a pin, the key can easily be reconstructed by using the key generation function implemented on the mobile phone as an "oracle".
+Different KDFs are suitable for different tasks such as:
 
-Ensure that passwords aren't directly passed into an encryption function. The key that is input to a key-derivation function is called a key-derivation key (KDK). A KDK **shall** be a cryptographic key, but the KDK used as an input to a recommended key-derivation functions can, for example, be generated by an approved cryptographic random bit generator, e.g. by a deterministic random bit generator (see: [NIST 800-108, rev 1](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")) ([NIST, 2022](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")).
-Choose an appropriate iteration count when using password derivation functions. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to consider implementation of algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2"). Also see ["OWASP Password Storage Cheat Sheet"](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction "OWASP Cheat Sheet Series: Password Storage Cheat Sheet") for recommendation on iteration count when using key derivation functions using Argon2, scrypt, bcrypt or PBKDF2.
+- Cryptographic key derivation
+
+    - Together with a non-secret parameter to derive one or more keys from a common secret value. Also known as known as "key diversification"
+    - As components of multiparty key-agreement protocols (e.g: [KDF1](https://en.wikipedia.org/wiki/IEEE_P1363)).
+    - To derive keys from secret passwords or passphrases.
+    - To derive keys of different length from the ones provided (e.g: [PBKDF2HMAC](https://en.wikipedia.org/wiki/PBKDF2) or [HKDF](https://en.wikipedia.org/wiki/HKDF)).
+    - [Key stretching](https://en.wikipedia.org/wiki/Key_stretching) and [key strengthening](https://en.wikipedia.org/wiki/Key_derivation_function#Key_stretching_and_key_strengthening).
+
+- Password storage
+
+    - In order to ensure attacker's can't use a stolen password even in the event of a data breach, passwords are stored as hashes computed through a computationally intensive KDF. The ideal password storage's KDF should be demanding on both computational and memory resources.
+
+source: ([Wikipedia, 2025.02.21"](https://en.wikipedia.org/wiki/Key_derivation_function "Key derivation function"))
+
+When using a KDF for cryptographic operations always ensure to use a recommended and approved KDF properly according to the latest recommendations and the software provider's documentation. E.g Only using a key derivation functions that is constructed from hashes against which no non-trivial pre-image or length-extension attacks are known and where attacking the key derivation function directly is infeasible. Using user-supplied input together with HKDF will make it easy for password crackers to execute a preimage attack.
+
+Choose a KDF that use an adaptive hash function that can be configured to change the amount of computational effort needed to compute the hash, such as the number of iterations ("stretching") or the amount of memory required. Some hash functions perform salting automatically. These functions can significantly increase the overhead for a brute force attack compared to intentionally-fast functions. For example, rainbow table attacks can become infeasible due to the high computing overhead. Finally, since computing power gets faster and cheaper over time, the technique can be reconfigured to increase the workload without forcing an entire replacement of the algorithm in use.
+
+Some hash functions that have one or more of these desired properties include [scrypt](https://www.tarsnap.com/scrypt.html), and [PBKDF2](https://www.rfc-editor.org/rfc/rfc2898). While there is active debate about which of these is the most effective, they are all stronger than using salts with hash functions with very little computing overhead.
+
+Note that using these functions can have an impact on performance, so they require special consideration to avoid denial-of-service attacks. However, their configurability provides finer control over how much CPU and memory is used, so it could be adjusted to suit the environment's needs. In the case where CPU and memory performance is a challenge try adjusting desired bit-length of the derived key instead of increasing the iteration account (e.g using HMAC-SHA512 instead of HMAC-SHA256). This might make the KDF more susceptible by brute-force attacks, but should be acceptable as long as you keep yourself within recommended guidelines.
+
+Unfortunately, "brute-force" attacks are quite liable to succeed where users selects passwords and pins with none or with too little entropy than what is required for cryptographic keys. Therefor, ensure that passwords and pins aren't directly passed into a HKDF. The key that is input to a key-derivation function is called a key-derivation key (KDK). A KDK **shall** be a cryptographic key, but the KDK used as an input to a recommended key-derivation functions can, for example, be generated by an approved cryptographic random bit generator, e.g. by a deterministic random bit generator (see: [NIST 800-108, rev 1](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")) ([NIST, 2022](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")).
+In cases where the input is user-controlled, use password hashing algorithm like Argon2, scrypt, bcrypt or PBKDF2 as a key derivation function to provide a sufficient level of computational effort.
+When using a password hashing algorithm as a KDF, also ensure to choose an appropriate iteration count that can provide sufficient computational efforts. Meaning that they make password or secret cracking attacks infeasible or expensive. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to implementation algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2"). Also see ["OWASP Password Storage Cheat Sheet"](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction "OWASP Cheat Sheet Series: Password Storage Cheat Sheet") for recommendation on iteration count when using key derivation functions using Argon2, scrypt, bcrypt or PBKDF2.
 
 ### Random Number Generators
 
@@ -130,6 +152,13 @@ PRNG can be vulnerable when developers use a regular PRNG for cryptographic purp
 
 Mobile SDKs offer standard implementations of PRNG algorithms that produce numbers with sufficient artificial randomness. We'll introduce the available APIs in the Android and iOS specific sections.
 
+### Weak hashing
+
+Make sure to choose a hash function that is built for the purpose you intend it for.
+When hashes are needed for integrity checks, choose an algorithm that is sufficiently collision resistant like the integrity algorithms SHA-256, SHA-384, SHA-512, BLAKE3 and the SHA-3 family. Choosing a weak algorithm may compromise the integrity and authenticity of data at rest and in transit. Also keep in mind that hash functions used for integrity checks, like the SHA series, should not be used for key derivation together with predictable input or in password hashing.
+
+
+
 ### Custom Implementations of Cryptography
 
 Inventing proprietary cryptographic functions is time consuming, difficult, and likely to fail. Instead, we can use well-known algorithms that are widely regarded as secure. Mobile operating systems offer standard cryptographic APIs that implement those algorithms.
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0009.md b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
index 99df93d6318..ce439aca37e 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0009.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
@@ -1,5 +1,5 @@
 ---
-title: Weak Cryptographic Key Generation
+title: Improper Cryptographic Key Generation
 id: MASWE-0009
 alias: weak-crypto-key-generation
 platform: [android, ios]
@@ -17,26 +17,26 @@ refs:
 - https://developer.android.com/reference/javax/crypto/KeyGenerator
 
 status: new
-
 ---
 
 ## Overview
 
 In cryptography, the security strength is heavily influenced by the methods used to generate cryptographic keys. One critical aspect is the key size, also known as the key length, which is measured in bits and must comply with the latest security best practices. Encryption algorithms that use insufficient key sizes are vulnerable to attack, while longer keys typically result in more complex encryption.
 
-However, even with an appropriately sized key, the security of the encryption can be compromised if the key generation process itself is flawed. For example a weak pseudorandom number generator (PRNG) can undermine cryptographic security by generating predictable or low-entropy keys. This reduces the effectiveness of the key length and makes it easier for attackers to guess or reproduce keys. Weak PRNGs can also produce repetitive patterns, leading to further vulnerabilities. Ensuring the use of strong, cryptographically secure PRNGs with high entropy seeding is essential for robust key security.
+However, even with an appropriately sized key, the security of the encryption can be compromised if the key generation process itself is flawed. For example using a pseudorandom number generator (PRNG) not meant for cryptographic purposes can undermine cryptographic security by generating predictable, weak or low-entropy keys. This reduces the effectiveness of the key length and makes it easier for attackers to guess or reproduce keys. Weak PRNG seeds can also produce repetitive patterns, leading to further vulnerabilities. Ensuring the use of strong, cryptographically secure PRNGs called CSPRNGs with high entropy seeding is essential for robust key security.
+The digest (or hash) of an improper implemented- or used hash function may allow and adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack).
 
 ## Impact
 
-- **Risk of Brute-Force Attacks**: Weak key generation, whether due to shorter key length or predictable random number generator (PRNG) inputs, increases the risk of brute-force attacks. Attackers can more easily guess or systematically try possible keys until they find the correct one.
-- **Loss of  Confidentiality**: Encryption relies on strong keys to maintain the confidentiality of sensitive data. Weak keys can allow attackers to decrypt and access confidential information, leading to unauthorized disclosure and potential data breaches.
-- **Loss of Integrity**: Weak key generation can compromise data integrity, allowing attackers to exploit vulnerabilities and potentially alter or tamper with the information without detection.
+- **Risk of Brute-Force Attacks**: Improper key generation, whether due to shorter key length or predictable random number generator (PRNG) inputs, increases the risk of brute-force attacks. Attackers can more easily guess or systematically try possible keys until they find the correct one.
+- **Loss of  Confidentiality**: Encryption relies on strong keys to maintain the confidentiality of sensitive data. Weak seed values can allow attackers to decrypt and access confidential information, leading to unauthorized disclosure and potential data breaches.
+- **Loss of Integrity**: Improper key generation can compromise data integrity, allowing attackers to exploit vulnerabilities and potentially alter or tamper with the information without detection.
 
 ## Modes of Introduction
 
 - **Inadequate Entropy During Key Generation**: Using a poor source of randomness can lead to predictable cryptographic keys. If the randomness lacks sufficient entropy, the generated keys may be easier for attackers to guess or recreate, compromising the security of the system.
 - **Insufficient Key Length**: Cryptographic keys that are too short provide inadequate security. For example, keys shorter than recommended lengths for modern algorithms may be vulnerable to brute force attacks, making them easier for attackers to break.
-- **Using Outdated or Weak Algorithms**: Relying on deprecated or inherently weak cryptographic algorithms can result in the generation of weaker keys. As these algorithms often have vulnerabilities or support shorter key lengths, they are more susceptible to modern attacks, compromising the overall security of the app.
+- **Using Outdated or Weak Algorithms**: Relying on deprecated, risky or inherently or broken cryptographic algorithms can result in the generation of weaker keys. As these algorithms often have vulnerabilities or support shorter key lengths, they are more susceptible to modern attacks, compromising the overall security of the app.
 
 ## Mitigations
 
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
index d8847dd7701..4047e584183 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
@@ -1,5 +1,5 @@
 ---
-title: Weak Cryptographic Key Derivation
+title: Improper Cryptographic Key Derivation
 id: MASWE-0010
 alias: weak-crypto-key-derivation
 platform: [android, ios]
@@ -20,3 +20,33 @@ status: draft
 
 ---
 
+## Overview
+
+Improper Key derivation functions will generate a key using a scheme or iteration count that does not provide a sufficient level of computational effort. This can open up the possibility for brute force password/secret cracking or dictionary attacks.
+In cases where a user-supplied password or pin is used without a sufficiently random salt the resulting output will be identical or similar enough to allow an attacker to execute a brute force attack to find the original password/pin using the KDF as an "oracle".
+A similar issue happens when the salt is user-supplied. Consider a mobile app that generates user keys from a master key on demand during installation. Let's say that a key used in the mobile app is derived from this master key using the username or other user supplied value as salt. Such an implementation can make it possible for an attacker to retrieve the derived key by using the username or supplied user value as input.
+Another common issue is using HKDF or any other type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HKDF aren't design for low-entropy inputs. Therefor password crackers can fairly efficiently crack massive amounts of passwords for KDFs that aren’t purposefully designed to be slow and memory-intensive. A similar issue happens when using deprecated, risky or broken KDF- or password hashing algorithms known to the vulnerable for various types of attacks.
+Also, cryptographic algorithms (such as symmetric encryption or some MACs) expect a secret input of a given size. For example, AES uses a key of exactly 16 bytes. A native implementation might use the user-supplied password directly as an input key. Using a user-supplied password or pin as an input key has the following problems:
+
+- If the password is smaller than the key, the full key space isn't used. The remaining space is padded (spaces are sometimes used for padding).
+- A user-supplied password will realistically consist mostly of displayable and pronounceable characters. Therefore, only some of the possible 256 ASCII characters are used and entropy is decreased by approximately a factor of four.
+
+## Impact
+
+- **Risk of Brute-Force Attacks**: Improper Key derivation functions open up for brute force password- and secret cracking, key or dictionary attacks such as rainbow tables.
+- **Loss of  Confidentiality**: Improper Key derivation may allow an attacker to guess or find the input and therefor steal the user's password or cryptographic key.
+- **Loss of Integrity**: Given that the attacker has access to the user's password or cryptographic key, the overall security of the app and mobile phone may be compromised.
+
+## Modes of Introduction
+
+- **Using static or predictable salt on low-entropy input**: Using user-supplied input together with a static or predictable salt makes it possible for the attacker to to pre-compute the hash value using dictionary attack, effectively disabling the protection that a salt would provide.
+- **Using user-supplied salt**: Using user-supplied salt will make it possible for an attacker to extract all derived keys through a KDF by supplying the user-supplied salt as an argument.
+- **Using non-resource intensive algorithms on low-entropy input**: Using user-supplied input together with HKDF makes it easy for password crackers to execute a preimage attack.
+- **Use a hash function as a general-purpose KDF**: In scenarios where the information used during key derivation is attacker-controlled, using a integrity based hash function (e.g from the SHA family) as KDF can expose the application to brute force or length-extension attacks.
+- **Using Deprecated, Risky or Broken Algorithms**: Relying on deprecated, risky or inherently broken cryptographic algorithms can result in the generation of weaker keys. As these algorithms often have vulnerabilities or support shorter key lengths, they are more susceptible to modern attacks, compromising the overall security of the app.
+
+## Mitigations
+
+- **Generate random salt using CSPRNGs with high entropy seeding**: Ensuring the use of strong, cryptographically secure PRNGs called CSPRNGs with high entropy seeding is essential for robust key security.
+- **Use Recommended and Approved algorithms that are fit for purpose**: In cases where the input is user-controlled, use key derivation functions such as Argon2, scrypt, bcrypt or PBKDF2 that provides a sufficient level of computational effort. Otherwise, ensure the input is thoroughly random using a recommended CSPRNG that guarantees high entropy seeding.
+- **Prefer HKDF and other KDFs that were designed specifically for key derivation**: HKDF and other KDFs specifically meant for key derivation will ensure the app isn't exposed to length-extension attacks.
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0019.md b/weaknesses/MASVS-CRYPTO/MASWE-0019.md
index f9aabf9d25d..94db683199b 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0019.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0019.md
@@ -1,5 +1,5 @@
 ---
-title: Potentially Weak Cryptography Implementations
+title: Deprecated, risky, or Noncompliant Cryptography Implementations
 id: MASWE-0019
 alias: potentially-weak-crypto-impl
 platform: [android, ios]
@@ -29,7 +29,7 @@ refs:
 
 ## Overview
 
-Outdated, weak, or noncompliant cryptographic implementations, such as those that do not meet established security standards such as FIPS 140-2/3 (Federal Information Processing Standards), may use algorithms that have not been sufficiently tested or that lack certification, may not follow best practices for secure key management, or may include custom cryptographic solutions that haven't undergone rigorous peer review or formal validation.
+Deprecated, risky, or noncompliant cryptographic implementations, such as those that do not meet established security standards such as FIPS 140-2/3 (Federal Information Processing Standards), may use algorithms that have not been sufficiently tested or that lack certification, may not follow best practices for secure key management, or may include custom cryptographic solutions that haven't undergone rigorous peer review or formal validation.
 
 ## Impact
 
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0020.md b/weaknesses/MASVS-CRYPTO/MASWE-0020.md
index af149840e2c..fa5f0145d9a 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0020.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0020.md
@@ -1,5 +1,5 @@
 ---
-title: Weak Encryption
+title: Deprecated, Risky, or Broken Encryption
 id: MASWE-0020
 alias: weak-encryption
 platform: [android, ios]
@@ -21,18 +21,18 @@ status: new
 
 ## Overview
 
-Weak encryption refers to cryptographic systems or implementations that are vulnerable to attack, allowing unauthorised individuals to decrypt secured data. This weakness can be due to a number of reasons, including the use of outdated algorithms, deprecated encryption modes such as ECB and improper implementation practices such as the use of a non-random or empty Initialisation Vector (IV).
+Deprecated, Risky, or Broken encryption refers to cryptographic systems or implementations that are vulnerable to attack, allowing unauthorized individuals to decrypt secured data. This  can be due to a number of reasons, including the use of deprecated, risky or broken algorithms, deprecated or risky encryption modes such as ECB and improper implementation practices such as the use of a non-random or empty Initialization Vector (IV).
 
 ## Impact
 
-- **Loss of Confidentiality**: Weak encryption may enable attackers to decipher and obtain sensitive information, resulting in unauthorized exposure and possible data breaches.
+- **Loss of Confidentiality**: Deprecated, risky, or broken encryption may enable attackers to decipher and obtain sensitive information, resulting in unauthorized exposure and possible data breaches.
 
-- **Loss of Integrity**: Weak encryption can compromise the integrity of data, allowing adversaries to alter or manipulate the information without detection.
+- **Loss of Integrity**: Deprecated, risky, or broken encryption can compromise the integrity of data, allowing adversaries to alter or manipulate the information without detection.
 
 ## Mode of Introduction
 
-- **Use of Deprecated Algorithms** : Relying on outdated or weak encryption algorithms can allow threat actors to attack the cipher text, key or exploit known vulnerabilities in the algorithm, for example through brute force attacks.
-- **Insecure Modes of Operation**:  Using modes that are considered deprecated increase the attack surface of encrypted information. For example the use of AES/ECB is deprecated as it divides the plaintext into blocks and encrypts each block separately using the same key. This makes the cipher text vulnerable to "known plaintext attacks" and leaks information about the structure of the original plaintext.
+- **Use of Deprecated Algorithms** : Relying on deprecated, risky or vulnerable encryption algorithms can allow threat actors to attack the cipher text, key or exploit known vulnerabilities in the algorithm, for example through brute force attacks.
+- **Insecure Modes of Operation**:  Using modes that are considered deprecated or risky increase the attack surface of encrypted information. For example the use of AES/ECB is deprecated as it divides the plaintext into blocks and encrypts each block separately using the same key. This makes the cipher text vulnerable to "known plaintext attacks" and leaks information about the structure of the original plaintext.
 - **Predictable Initialization Vectors (IVs)**: If IVs are not random or unique, they can be exploited in attacks like ciphertext injection or pattern recognition. This compromises the confidentiality of encrypted data, especially in modes like CBC (Cipher Block Chaining).
 - **Weak Keys**: Short or easily guessable keys compromise encryption strength. The use of small key sizes (e.g., 56-bit keys in DES) can make the encryption susceptible to brute-force attacks. Best practices recommend keys of at least 256 bits for strong encryption.
 - **Misuse of Non-Cryptographic Operations**: Relying on techniques such as XOR, Base64 encoding, or simple obfuscation methods for security purposes. These methods provide no actual encryption and can be easily reversed or decoded, exposing sensitive data.
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0021.md b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
index 402b864b801..edbe14b80b4 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0021.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
@@ -1,5 +1,5 @@
 ---
-title: Weak Hashing
+title: Weak, Risky or Broken Hashing
 id: MASWE-0021
 alias: weak-hashing
 platform: [android, ios]
@@ -12,12 +12,42 @@ mappings:
 refs:
 - https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality
 - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf
+- https://cwe.mitre.org/data/definitions/328.html
+- https://en.wikipedia.org/wiki/Collision_attack
+- https://csrc.nist.gov/pubs/ir/8547/ipd
 draft:
   description: Utilizing weak hashing algorithms such as MD5 and SHA1 in a security
     sensitive context may compromise data integrity and authenticity.
   topics:
   - Weak hashing algorithms (e.g. MD5, SHA1, etc.)
 status: draft
-
 ---
 
+Choosing a weak hash algorithm, that is insufficiently collision resistant, may compromise the integrity and authenticity of data at rest and in transit by opening the application up for collision attacks.
+
+when performing key derivation together with predictable input or in password hashing, the digest (or hash) of an improper implemented- or used hash function may allow and adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack/collision attack), given the actor can arbitrarily choose the inputs to be hashed and can do so a reasonable amount of times
+
+What is regarded as "reasonable" varies by context and threat model, but in general, "reasonable" could cover any attack that is more efficient than brute force (i.e., on average, attempting half of all possible combinations). Note that some attacks might be more efficient than brute force but are still not regarded as achievable in the real world.
+
+Any algorithm that does not meet the above conditions will generally be considered weak for general use in hashing. When a collision attack is discovered and is found to be faster than a birthday attack, a hash function is often denounced as "broken". This is the case for MD5 and SHA-1.
+
+Another common issue is using HKDF for key derivation with any type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HKDF aren't design for low-entropy inputs. Doing so will result in producing "weak" hashes that easily can be broken.
+
+## Impact
+
+- **Loss of Integrity and authenticity**: A weak, risky or broken hashing algorithm, may allow an attacker to compromise the integrity and authenticity of data at rest and in transit.
+- **Loss of Confidentiality**: A  weak, risky or broken hashing algorithm may expose the preimage (input) and in so doing break the confidentiality.
+- **Risk of Brute-Force Attacks**: A  weak, risky or broken hashing is susceptible to brute-force attacks.
+
+## Modes of Introduction
+
+- **using a weak, risky or broken hashing algorithm**: E.g: MD5 and SHA-1 has been identified to be vulnerable for collision attacks that are faster than a birthday attack. Meaning that they are denounced as "broken".
+- **Using a insufficiently collision resistant hash**: Choosing a a hashing algorithm of insufficient length may result in loss of integrity or confidentiality.
+- **Using non-resource intensive algorithms on low-entropy input**: Using a integrity based hashing algorithm to hash low-entry input like pin numbers would make brute-force or dictionary attacks trivial.
+
+
+## Mitigations
+
+- **Choose collision resistant algorithm**: Choose an algorithm that is sufficiently collision resistant like the integrity algorithms SHA-256, SHA-384, SHA-512, BLAKE3 and the SHA-3 family
+- **Choose an algorithm with sufficient bit-lengths**: As our computers gets stronger, the hashes gets weaker, therefor, make sure that you can adjust the bit-length length of the algorithm of your choosing. When hashes are stored at rest, make sure to follow the software industry's long term recommendations (e.g: ["NIST: Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd)").
+- **Choose an algorithm fit for it's purpose**: When you want to ensure the data's integrity choose a integrity based algorithm. When you want to hash low-entropy input choose a password hash algorithm. Don't try to be clever. Follow recommendations and guidelines.
\ No newline at end of file
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0023.md b/weaknesses/MASVS-CRYPTO/MASWE-0023.md
index 3f8b4cc8d1a..8c156308c41 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0023.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0023.md
@@ -1,5 +1,5 @@
 ---
-title: Weak Padding
+title: Predictable Padding
 id: MASWE-0023
 alias: weak-padding
 platform: [android, ios]
@@ -24,14 +24,14 @@ status: new
 
 ## Overview
 
-**Outdated or weak padding schemes** can leave mobile apps susceptible to [padding oracle attacks](https://www.usenix.org/legacy/event/woot10/tech/full_papers/Rizzo.pdf), a type of side-channel exploit that lets attackers decrypt or manipulate data **without** knowing the key. These attacks arise when the app reveals whether a padding error occurred (through error messages or timing differences), creating an **oracle**. By submitting modified ciphertexts and observing the app's response, an attacker can gradually recover plaintext or forge ciphertext, compromising both confidentiality and integrity.
+**Outdated or predictable padding schemes** can leave mobile apps susceptible to [padding oracle attacks](https://www.usenix.org/legacy/event/woot10/tech/full_papers/Rizzo.pdf), a type of side-channel exploit that lets attackers decrypt or manipulate data **without** knowing the key. These attacks arise when the app reveals whether a padding error occurred (through error messages or timing differences), creating an **oracle**. By submitting modified ciphertexts and observing the app's response, an attacker can gradually recover plaintext or forge ciphertext, compromising both confidentiality and integrity.
 
-Below are two common examples of cryptographic contexts where weak padding can become a problem:
+Below are two common examples of cryptographic contexts where predictable padding can become a problem:
 
 - **Symmetric Cryptography**: In block cipher modes (e.g., AES-CBC), **PKCS#7 padding** is widely used. It becomes vulnerable to padding oracle attacks if the system leaks detailed error messages or timing differences. To mitigate this, cryptographers often use **authenticated encryption modes** like AES-GCM or pair AES-CBC with a separate integrity check (e.g., HMAC in an Encrypt-then-MAC scheme).
 - **Asymmetric Cryptography**: With RSA, **PKCS#1 v1.5** is known to be susceptible to attacks such as [Bleichenbacher](https://link.springer.com/content/pdf/10.1007/BFb0055716.pdf) (based on padding oracles). This older scheme is now discouraged or disallowed by various standards (for example, see [RFC 8017, Section 7.2](https://datatracker.ietf.org/doc/html/rfc8017#section-7.2) from November 2016 or [NIST SP 800-131A Rev.2, Section 6](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf) from March 2019).
 
-However, simply using a weak padding scheme does not guarantee a padding oracle vulnerability. As mentioned above, the app must **also** leak information (the "oracle") that indicates whether a padding error has occurred. If both conditions are met, attackers can use these signals to recover sensitive data or to craft malicious ciphertext.
+However, simply using a predictable padding scheme does not guarantee a padding oracle vulnerability. As mentioned above, the app must **also** leak information (the "oracle") that indicates whether a padding error has occurred. If both conditions are met, attackers can use these signals to recover sensitive data or to craft malicious ciphertext.
 
 ## Impact
 
@@ -41,7 +41,7 @@ However, simply using a weak padding scheme does not guarantee a padding oracle
 ## Modes of Introduction
 
 - **Insecure Padding for Symmetric Encryption**: Using padding schemes like PKCS#7 without additional message authentication (e.g., HMAC) for symmetric encryption algorithms like AES in block cipher modes (e.g., CBC).
-- **Insecure Padding for Asymmetric Encryption**: Using weak padding schemes like PKCS#1 v1.5 for RSA asymmetric encryption.
+- **Insecure Padding for Asymmetric Encryption**: Using predictable padding schemes like PKCS#1 v1.5 for RSA asymmetric encryption.
 
 ## Mitigations
 
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
index aa33a723587..92822466aba 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
@@ -1,5 +1,5 @@
 ---
-title: Weak Message Authentication Codes (MAC)
+title: Improper use of Message Authentication Code (MAC)
 id: MASWE-0024
 alias: weak-mac
 platform: [android, ios]
@@ -12,11 +12,34 @@ mappings:
 refs:
 - https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality
 - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf
+- https://csrc.nist.gov/pubs/sp/800/224/ipd
+- https://datatracker.ietf.org/doc/html/rfc6151
+- https://web.archive.org/web/20170810051504/http://www.tcs.hut.fi/old/papers/aura/aura-csfws97.pdf
+- https://en.wikipedia.org/wiki/Replay_attack
 draft:
-  description: The use of weak MAC such as HmacMD5, etc. in a security sensitive context
+  description: Improper use of MAC. E.g: allowing the user to control the input.
     may expose cryptographic vulnerabilities, affecting data integrity.
   topics: null
 status: draft
-
 ---
+Improper use of MAC by e.g by generating a MAC over a message without the timestamp can make the application susceptible for replay attacks.
+
+Another common issue is using HMAC with on low-entropy input with any type of general based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HMAC aren't designed for low-entropy inputs or low-entropy keys. Doing so will result in producing "weak" message digest that easily can be exploited.
+
+There could also be issues with a specific and deprecated HMAC implementation.
+
+## Impact
+
+- **Loss of Integrity and authenticity**: Improper use of MAC may result in replay attacks or, in worse case, broken authentication that could compromise the integrity of a system.
+- **Loss of Confidentiality**: Using MAC for other purposes than authentication may lead to a complete loss of confidentiality.
+
+## Modes of Introduction
+
+- **Not authenticating including a timestamp**: Creating a MAC without using and a proper timestamp that can be validated for the possibility of replay-attacks.
+- **Using a MAC for other purposes then message authentication**: Using low-entropy inputs or low-entropy keys as input to a HMAC.
+
+## Mitigations
 
+- **Use MAC with a timestamp**: Generate the MAC over a message with the timestamp included. This should protect the application against replay attacks within a reasonable amount of time. Reasonable, meaning a time frame that is short enough to prevent an attacker from sending an identical message and long enough to allow the message to be sent and digested.
+- **Do not use HMAC together with a low-entropy key**: Ensure the keys used are generated using Ccyptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks.
+- **Do not use deprecated HMCA implementations**: Deprecated HMCA implementation could contain errors that allow for collision attacks. Therefor, only use up to date libraries and functions.
\ No newline at end of file
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0025.md b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
index 454331e295d..fe3a0150aa6 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0025.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
@@ -1,5 +1,5 @@
 ---
-title: Weak Signature
+title: Signatures created by Deprecated, Risky or Broken algorithms.
 id: MASWE-0025
 alias: weak-signatures
 platform: [android, ios]
@@ -13,11 +13,26 @@ refs:
 - https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality
 - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf
 - https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf
+- https://csrc.nist.gov/pubs/ir/8547/ipd
 draft:
-  description: The use of weak signature such as SHA1withRSA, etc. in a security sensitive
-    context should be avoided to ensure the integrity and authenticity of the data.
+  description: The use of algorithms with insufficient strength for signatures such as SHA1withRSA, etc. in a security sensitive context should be avoided to ensure the integrity and authenticity of the data.
   topics: null
 status: draft
-
 ---
+Using deprecated, risky or broken algorithms for the purpose of ensuring accountability and non-reputation through the use of signatures could make it possible for an attacker to execute digital signature forgery and compromise the integrity and authenticity of the data at rest and in transit.
+
+## Impact
+
+- **Loss of Integrity and authenticity**: Signature forgery may allow the attacker to compromise the integrity and authenticity of the data by signing the data on behalf of another entity.
+- **Loss of accountability**: Signature forgery opens up for deniability and reduces accountability.
+
+## Modes of Introduction
+
+- **using a weak, risky or broken hashing algorithm**: E.g: MD5 and SHA-1 has been identified to be vulnerable for collision attacks that are faster than a birthday attack. Meaning that they are denounced as "broken".
+- **Using a insufficiently collision resistant hash**: Choosing a a hashing algorithm of insufficient length may result in loss of integrity or confidentiality.
+
+## Mitigations
+
+- **Choose collision resistant algorithm**: Choose a signature algorithm that is sufficiently collision resistant like RSA (3072 bits and higher), ECDSA with NIST P-384 or EdDSA with Edwards448.
 
+- **Choose an signing scheme that make use of algorithms with sufficient bit-lengths**: As our computers gets stronger, the hashes gets weaker, therefor, make sure that you can adjust the bit-length length (strength) of the algorithm of your choosing. When signatures are stored at rest, make sure to follow the software industry's long term recommendations (e.g: ["NIST: Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd)").
\ No newline at end of file
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0027.md b/weaknesses/MASVS-CRYPTO/MASWE-0027.md
index 62fb9d0e8a8..f7d0e77de4f 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0027.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0027.md
@@ -1,5 +1,5 @@
 ---
-title: Cryptographically Weak Pseudo-Random Number Generator (PRNG)
+title: Cryptographically Predictable Pseudo-Random Number Generator (PRNG)
 id: MASWE-0027
 alias: insecure-random
 platform: ["android", "ios"]

From e4c1996d0550fc4cb79066f1743058040b01076b Mon Sep 17 00:00:00 2001
From: Johan Sydseter <johan.sydseter@admincontrol.com>
Date: Tue, 11 Mar 2025 13:40:11 +0100
Subject: [PATCH 027/117] Correct spelling and formating

---
 Document/0x04g-Testing-Cryptography.md | 4 +---
 weaknesses/MASVS-CRYPTO/MASWE-0010.md  | 4 ++--
 weaknesses/MASVS-CRYPTO/MASWE-0021.md  | 5 ++---
 weaknesses/MASVS-CRYPTO/MASWE-0024.md  | 2 +-
 weaknesses/MASVS-CRYPTO/MASWE-0025.md  | 2 +-
 5 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 4dd1417bca6..cb87f25af7c 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -140,7 +140,7 @@ Some hash functions that have one or more of these desired properties include [s
 
 Note that using these functions can have an impact on performance, so they require special consideration to avoid denial-of-service attacks. However, their configurability provides finer control over how much CPU and memory is used, so it could be adjusted to suit the environment's needs. In the case where CPU and memory performance is a challenge try adjusting desired bit-length of the derived key instead of increasing the iteration account (e.g using HMAC-SHA512 instead of HMAC-SHA256). This might make the KDF more susceptible by brute-force attacks, but should be acceptable as long as you keep yourself within recommended guidelines.
 
-Unfortunately, "brute-force" attacks are quite liable to succeed where users selects passwords and pins with none or with too little entropy than what is required for cryptographic keys. Therefor, ensure that passwords and pins aren't directly passed into a HKDF. The key that is input to a key-derivation function is called a key-derivation key (KDK). A KDK **shall** be a cryptographic key, but the KDK used as an input to a recommended key-derivation functions can, for example, be generated by an approved cryptographic random bit generator, e.g. by a deterministic random bit generator (see: [NIST 800-108, rev 1](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")) ([NIST, 2022](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")).
+Unfortunately, "brute-force" attacks are quite liable to succeed where users selects passwords and pins with none or with too little entropy than what is required for cryptographic keys. Therefore, ensure that passwords and pins aren't directly passed into a HKDF. The key that is input to a key-derivation function is called a key-derivation key (KDK). A KDK **shall** be a cryptographic key, but the KDK used as an input to a recommended key-derivation functions can, for example, be generated by an approved cryptographic random bit generator, e.g. by a deterministic random bit generator (see: [NIST 800-108, rev 1](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")) ([NIST, 2022](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")).
 In cases where the input is user-controlled, use password hashing algorithm like Argon2, scrypt, bcrypt or PBKDF2 as a key derivation function to provide a sufficient level of computational effort.
 When using a password hashing algorithm as a KDF, also ensure to choose an appropriate iteration count that can provide sufficient computational efforts. Meaning that they make password or secret cracking attacks infeasible or expensive. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to implementation algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2"). Also see ["OWASP Password Storage Cheat Sheet"](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction "OWASP Cheat Sheet Series: Password Storage Cheat Sheet") for recommendation on iteration count when using key derivation functions using Argon2, scrypt, bcrypt or PBKDF2.
 
@@ -157,8 +157,6 @@ Mobile SDKs offer standard implementations of PRNG algorithms that produce numbe
 Make sure to choose a hash function that is built for the purpose you intend it for.
 When hashes are needed for integrity checks, choose an algorithm that is sufficiently collision resistant like the integrity algorithms SHA-256, SHA-384, SHA-512, BLAKE3 and the SHA-3 family. Choosing a weak algorithm may compromise the integrity and authenticity of data at rest and in transit. Also keep in mind that hash functions used for integrity checks, like the SHA series, should not be used for key derivation together with predictable input or in password hashing.
 
-
-
 ### Custom Implementations of Cryptography
 
 Inventing proprietary cryptographic functions is time consuming, difficult, and likely to fail. Instead, we can use well-known algorithms that are widely regarded as secure. Mobile operating systems offer standard cryptographic APIs that implement those algorithms.
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
index 4047e584183..84af37c42ac 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
@@ -25,7 +25,7 @@ status: draft
 Improper Key derivation functions will generate a key using a scheme or iteration count that does not provide a sufficient level of computational effort. This can open up the possibility for brute force password/secret cracking or dictionary attacks.
 In cases where a user-supplied password or pin is used without a sufficiently random salt the resulting output will be identical or similar enough to allow an attacker to execute a brute force attack to find the original password/pin using the KDF as an "oracle".
 A similar issue happens when the salt is user-supplied. Consider a mobile app that generates user keys from a master key on demand during installation. Let's say that a key used in the mobile app is derived from this master key using the username or other user supplied value as salt. Such an implementation can make it possible for an attacker to retrieve the derived key by using the username or supplied user value as input.
-Another common issue is using HKDF or any other type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HKDF aren't design for low-entropy inputs. Therefor password crackers can fairly efficiently crack massive amounts of passwords for KDFs that aren’t purposefully designed to be slow and memory-intensive. A similar issue happens when using deprecated, risky or broken KDF- or password hashing algorithms known to the vulnerable for various types of attacks.
+Another common issue is using HKDF or any other type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HKDF aren't design for low-entropy inputs. Therefore password crackers can fairly efficiently crack massive amounts of passwords for KDFs that aren’t purposefully designed to be slow and memory-intensive. A similar issue happens when using deprecated, risky or broken KDF- or password hashing algorithms known to the vulnerable for various types of attacks.
 Also, cryptographic algorithms (such as symmetric encryption or some MACs) expect a secret input of a given size. For example, AES uses a key of exactly 16 bytes. A native implementation might use the user-supplied password directly as an input key. Using a user-supplied password or pin as an input key has the following problems:
 
 - If the password is smaller than the key, the full key space isn't used. The remaining space is padded (spaces are sometimes used for padding).
@@ -34,7 +34,7 @@ Also, cryptographic algorithms (such as symmetric encryption or some MACs) expec
 ## Impact
 
 - **Risk of Brute-Force Attacks**: Improper Key derivation functions open up for brute force password- and secret cracking, key or dictionary attacks such as rainbow tables.
-- **Loss of  Confidentiality**: Improper Key derivation may allow an attacker to guess or find the input and therefor steal the user's password or cryptographic key.
+- **Loss of  Confidentiality**: Improper Key derivation may allow an attacker to guess or find the input and therefore steal the user's password or cryptographic key.
 - **Loss of Integrity**: Given that the attacker has access to the user's password or cryptographic key, the overall security of the app and mobile phone may be compromised.
 
 ## Modes of Introduction
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0021.md b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
index edbe14b80b4..b9a69587d1e 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0021.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
@@ -45,9 +45,8 @@ Another common issue is using HKDF for key derivation with any type of integrity
 - **Using a insufficiently collision resistant hash**: Choosing a a hashing algorithm of insufficient length may result in loss of integrity or confidentiality.
 - **Using non-resource intensive algorithms on low-entropy input**: Using a integrity based hashing algorithm to hash low-entry input like pin numbers would make brute-force or dictionary attacks trivial.
 
-
 ## Mitigations
 
 - **Choose collision resistant algorithm**: Choose an algorithm that is sufficiently collision resistant like the integrity algorithms SHA-256, SHA-384, SHA-512, BLAKE3 and the SHA-3 family
-- **Choose an algorithm with sufficient bit-lengths**: As our computers gets stronger, the hashes gets weaker, therefor, make sure that you can adjust the bit-length length of the algorithm of your choosing. When hashes are stored at rest, make sure to follow the software industry's long term recommendations (e.g: ["NIST: Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd)").
-- **Choose an algorithm fit for it's purpose**: When you want to ensure the data's integrity choose a integrity based algorithm. When you want to hash low-entropy input choose a password hash algorithm. Don't try to be clever. Follow recommendations and guidelines.
\ No newline at end of file
+- **Choose an algorithm with sufficient bit-lengths**: As our computers gets stronger, the hashes gets weaker, therefore, make sure that you can adjust the bit-length length of the algorithm of your choosing. When hashes are stored at rest, make sure to follow the software industry's long term recommendations (e.g: ["NIST: Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd)").
+- **Choose an algorithm fit for it's purpose**: When you want to ensure the data's integrity choose a integrity based algorithm. When you want to hash low-entropy input choose a password hash algorithm. Don't try to be clever. Follow recommendations and guidelines.
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
index 92822466aba..dc4f740d6c4 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
@@ -42,4 +42,4 @@ There could also be issues with a specific and deprecated HMAC implementation.
 
 - **Use MAC with a timestamp**: Generate the MAC over a message with the timestamp included. This should protect the application against replay attacks within a reasonable amount of time. Reasonable, meaning a time frame that is short enough to prevent an attacker from sending an identical message and long enough to allow the message to be sent and digested.
 - **Do not use HMAC together with a low-entropy key**: Ensure the keys used are generated using Ccyptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks.
-- **Do not use deprecated HMCA implementations**: Deprecated HMCA implementation could contain errors that allow for collision attacks. Therefor, only use up to date libraries and functions.
\ No newline at end of file
+- **Do not use deprecated HMCA implementations**: Deprecated HMCA implementation could contain errors that allow for collision attacks. Therefore, only use up to date libraries and functions.
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0025.md b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
index fe3a0150aa6..73497c96eb1 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0025.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
@@ -35,4 +35,4 @@ Using deprecated, risky or broken algorithms for the purpose of ensuring account
 
 - **Choose collision resistant algorithm**: Choose a signature algorithm that is sufficiently collision resistant like RSA (3072 bits and higher), ECDSA with NIST P-384 or EdDSA with Edwards448.
 
-- **Choose an signing scheme that make use of algorithms with sufficient bit-lengths**: As our computers gets stronger, the hashes gets weaker, therefor, make sure that you can adjust the bit-length length (strength) of the algorithm of your choosing. When signatures are stored at rest, make sure to follow the software industry's long term recommendations (e.g: ["NIST: Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd)").
\ No newline at end of file
+- **Choose an signing scheme that make use of algorithms with sufficient bit-lengths**: As our computers gets stronger, the hashes gets weaker, therefore, make sure that you can adjust the bit-length length (strength) of the algorithm of your choosing. When signatures are stored at rest, make sure to follow the software industry's long term recommendations (e.g: ["NIST: Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd)").

From 740c1c108866f5e6ddc7caf69e70471a8ee1b2a3 Mon Sep 17 00:00:00 2001
From: Johan Sydseter <johan.sydseter@admincontrol.com>
Date: Tue, 11 Mar 2025 13:46:59 +0100
Subject: [PATCH 028/117] grammer correction

---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index cb87f25af7c..a0dd1606706 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -51,7 +51,7 @@ Please make sure that:
 - Cryptographic means are not mixed with each other: e.g. you do not sign with a public key, or try to reuse a key pair used for a signature to do encryption.
 - Cryptographic parameters are well defined within reasonable range. This includes, but is not limited to: cryptographic salt, which should be at least the same length as hash function output, reasonable choice of password derivation function and iteration count (e.g. PBKDF2, scrypt or bcrypt), IVs being random and unique, fit-for-purpose block encryption modes (e.g. ECB should not be used, except specific cases), key management being done properly (e.g. 3DES should have three independent keys) and so on.
 
-Recommend algorithms:
+Recommended algorithms:
 
 - Confidentiality algorithms: AES-GCM-256 or ChaCha20-Poly1305
 - Integrity algorithms: SHA-256, SHA-384, SHA-512, BLAKE3, the SHA-3 family

From f2f5aef190cf78f9a65c8a0af94ba7994eb6c437 Mon Sep 17 00:00:00 2001
From: Johan Sydseter <johan.sydseter@admincontrol.com>
Date: Tue, 11 Mar 2025 13:52:54 +0100
Subject: [PATCH 029/117] Correct link

---
 weaknesses/MASVS-CRYPTO/MASWE-0019.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0019.md b/weaknesses/MASVS-CRYPTO/MASWE-0019.md
index 94db683199b..98e79d4bf35 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0019.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0019.md
@@ -14,7 +14,7 @@ refs:
  - https://book.hacktricks.xyz/crypto-and-stego/cryptographic-algorithms
  - https://www.researchgate.net/publication/290181523_Evaluation_of_Cryptography_Usage_in_Android_Applications
  - https://www.scitepress.org/papers/2014/50563/50563.pdf
- - https://pure.tugraz.at/ws/portalfiles/portal/23858147
+ - https://pure.tugraz.at/ws/portalfiles/portal/23858147/main.pdf
  - https://github.com/Wind-River/crypto-detector
  - https://github.com/Rami114/cryptoscan/
  - https://github.com/IAIK/CryptoSlice

From b49b30d20d4622804d13842b8b43ff7326ecf66c Mon Sep 17 00:00:00 2001
From: Johan Sydseter <johan.sydseter@admincontrol.com>
Date: Tue, 11 Mar 2025 14:02:32 +0100
Subject: [PATCH 030/117] Replace links with identical sources hosted from
 other locations

---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 weaknesses/MASVS-CRYPTO/MASWE-0019.md  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index a0dd1606706..971f95d7a97 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -64,7 +64,7 @@ Additionally, you should always rely on secure hardware (if available) for stori
 
 For more information on algorithm choice and best practices, see the following resources:
 
-- ["Commercial National Security Algorithm Suite and Quantum Computing FAQ"](https://cryptome.org/2016/01/CNSA-Suite-and-Quantum-Computing-FAQ.pdf "Commercial National Security Algorithm Suite and Quantum Computing FAQ")
+- ["Commercial National Security Algorithm Suite and Quantum Computing FAQ"](https://web.archive.org/web/20250305234320/https://cryptome.org/2016/01/CNSA-Suite-and-Quantum-Computing-FAQ.pdf "Commercial National Security Algorithm Suite and Quantum Computing FAQ")
 - [NIST recommendations (2019)](https://www.keylength.com/en/4/ "NIST recommendations")
 - [BSI recommendations (2019)](https://www.keylength.com/en/8/ "BSI recommendations")
 - NIST advises using RSA-based key-transport schemes with a minimum modulus length of at least 2048 bits according to 800-56B Rev. 2 ([NIST, 2019](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final "NIST: Recommendation for Pair-Wise Key-Establishment Using Integer Factorization Cryptography"))
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0019.md b/weaknesses/MASVS-CRYPTO/MASWE-0019.md
index 98e79d4bf35..970982d36e8 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0019.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0019.md
@@ -12,7 +12,7 @@ mappings:
 
 refs: 
  - https://book.hacktricks.xyz/crypto-and-stego/cryptographic-algorithms
- - https://www.researchgate.net/publication/290181523_Evaluation_of_Cryptography_Usage_in_Android_Applications
+ - https://dl.acm.org/doi/10.4108/eai.3-12-2015.2262471
  - https://www.scitepress.org/papers/2014/50563/50563.pdf
  - https://pure.tugraz.at/ws/portalfiles/portal/23858147/main.pdf
  - https://github.com/Wind-River/crypto-detector

From fa059a30934982041867f5b1cdf7f38119a4606d Mon Sep 17 00:00:00 2001
From: Johan Sydseter <johan.sydseter@admincontrol.com>
Date: Tue, 11 Mar 2025 15:48:18 +0100
Subject: [PATCH 031/117] Use improper, short, insufficient and predictable
 instead of weak

---
 Document/0x04b-Mobile-App-Security-Testing.md        |  2 +-
 Document/0x04g-Testing-Cryptography.md               |  4 ++--
 Document/0x05d-Testing-Data-Storage.md               |  2 +-
 Document/0x05e-Testing-Cryptography.md               |  2 +-
 docs/news/posts/2024-07-30-new-maswe.md              |  2 +-
 prerequisites/identify-security-relevant-contexts.md |  2 +-
 rules/mastg-android-weak-encryption-algorithms.yaml  |  4 ++--
 rules/mastg-android-weak-encryption-modes.yaml       |  4 ++--
 rules/mastg-android-weak-key-generation.yml          |  2 +-
 techniques/android/MASTG-TECH-0014.md                |  2 +-
 techniques/generic/MASTG-TECH-0049.md                |  2 +-
 tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0208.md   |  6 +++---
 tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0221.md   |  8 ++++----
 tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md   |  4 ++--
 tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0209.md       |  6 +++---
 tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0210.md       | 12 ++++++------
 tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md       | 12 ++++++------
 weaknesses/MASVS-CRYPTO/MASWE-0009.md                |  2 +-
 weaknesses/MASVS-CRYPTO/MASWE-0010.md                |  2 +-
 weaknesses/MASVS-CRYPTO/MASWE-0019.md                |  6 +++---
 weaknesses/MASVS-CRYPTO/MASWE-0020.md                |  4 ++--
 weaknesses/MASVS-CRYPTO/MASWE-0021.md                |  6 +++---
 weaknesses/MASVS-CRYPTO/MASWE-0023.md                |  2 +-
 weaknesses/MASVS-NETWORK/MASWE-0047.md               |  4 ++--
 24 files changed, 51 insertions(+), 51 deletions(-)

diff --git a/Document/0x04b-Mobile-App-Security-Testing.md b/Document/0x04b-Mobile-App-Security-Testing.md
index a52455620b3..f0ea760d2c8 100644
--- a/Document/0x04b-Mobile-App-Security-Testing.md
+++ b/Document/0x04b-Mobile-App-Security-Testing.md
@@ -139,7 +139,7 @@ When developing a mobile application, it's crucial to accurately identify and ha
 
 Properly distinguishing security-relevant contexts helps in minimizing false positives during security testing. False positives can divert attention from real issues and waste valuable resources. Here are some common scenarios:
 
-- **Random Number Generation**: Using weak random number generators can be a serious security flaw in contexts like authentication or encryption key generation. However, not all uses of random numbers are security-sensitive. For instance, using a less robust random number generator for non-security purposes like shuffling a list of items in a game is generally acceptable.
+- **Random Number Generation**: Using predictable random number generators can be a serious security flaw in contexts like authentication or encryption key generation. However, not all uses of random numbers are security-sensitive. For instance, using a less robust random number generator for non-security purposes like shuffling a list of items in a game is generally acceptable.
 
 - **Hashing**: Hashing is often used in security for storing passwords or ensuring data integrity. However, hashing a non-sensitive value, like a device's screen resolution for analytics, isn't a security concern.
 
diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 971f95d7a97..e678177bb5b 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -152,10 +152,10 @@ PRNG can be vulnerable when developers use a regular PRNG for cryptographic purp
 
 Mobile SDKs offer standard implementations of PRNG algorithms that produce numbers with sufficient artificial randomness. We'll introduce the available APIs in the Android and iOS specific sections.
 
-### Weak hashing
+### Weak, Risky or Broken Hashing
 
 Make sure to choose a hash function that is built for the purpose you intend it for.
-When hashes are needed for integrity checks, choose an algorithm that is sufficiently collision resistant like the integrity algorithms SHA-256, SHA-384, SHA-512, BLAKE3 and the SHA-3 family. Choosing a weak algorithm may compromise the integrity and authenticity of data at rest and in transit. Also keep in mind that hash functions used for integrity checks, like the SHA series, should not be used for key derivation together with predictable input or in password hashing.
+When hashes are needed for integrity checks, choose an algorithm that is sufficiently collision resistant like the integrity algorithms SHA-256, SHA-384, SHA-512, BLAKE3 and the SHA-3 family. Choosing a risky or broken algorithm may compromise the integrity and authenticity of data at rest and in transit. Also keep in mind that hash functions used for integrity checks, like the SHA series, should not be used for key derivation together with predictable input or in password hashing.
 
 ### Custom Implementations of Cryptography
 
diff --git a/Document/0x05d-Testing-Data-Storage.md b/Document/0x05d-Testing-Data-Storage.md
index 308469e84ee..0aade12836c 100644
--- a/Document/0x05d-Testing-Data-Storage.md
+++ b/Document/0x05d-Testing-Data-Storage.md
@@ -542,7 +542,7 @@ Deriving a key from a user provided passphrase is a common solution (depending o
 
 Each time the application needs to perform a cryptographic operation, the user's passphrase is needed. Either the user is prompted for it every time, which isn't an ideal user experience, or the passphrase is kept in memory as long as the user is authenticated. Keeping the passphrase in memory is not a best-practice, as any cryptographic material must only be kept in memory while it is being used. Zeroing out a key is often a very challenging task as explained in ["Cleaning out Key Material"](#cleaning-out-key-material).
 
-Additionally, consider that keys derived from a passphrase have their own weaknesses. For instance, the passwords or passphrases might be reused by the user or easy to guess. Please refer to the [Testing Cryptography chapter](0x04g-Testing-Cryptography.md#weak-key-generation-functions) for more information.
+Additionally, consider that keys derived from a passphrase have their own weaknesses. For instance, the passwords or passphrases might be reused by the user or easy to guess. Please refer to the [Testing Cryptography chapter](0x04g-Testing-Cryptography.md#improper-key-derivation-functions) for more information.
 
 #### Cleaning out Key Material
 
diff --git a/Document/0x05e-Testing-Cryptography.md b/Document/0x05e-Testing-Cryptography.md
index 11561c7c5bb..361f0668be9 100644
--- a/Document/0x05e-Testing-Cryptography.md
+++ b/Document/0x05e-Testing-Cryptography.md
@@ -210,7 +210,7 @@ KeyPair keyPair = keyPairGenerator.generateKeyPair();
 
 This sample creates the RSA key pair with a key size of 4096-bit (i.e. modulus size). Elliptic Curve (EC) keys can also be generated in a similar way. However as of Android 11 (API level 30), [AndroidKeyStore does not support encryption or decryption with EC keys](https://developer.android.com/guide/topics/security/cryptography#SupportedCipher). They can only be used for signatures.
 
-A symmetric encryption key can be generated from the passphrase by using the Password Based Key Derivation Function version 2 (PBKDF2). This cryptographic protocol is designed to generate cryptographic keys, which can be used for cryptography purpose. Input parameters for the algorithm are adjusted according to [weak key generation function](0x04g-Testing-Cryptography.md#weak-key-generation-functions) section. The code listing below illustrates how to generate a strong encryption key based on a password.
+A symmetric encryption key can be generated from the passphrase by using the Password Based Key Derivation Function version 2 (PBKDF2). This cryptographic protocol is designed to generate cryptographic keys, which can be used for cryptography purpose. Input parameters for the algorithm are adjusted according to [improper key generation function](0x04g-Testing-Cryptography.md#improper-key-derivation-functions) section. The code listing below illustrates how to generate a strong encryption key based on a password.
 
 ```java
 public static SecretKey generateStrongAESKey(char[] password, int keyLength)
diff --git a/docs/news/posts/2024-07-30-new-maswe.md b/docs/news/posts/2024-07-30-new-maswe.md
index 7f7f9fdd61d..9e773f2a422 100644
--- a/docs/news/posts/2024-07-30-new-maswe.md
+++ b/docs/news/posts/2024-07-30-new-maswe.md
@@ -41,7 +41,7 @@ Now MASVS, MASWE and MASTG are all seamlessly connected. We start with the high-
 1. **MASVS Controls**: High-level platform-agnostic requirements.
    > For example, "The app employs current cryptography and uses it according to best practices." ([MASVS-CRYPTO-1](https://mas.owasp.org/MASVS/controls/MASVS-CRYPTO-1/)).
 2. **MASWE Weaknesses**: Specific weaknesses, typically also platform-agnostic, related to the controls.
-   > For example, "use of weak pseudo-random number generation" ([MASWE-0027](https://mas.owasp.org/MASWE/MASVS-CRYPTO/MASWE-0027/)).
+   > For example, "use of predictable pseudo-random number generation" ([MASWE-0027](https://mas.owasp.org/MASWE/MASVS-CRYPTO/MASWE-0027/)).
 3. **MASTG Tests**: Each weakness is evaluated by executing tests that guide the tester in identifying and mitigating the issues using various tools and techniques on each mobile platform.
    > For example, testing for "insecure random API usage on Android" ([MASTG-TEST-0204](https://mas.owasp.org/MASTG/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0204/)).
 4. **MASTG Demos**: Practical demonstrations that include working code samples and test scripts to ensure reproducibility and reliability.
diff --git a/prerequisites/identify-security-relevant-contexts.md b/prerequisites/identify-security-relevant-contexts.md
index 703bcc63d24..bf44a21ecba 100644
--- a/prerequisites/identify-security-relevant-contexts.md
+++ b/prerequisites/identify-security-relevant-contexts.md
@@ -4,7 +4,7 @@ When developing a mobile application, it's crucial to accurately identify and ha
 
 Properly distinguishing security-relevant contexts helps in minimizing false positives during security testing. False positives can divert attention from real issues and waste valuable resources. Here are some common scenarios:
 
-- **Random Number Generation**: Using weak random number generators can be a serious security flaw in contexts like authentication or encryption key generation. However, not all uses of random numbers are security-sensitive. For instance, using a less robust random number generator for non-security purposes like shuffling a list of items in a game is generally acceptable.
+- **Random Number Generation**: Using predictable random number generators can be a serious security flaw in contexts like authentication or encryption key generation. However, not all uses of random numbers are security-sensitive. For instance, using a less robust random number generator for non-security purposes like shuffling a list of items in a game is generally acceptable.
 
 - **Hashing**: Hashing is often used in security for storing passwords or ensuring data integrity. However, hashing a non-sensitive value, like a device's screen resolution for analytics, isn't a security concern.
 
diff --git a/rules/mastg-android-weak-encryption-algorithms.yaml b/rules/mastg-android-weak-encryption-algorithms.yaml
index f7928a07511..1cfa98e6862 100644
--- a/rules/mastg-android-weak-encryption-algorithms.yaml
+++ b/rules/mastg-android-weak-encryption-algorithms.yaml
@@ -4,6 +4,6 @@ rules:
       - java
     severity: WARNING
     metadata:
-      summary: This rule looks for weak encryption algorithms.
-    message: "[MASVS-CRYPTO-1] Weak encryption algorithms found in use."
+      summary: This rule looks for risky or broken encryption algorithms.
+    message: "[MASVS-CRYPTO-1] Risky or broken encryption algorithms found in use."
     pattern-regex: Cipher\.getInstance\("?(DES|DESede|RC4|Blowfish)(/[A-Za-z0-9]+(/[A-Za-z0-9]+)?)?"?\)
diff --git a/rules/mastg-android-weak-encryption-modes.yaml b/rules/mastg-android-weak-encryption-modes.yaml
index 4debe1ace91..d7c913c38f6 100644
--- a/rules/mastg-android-weak-encryption-modes.yaml
+++ b/rules/mastg-android-weak-encryption-modes.yaml
@@ -4,8 +4,8 @@ rules:
       - java
     severity: WARNING
     metadata:
-      summary: This rule looks for weak encryption modes.
-    message: "[MASVS-CRYPTO-1] Weak encryption modes found in use."
+      summary: This rule looks for predictable encryption modes.
+    message: "[MASVS-CRYPTO-1] Predictable encryption modes found in use."
     pattern-either:
       - pattern: Cipher.getInstance("AES")
       - pattern-regex: Cipher\.getInstance\("?[A-Za-z0-9]+/ECB(/[A-Za-z0-9]+)?"?\)
diff --git a/rules/mastg-android-weak-key-generation.yml b/rules/mastg-android-weak-key-generation.yml
index 3de9540d62d..4b2e42c7bd6 100644
--- a/rules/mastg-android-weak-key-generation.yml
+++ b/rules/mastg-android-weak-key-generation.yml
@@ -4,7 +4,7 @@ rules:
     languages:
       - java
     metadata:
-      summary: This rule looks for methods that create a weak key size in encryption algorithms.
+      summary: This rule looks for methods that create a short key size in encryption algorithms.
     message: "[MASVS-CRYPTO] Make sure that the key size is according to security best practices"
     pattern-either:
       - pattern: |
diff --git a/techniques/android/MASTG-TECH-0014.md b/techniques/android/MASTG-TECH-0014.md
index 676185d4840..e3d7e7798a9 100644
--- a/techniques/android/MASTG-TECH-0014.md
+++ b/techniques/android/MASTG-TECH-0014.md
@@ -17,7 +17,7 @@ grep 'android:minSdkVersion' AndroidManifest.xml
 
 This command searches for the `android:minSdkVersion` attribute within the manifest file. Ensuring a higher `minSdkVersion` can reduce security risks, as older versions of Android may not include the latest security features and fixes.
 
-## Example: Using semgrep for Identifying Weak Cryptography
+## Example: Using semgrep for Identifying Predictable Seed
 
 semgrep is a more advanced tool that can be used for pattern matching in code. It's particularly useful for identifying complex coding patterns that might lead to security vulnerabilities. For example, to find instances where a deterministic seed is used with the `SecureRandom` class (which can compromise the randomness and thus the security), you can use a semgrep rule like:
 
diff --git a/techniques/generic/MASTG-TECH-0049.md b/techniques/generic/MASTG-TECH-0049.md
index c22a0ccd080..ed1cefbb218 100644
--- a/techniques/generic/MASTG-TECH-0049.md
+++ b/techniques/generic/MASTG-TECH-0049.md
@@ -7,7 +7,7 @@ Dynamic Analysis tests the mobile app by executing and running the app binary an
 
 - Business logic flaws
 - Vulnerabilities in the tested environments
-- Weak input validation and bad input/output encoding as they are processed through one or multiple services
+- Improper input validation and bad input/output encoding as they are processed through one or multiple services
 
 Analysis can be assisted by automated tools, such as @MASTG-TOOL-0035, while assessing an application. An application can be assessed by side-loading it, re-packaging it, or by simply attacking the installed version.
 
diff --git a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0208.md b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0208.md
index 3bfb20a7b5f..8a3937f2db7 100644
--- a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0208.md
+++ b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0208.md
@@ -1,6 +1,6 @@
 ---
 platform: android
-title: Inappropriate Key Sizes 
+title: Insufficient Key Sizes 
 id: MASTG-TEST-0208
 type: [static]
 weakness: MASWE-0009
@@ -8,7 +8,7 @@ weakness: MASWE-0009
 
 ## Overview
 
-In this test case, we will look for the use inappropriate key sizes in Android apps. To do this, we need to focus on the cryptographic frameworks and libraries that are available in Android and the methods that are used to generate, inspect and manage cryptographic keys.
+In this test case, we will look for the use Insufficient key sizes in Android apps. To do this, we need to focus on the cryptographic frameworks and libraries that are available in Android and the methods that are used to generate, inspect and manage cryptographic keys.
 
 The Java Cryptography Architecture (JCA) provides foundational classes for key generation which are often used directly when portability or compatibility with older systems is a concern.
 
@@ -27,4 +27,4 @@ The output should contain a list of locations where insufficient key lengths are
 
 ## Evaluation
 
-The test case fails if you can find the use of inappropriate key sizes within the source code. For example, a 1024-bit key size is considered weak for RSA encryption and a 128-bit key size is considered weak for AES encryption considering quantum computing attacks.
+The test case fails if you can find the use of insufficient key sizes within the source code. For example, a 1024-bit key size is considered insufficient for RSA encryption and a 128-bit key size is considered insufficient for AES encryption considering quantum computing attacks.
diff --git a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0221.md b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0221.md
index 01b0cc9a9d2..2cb7b5b5aff 100644
--- a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0221.md
+++ b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0221.md
@@ -1,5 +1,5 @@
 ---
-title: Weak Symmetric Encryption Algorithms
+title: Symmetric Encryption Algorithms with insufficient strength
 platform: android
 id: MASTG-TEST-0221
 type: [static, dynamic]
@@ -9,16 +9,16 @@ best-practices: [MASTG-BEST-0009]
 
 ## Overview
 
-To test for the [use of weak encryption algorithms](../../../Document/0x04g-Testing-Cryptography.md#identifying-insecure-andor-deprecated-cryptographic-algorithms) in Android apps, we need to focus on methods from cryptographic frameworks and libraries that are used to perform encryption and decryption operations.
+To test for the [use of encryption algorithms with insufficient strength](../../../Document/0x04g-Testing-Cryptography.md#identifying-insecure-andor-deprecated-cryptographic-algorithms) in Android apps, we need to focus on methods from cryptographic frameworks and libraries that are used to perform encryption and decryption operations.
 
 - [`Cipher.getInstance`](https://developer.android.com/reference/javax/crypto/Cipher#getInstance(java.lang.String)): Initializes a Cipher object for encryption or decryption. The `algorithm` parameter can be one of the [supported algorithms](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#Cipher).
 - [`SecretKeyFactory.getInstance`](https://developer.android.com/reference/javax/crypto/SecretKeyFactory#getInstance(java.lang.String)): Returns a SecretKeyFactory object that converts keys into key specifications and vice versa. The `algorithm` parameter can be one of the [supported algorithms](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#SecretKeyFactory).
 - [`KeyGenerator.getInstance`](https://developer.android.com/reference/javax/crypto/KeyGenerator#getInstance(java.lang.String)): Returns a `KeyGenerator` object that generates secret keys for symmetric algorithms. The `algorithm` parameter can be one of the [supported algorithms](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#KeyGenerator).
 
-Some weak symmetric encryption algorithms include:
+Some deprecated, risky or broken symmetric encryption algorithms include:
 
 - **DES (Data Encryption Standard)**: 56-bit key, breakable, [withdrawn by NIST in 2005](https://csrc.nist.gov/pubs/fips/46-3/final).
-- **3DES (Triple DES, officially the Triple Data Encryption Algorithm (TDEA or Triple DEA))**: Weak 64-bit blocks, [vulnerable to Sweet32 birthday attacks](https://sweet32.info/), [withdrawn by NIST on January 1, 2024](https://csrc.nist.gov/pubs/sp/800/67/r2/final).
+- **3DES (Triple DES, officially the Triple Data Encryption Algorithm (TDEA or Triple DEA))**: 64-bit with insufficient block size, [vulnerable to Sweet32 birthday attacks](https://sweet32.info/), [withdrawn by NIST on January 1, 2024](https://csrc.nist.gov/pubs/sp/800/67/r2/final).
 - **RC4**: Predictable key stream, allows plaintext recovery [RC4 Weakness](https://www.rc4nomore.com/), disapproved by [NIST](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-52r1.pdf) in 2014 and prohibited by [IETF](https://datatracker.ietf.org/doc/html/rfc7465) in 2015.
 - **Blowfish**: 64-bit block size, [vulnerable to Sweet32 attacks](https://en.wikipedia.org/wiki/Birthday_attack), never FIPS-approved, and listed under ["Non-Approved algorithms" in FIPS](https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp2092.pdf).
 
diff --git a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md
index 5f0b3b8249a..609b892eff6 100644
--- a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md
+++ b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md
@@ -1,5 +1,5 @@
 ---
-title: Weak Symmetric Encryption Modes
+title: Predictable Symmetric Encryption Modes
 platform: android
 id: MASTG-TEST-0232
 type: [static, dynamic]
@@ -9,7 +9,7 @@ best-practices: [MASTG-BEST-0005]
 
 ## Overview
 
-To test for the [use of weak encryption modes](../../../Document/0x04g-Testing-Cryptography.md#weak-block-cipher-mode) in Android apps, we need to focus on methods from cryptographic frameworks and libraries that are used to configure and apply encryption modes.
+To test for the [use of predictable encryption modes](../../../Document/0x04g-Testing-Cryptography.md#weak-block-cipher-mode) in Android apps, we need to focus on methods from cryptographic frameworks and libraries that are used to configure and apply encryption modes.
 
 In Android development, the `Cipher` class from the Java Cryptography Architecture (JCA) is the primary API that allows you to specify the encryption mode for cryptographic operations. [`Cipher.getInstance`](https://developer.android.com/reference/javax/crypto/Cipher#getInstance(java.lang.String)) defines the transformation string, which includes the encryption algorithm, mode of operation, and padding scheme. The general format is `"Algorithm/Mode/Padding"`. For example:
 
diff --git a/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0209.md b/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0209.md
index c42347731fa..543d67b5518 100644
--- a/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0209.md
+++ b/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0209.md
@@ -1,6 +1,6 @@
 ---
 platform: ios
-title: Inappropriate Key Sizes
+title: Insufficient Key Sizes
 id: MASTG-TEST-0209
 type: [static, dynamic]
 weakness: MASWE-0009
@@ -8,7 +8,7 @@ weakness: MASWE-0009
 
 ## Overview
 
-In this test case, we will look for the use inappropriate key sizes in iOS apps. To do this, we need to focus on the cryptographic frameworks and libraries that are available in iOS and the methods that are used to generate cryptographic keys.
+In this test case, we will look for the use insufficient key sizes in iOS apps. To do this, we need to focus on the cryptographic frameworks and libraries that are available in iOS and the methods that are used to generate cryptographic keys.
 
 - **CommonCrypto**: The [`CCCrypt`](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/CCCrypt.3cc.html) function is used for symmetric encryption and decryption and specifies the key size or key length in its fifth parameter `keyLength`.
 - **Security**: The [`SecKeyCreateRandomKey`](https://developer.apple.com/documentation/security/1823694-seckeycreaterandomkey) function is used to generate a random key using certain attributes including [`kSecAttrKeyType`](https://developer.apple.com/documentation/security/ksecattrkeytype) and [`kSecAttrKeySizeInBits`](https://developer.apple.com/documentation/security/ksecattrkeysizeinbits). The [`SecKeyGeneratePair`](https://developer.apple.com/documentation/security/1395339-seckeygeneratepair) function is deprecated in iOS 16.
@@ -26,4 +26,4 @@ The output should contain the disassembled code of the functions using `CCCrypt`
 
 ## Evaluation
 
-The test case fails if you can find the use of inappropriate key sizes within the source code. For example, a 1024-bit key size is considered weak for RSA encryption and a 128-bit key size is considered weak for AES encryption considering quantum computing attacks.
+The test case fails if you can find the use of insufficient key sizes within the source code. For example, a 1024-bit key size is considered insufficient for RSA encryption and a 128-bit key size is considered insufficient for AES encryption considering quantum computing attacks.
diff --git a/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0210.md b/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0210.md
index ed42862104e..bd3b7748723 100644
--- a/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0210.md
+++ b/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0210.md
@@ -1,6 +1,6 @@
 ---
 platform: ios
-title: Weak Encryption Algorithms
+title: Symmetric Encryption Algorithms with insufficient strength
 id: MASTG-TEST-0210
 type: [static, dynamic]
 weakness: MASWE-0020
@@ -8,7 +8,7 @@ weakness: MASWE-0020
 
 ## Overview
 
-To test for the use of weak encryption algorithms in iOS apps, we need to focus on methods from cryptographic frameworks and libraries that are used to perform encryption and decryption operations.
+To test for the use of encryption algorithms with insufficient strength in iOS apps, we need to focus on methods from cryptographic frameworks and libraries that are used to perform encryption and decryption operations.
 
 - **CommonCrypto**: The [`CCCrypt`](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/CCCrypt.3cc.html) function is used for **symmetric algorithms** and specifies the algorithm in its second parameter `alg`. This includes:
     - `kCCAlgorithmAES128`
@@ -18,7 +18,7 @@ To test for the use of weak encryption algorithms in iOS apps, we need to focus
     - `kCCAlgorithmRC4`
     - `kCCAlgorithmRC2`
 
-- **CryptoKit**: This library does not support weak encryption algorithms. It supports the following **symmetric algorithms**:
+- **CryptoKit**: This library does not support encryption algorithms with insufficient strength. It supports the following **symmetric algorithms**:
     - `AES.GCM`
     - `ChaChaPoly`
 
@@ -34,16 +34,16 @@ The output should contain the disassembled code of the functions using the relev
 
 ## Evaluation
 
-The test case fails if you can find the use of weak encryption algorithms within the source code. For example:
+The test case fails if you can find the use of encryption algorithms within the source code with insufficient strength. For example:
 
 - DES
 - 3DES
 - RC2
 - RC4
 
-**Stay up-to-date**: This is a non-exhaustive list of weak algorithms. Make sure to check the latest standards and recommendations from organizations such as the National Institute of Standards and Technology (NIST), the German Federal Office for Information Security (BSI) or any other relevant authority in your region.
+**Stay up-to-date**: This is a non-exhaustive list of deprecated, risky and broken algorithms. Make sure to check the latest standards and recommendations from organizations such as the National Institute of Standards and Technology (NIST), the German Federal Office for Information Security (BSI) or any other relevant authority in your region.
 
-Some algorithms may not be considered weak as a whole, but may have **weak configurations** that should be avoided. Such as using a key with insufficient strength or not being considered quantum-safe. For example, an AES 128-bit key size is considered weak considering quantum computing attacks.
+Some algorithms may not be considered to have insufficient strength, but may have **inappropriate configurations** that should be avoided. Such as using a seed or IV not generated by Cryptographically secure PRNGs (CSPRNG) or not being considered quantum-safe. For example, an AES 128-bit key size is considered insufficient considering quantum computing attacks. When building an app that uses data that will be stored for a considerable long time. Make sure that you follow NIST recommendations about how to ["Transition to Post-Quantum Cryptography Standards"](https://csrc.nist.gov/pubs/ir/8547/ipd).
 
 **Context Considerations**:
 
diff --git a/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md b/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md
index 374a6824814..f911916700c 100644
--- a/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md
+++ b/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md
@@ -1,6 +1,6 @@
 ---
 platform: ios
-title: Weak Hashing Algorithms
+title: Weak, Risky or Broken Hashing Algorithms
 id: MASTG-TEST-0211
 type: [static, dynamic]
 weakness: MASWE-0021
@@ -8,9 +8,9 @@ weakness: MASWE-0021
 
 ## Overview
 
-To test for the use of weak hashing algorithms in iOS apps, we need to focus on methods from cryptographic frameworks and libraries that are used to perform hashing operations.
+To test for the use of risky or broken hashing algorithms in iOS apps, we need to focus on methods from cryptographic frameworks and libraries that are used to perform hashing operations.
 
-- **CommonCrypto**: [CommonDigest.h](https://opensource.apple.com/source/CommonCrypto/CommonCrypto-36064/CommonCrypto/CommonDigest.h) defines the following **hashing algorithms**:
+- **CommonCrypto**: [CommonDigest.h](https://web.archive.org/web/20240606000312/https://opensource.apple.com/source/CommonCrypto/CommonCrypto-36064/CommonCrypto/CommonDigest.h) defines the following **hashing algorithms**:
     - `CC_MD2`
     - `CC_MD4`
     - `CC_MD5`
@@ -39,15 +39,15 @@ The output should contain the disassembled code of the functions using the relev
 
 ## Evaluation
 
-The test case fails if you can find the use of weak hashing algorithms within the source code. For example:
+The test case fails if you can find the use of "broken" hashing algorithms within the source code. For example:
 
 - MD5
 - SHA-1
 
-**Stay up-to-date**: This is a non-exhaustive list of weak algorithms. Make sure to check the latest standards and recommendations from organizations such as the National Institute of Standards and Technology (NIST), the German Federal Office for Information Security (BSI) or any other relevant authority in your region.
+**Stay up-to-date**: This is a non-exhaustive list of weak, risky or broken algorithms. Make sure to check the latest standards and recommendations from organizations such as the National Institute of Standards and Technology (NIST), the German Federal Office for Information Security (BSI) or any other relevant authority in your region. When building an app that uses hashes that will be stored for a considerable long time. Make sure that you follow NIST recommendations about how to ["Transition to Post-Quantum Cryptography Standards"](https://csrc.nist.gov/pubs/ir/8547/ipd).
 
 **Context Considerations**:
 
 To reduce false positives, make sure you understand the context in which the algorithm is being used before reporting the associated code as insecure. Ensure that it is being used in a security-relevant context to protect sensitive data.
 
-For example, using MD5 for hashing passwords is considered weak, but using MD5 for checksums or non-cryptographic purposes is acceptable.
+For example, using MD5 for hashing passwords is considered risky, but using MD5 for checksums or non-cryptographic purposes is acceptable.
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0009.md b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
index ce439aca37e..efbd610f26d 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0009.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
@@ -36,7 +36,7 @@ The digest (or hash) of an improper implemented- or used hash function may allow
 
 - **Inadequate Entropy During Key Generation**: Using a poor source of randomness can lead to predictable cryptographic keys. If the randomness lacks sufficient entropy, the generated keys may be easier for attackers to guess or recreate, compromising the security of the system.
 - **Insufficient Key Length**: Cryptographic keys that are too short provide inadequate security. For example, keys shorter than recommended lengths for modern algorithms may be vulnerable to brute force attacks, making them easier for attackers to break.
-- **Using Outdated or Weak Algorithms**: Relying on deprecated, risky or inherently or broken cryptographic algorithms can result in the generation of weaker keys. As these algorithms often have vulnerabilities or support shorter key lengths, they are more susceptible to modern attacks, compromising the overall security of the app.
+- **Using Outdated, Risky or Broken Algorithms**: Relying on deprecated, risky or inherently or broken cryptographic algorithms can result in the generation of weaker keys. As these algorithms often have vulnerabilities or support shorter key lengths, they are more susceptible to modern attacks, compromising the overall security of the app.
 
 ## Mitigations
 
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
index 84af37c42ac..02cc34d9213 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
@@ -14,7 +14,7 @@ refs:
 draft:
   description: e.g. PBKDF2 with insufficient iterations, lack of salt, etc.
   topics:
-  - weak sources
+  - improper cryptography
   - lack of salt encryption when doing PBKDF2
 status: draft
 
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0019.md b/weaknesses/MASVS-CRYPTO/MASWE-0019.md
index 970982d36e8..eafa0ae5dc6 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0019.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0019.md
@@ -1,5 +1,5 @@
 ---
-title: Deprecated, risky, or Noncompliant Cryptography Implementations
+title: Deprecated, risky, or Broken Cryptography Implementations
 id: MASWE-0019
 alias: potentially-weak-crypto-impl
 platform: [android, ios]
@@ -12,7 +12,7 @@ mappings:
 
 refs: 
  - https://book.hacktricks.xyz/crypto-and-stego/cryptographic-algorithms
- - https://dl.acm.org/doi/10.4108/eai.3-12-2015.2262471
+ - https://eudl.eu/pdf/10.4108/eai.3-12-2015.2262471
  - https://www.scitepress.org/papers/2014/50563/50563.pdf
  - https://pure.tugraz.at/ws/portalfiles/portal/23858147/main.pdf
  - https://github.com/Wind-River/crypto-detector
@@ -37,7 +37,7 @@ Custom cryptographic implementations created without following established stand
 
 The impact associated with such defects can be very broad and difficult to predict or measure:
 
-- **Data breaches**: Weak encryption can lead to unauthorized access to sensitive data, resulting in data breaches.
+- **Data breaches**: Deprecated, risky, or broken encryption can lead to unauthorized access to sensitive data, resulting in data breaches.
 - **Compromised confidentiality, integrity, and authenticity**: The core principles of cryptography (confidentiality, integrity, and authenticity) are compromised. Attackers can decrypt, manipulate, or impersonate legitimate users or systems.
 
 ## Modes of Introduction
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0020.md b/weaknesses/MASVS-CRYPTO/MASWE-0020.md
index fa5f0145d9a..530b7e09ca0 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0020.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0020.md
@@ -34,12 +34,12 @@ Deprecated, Risky, or Broken encryption refers to cryptographic systems or imple
 - **Use of Deprecated Algorithms** : Relying on deprecated, risky or vulnerable encryption algorithms can allow threat actors to attack the cipher text, key or exploit known vulnerabilities in the algorithm, for example through brute force attacks.
 - **Insecure Modes of Operation**:  Using modes that are considered deprecated or risky increase the attack surface of encrypted information. For example the use of AES/ECB is deprecated as it divides the plaintext into blocks and encrypts each block separately using the same key. This makes the cipher text vulnerable to "known plaintext attacks" and leaks information about the structure of the original plaintext.
 - **Predictable Initialization Vectors (IVs)**: If IVs are not random or unique, they can be exploited in attacks like ciphertext injection or pattern recognition. This compromises the confidentiality of encrypted data, especially in modes like CBC (Cipher Block Chaining).
-- **Weak Keys**: Short or easily guessable keys compromise encryption strength. The use of small key sizes (e.g., 56-bit keys in DES) can make the encryption susceptible to brute-force attacks. Best practices recommend keys of at least 256 bits for strong encryption.
+- **Short Keys**: Short or easily guessable keys compromise encryption strength. The use of small key sizes (e.g., 56-bit keys in DES) can make the encryption susceptible to brute-force attacks. Best practices recommend keys of at least 256 bits for strong encryption.
 - **Misuse of Non-Cryptographic Operations**: Relying on techniques such as XOR, Base64 encoding, or simple obfuscation methods for security purposes. These methods provide no actual encryption and can be easily reversed or decoded, exposing sensitive data.
 
 ## Mitigations
 
 - **Use Secure Encryption Modes**: Choose secure modes such as `AES/GCM/NoPadding` and avoid insecure modes such as ECB.  
 - **Ensure Proper Initialization Vector Management**: Generate IVs using cryptographically secure random number generators and ensure they are unique for every operation.
-- **Use Strong Key Sizes**: Enforce key lengths of at least 256 bits for AES and avoid using small or weak keys such as 56-bit DES keys.  
+- **Use Strong Key Sizes**: Enforce key lengths of at least 256 bits for AES and avoid using small or short keys such as 56-bit DES keys.  
 - **Rely on Proper Cryptographic Libraries**: Avoid using XOR, Base64 encoding, or obfuscation as substitutes for encryption and rely on well-vetted cryptographic libraries.
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0021.md b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
index b9a69587d1e..0b9089bc747 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0021.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
@@ -16,10 +16,10 @@ refs:
 - https://en.wikipedia.org/wiki/Collision_attack
 - https://csrc.nist.gov/pubs/ir/8547/ipd
 draft:
-  description: Utilizing weak hashing algorithms such as MD5 and SHA1 in a security
+  description: Utilizing broken hashing algorithms such as MD5 and SHA1 in a security
     sensitive context may compromise data integrity and authenticity.
   topics:
-  - Weak hashing algorithms (e.g. MD5, SHA1, etc.)
+  - Broken hashing algorithms (e.g. MD5, SHA1, etc.)
 status: draft
 ---
 
@@ -29,7 +29,7 @@ when performing key derivation together with predictable input or in password ha
 
 What is regarded as "reasonable" varies by context and threat model, but in general, "reasonable" could cover any attack that is more efficient than brute force (i.e., on average, attempting half of all possible combinations). Note that some attacks might be more efficient than brute force but are still not regarded as achievable in the real world.
 
-Any algorithm that does not meet the above conditions will generally be considered weak for general use in hashing. When a collision attack is discovered and is found to be faster than a birthday attack, a hash function is often denounced as "broken". This is the case for MD5 and SHA-1.
+Any algorithm that does not meet the above conditions will generally be considered risky or "weak" for general use in hashing. When a collision attack is discovered and is found to be faster than a birthday attack, a hash function is often denounced as "broken". This is the case for MD5 and SHA-1.
 
 Another common issue is using HKDF for key derivation with any type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HKDF aren't design for low-entropy inputs. Doing so will result in producing "weak" hashes that easily can be broken.
 
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0023.md b/weaknesses/MASVS-CRYPTO/MASWE-0023.md
index 8c156308c41..0ec5347330e 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0023.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0023.md
@@ -46,5 +46,5 @@ However, simply using a predictable padding scheme does not guarantee a padding
 ## Mitigations
 
 - **Use Authenticated Symmetric Encryption Modes**: Prefer authenticated encryption modes like AES-GCM, which eliminate the need for separate padding validation and incorporate integrity checks. If AES-CBC must be used, adopt the Encrypt-then-MAC paradigm (e.g., append HMAC). See [NIST SP 800-175B Rev.1, Section 4.3](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf).
-- **Use Secure Padding Schemes for Asymmetric Encryption**: Replace weak schemes like PKCS#1 v1.5 with secure ones such as OAEP (Optimal Asymmetric Encryption Padding). See [NIST SP 800-56B Rev.2, Section 7.2.2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf).
+- **Use Secure Padding Schemes for Asymmetric Encryption**: Replace predictable schemes like PKCS#1 v1.5 with secure ones such as OAEP (Optimal Asymmetric Encryption Padding). See [NIST SP 800-56B Rev.2, Section 7.2.2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf).
 - **Don't Expose Cryptographic Errors**: Do not expose cryptographic error messages, such as padding errors, to users. This prevents attackers from gaining clues about the padding's correctness.
diff --git a/weaknesses/MASVS-NETWORK/MASWE-0047.md b/weaknesses/MASVS-NETWORK/MASWE-0047.md
index 3f21c9b45b7..869b723fdca 100644
--- a/weaknesses/MASVS-NETWORK/MASWE-0047.md
+++ b/weaknesses/MASVS-NETWORK/MASWE-0047.md
@@ -13,7 +13,7 @@ status: new
 
 ## Overview
 
-[Identity pinning (aka. certificate pinning, public key pinning or TLS pinning)](../../Document/0x04f-Testing-Network-Communication/#restricting-trust-identity-pinning) refers to associating a mobile app with a specific cryptographic identity, such as a certificate or public key to ensure that the app only communicates with trusted servers.
+[Identity pinning (aka. certificate pinning, public key pinning or TLS pinning)](../../Document/0x04f-Testing-Network-Communication.md#restricting-trust-identity-pinning) refers to associating a mobile app with a specific cryptographic identity, such as a certificate or public key to ensure that the app only communicates with trusted servers.
 
 When a mobile app does not implement certificate pinning, or if it is implemented incorrectly, the app remains vulnerable to [Machine-in-the-Middle (MITM)](../../Document/0x04f-Testing-Network-Communication.md#intercepting-network-traffic-through-mitm) attacks which enable attackers to intercept and modify the communication between the app and the intended server. This occurs because when the app is presented a fraudulent certificate that the app may unknowingly trust, thereby gaining access to sensitive data or injecting malicious content into the data stream.
 
@@ -35,7 +35,7 @@ This highlights the importance of implementing certificate pinning **alongside o
 
 - **Improper Configuration of Pinning Libraries**: Misconfiguring libraries like TrustKit, OkHttp's `CertificatePinner`, Volley, or AFNetworking's `SSLPinningMode`, leading to ineffective pinning.
 - **Dynamic Pinning without Security**: Retrieving pins dynamically over insecure channels without proper validation, making it easy for attackers to supply malicious pins.
-- **Weak Validation Logic**: Custom pinning implementations that do not correctly validate the certificate chain or public key. For example, accepting any certificate that chains to a trusted root CA instead of a specific certificate or public key.
+- **Improper Validation Logic**: Custom pinning implementations that do not correctly validate the certificate chain or public key. For example, accepting any certificate that chains to a trusted root CA instead of a specific certificate or public key.
 - **Lack of Backup Pins**: Not including backup pins to prevent connectivity issues if the primary pin is no longer valid.
 
 ## Mitigations

From 51645138f83b78e539123d5f32681e3dc1911401 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 00:13:15 +0100
Subject: [PATCH 032/117] Update
 tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0208.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0208.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0208.md b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0208.md
index 8a3937f2db7..47ca26dd7a9 100644
--- a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0208.md
+++ b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0208.md
@@ -8,7 +8,7 @@ weakness: MASWE-0009
 
 ## Overview
 
-In this test case, we will look for the use Insufficient key sizes in Android apps. To do this, we need to focus on the cryptographic frameworks and libraries that are available in Android and the methods that are used to generate, inspect and manage cryptographic keys.
+In this test case, we will look for the use insufficient key sizes in Android apps. To do this, we need to focus on the cryptographic frameworks and libraries that are available in Android and the methods that are used to generate, inspect and manage cryptographic keys.
 
 The Java Cryptography Architecture (JCA) provides foundational classes for key generation which are often used directly when portability or compatibility with older systems is a concern.
 

From 2b3ce85cc15330e5497e3f2d82592cd246c21c50 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 00:14:04 +0100
Subject: [PATCH 033/117] Update
 tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0221.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0221.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0221.md b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0221.md
index 2cb7b5b5aff..63f8a6fd0c5 100644
--- a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0221.md
+++ b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0221.md
@@ -1,5 +1,5 @@
 ---
-title: Symmetric Encryption Algorithms with insufficient strength
+title: Symmetric Encryption Algorithms with Insufficient Strength
 platform: android
 id: MASTG-TEST-0221
 type: [static, dynamic]

From 34d98ead9460840791d7e7ce0171907ff5e2b81e Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 00:41:17 +0100
Subject: [PATCH 034/117] Exchange predictable with risky or broken

---
 tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md
index 609b892eff6..447e6b0607e 100644
--- a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md
+++ b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md
@@ -1,5 +1,5 @@
 ---
-title: Predictable Symmetric Encryption Modes
+title: Risky or broken Symmetric Encryption Modes
 platform: android
 id: MASTG-TEST-0232
 type: [static, dynamic]
@@ -9,7 +9,7 @@ best-practices: [MASTG-BEST-0005]
 
 ## Overview
 
-To test for the [use of predictable encryption modes](../../../Document/0x04g-Testing-Cryptography.md#weak-block-cipher-mode) in Android apps, we need to focus on methods from cryptographic frameworks and libraries that are used to configure and apply encryption modes.
+To test for the [use of risky or broken encryption modes](../../../Document/0x04g-Testing-Cryptography.md#weak-block-cipher-mode) in Android apps, we need to focus on methods from cryptographic frameworks and libraries that are used to configure and apply encryption modes.
 
 In Android development, the `Cipher` class from the Java Cryptography Architecture (JCA) is the primary API that allows you to specify the encryption mode for cryptographic operations. [`Cipher.getInstance`](https://developer.android.com/reference/javax/crypto/Cipher#getInstance(java.lang.String)) defines the transformation string, which includes the encryption algorithm, mode of operation, and padding scheme. The general format is `"Algorithm/Mode/Padding"`. For example:
 
@@ -40,8 +40,8 @@ In the transformation strings like `"RSA/ECB/OAEPPadding"` or `"RSA/ECB/PKCS1Pad
 
 ## Observation
 
-The output should contain a list of locations where insecure or deprecated encryption modes are used in cryptographic operations.
+The output should contain a list of locations where risky or broken encryption modes are used in cryptographic operations.
 
 ## Evaluation
 
-The test case fails if any insecure encryption modes are identified in the app.
+The test case fails if any risky or broken modes are identified in the app.

From 5ace337717749bf888a2f0bd04e632c13502d4b6 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 00:42:19 +0100
Subject: [PATCH 035/117] Change to upper case

---
 tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md
index 447e6b0607e..4abaef24d06 100644
--- a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md
+++ b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md
@@ -1,5 +1,5 @@
 ---
-title: Risky or broken Symmetric Encryption Modes
+title: Risky or Broken Symmetric Encryption Modes
 platform: android
 id: MASTG-TEST-0232
 type: [static, dynamic]

From 5492f30d88811e35ba55109bad5790bed5fee4a0 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:02:51 +0100
Subject: [PATCH 036/117] Use risky or broken.

---
 tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md b/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md
index f911916700c..a6f4ab09905 100644
--- a/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md
+++ b/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md
@@ -1,6 +1,6 @@
 ---
 platform: ios
-title: Weak, Risky or Broken Hashing Algorithms
+title: Risky or Broken Hashing Algorithms
 id: MASTG-TEST-0211
 type: [static, dynamic]
 weakness: MASWE-0021

From 91d839af4db03b20a62311276b0ceca8ca40342a Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:04:16 +0100
Subject: [PATCH 037/117] Update weaknesses/MASVS-CRYPTO/MASWE-0019.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 weaknesses/MASVS-CRYPTO/MASWE-0019.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0019.md b/weaknesses/MASVS-CRYPTO/MASWE-0019.md
index eafa0ae5dc6..1baa84ba934 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0019.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0019.md
@@ -1,5 +1,6 @@
 ---
-title: Deprecated, risky, or Broken Cryptography Implementations
+title: Deprecated, Risky, or Broken Cryptography Implementations
+
 id: MASWE-0019
 alias: potentially-weak-crypto-impl
 platform: [android, ios]

From 05590a98296daa39600cc3b5b1f5f96541f1d9ee Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:05:18 +0100
Subject: [PATCH 038/117] Update weaknesses/MASVS-CRYPTO/MASWE-0020.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 weaknesses/MASVS-CRYPTO/MASWE-0020.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0020.md b/weaknesses/MASVS-CRYPTO/MASWE-0020.md
index 530b7e09ca0..b7397bd6197 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0020.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0020.md
@@ -21,7 +21,7 @@ status: new
 
 ## Overview
 
-Deprecated, Risky, or Broken encryption refers to cryptographic systems or implementations that are vulnerable to attack, allowing unauthorized individuals to decrypt secured data. This  can be due to a number of reasons, including the use of deprecated, risky or broken algorithms, deprecated or risky encryption modes such as ECB and improper implementation practices such as the use of a non-random or empty Initialization Vector (IV).
+Deprecated, risky, or broken encryption refers to cryptographic systems or implementations that are vulnerable to attack, allowing unauthorized individuals to decrypt secured data. This can be due to a number of reasons, including the use of deprecated, risky or broken algorithms, deprecated or risky encryption modes such as ECB and improper implementation practices such as the use of a non-random or empty Initialization Vector (IV).
 
 ## Impact
 

From 59e271b73426aaeab49eb475c8b8fec79de17c2f Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:12:01 +0100
Subject: [PATCH 039/117] replace weak with deprecated

---
 weaknesses/MASVS-CRYPTO/MASWE-0021.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0021.md b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
index 0b9089bc747..6eb4f28fe6f 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0021.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
@@ -1,5 +1,5 @@
 ---
-title: Weak, Risky or Broken Hashing
+title: Deprecated, Risky or Broken Hashing
 id: MASWE-0021
 alias: weak-hashing
 platform: [android, ios]
@@ -23,25 +23,25 @@ draft:
 status: draft
 ---
 
-Choosing a weak hash algorithm, that is insufficiently collision resistant, may compromise the integrity and authenticity of data at rest and in transit by opening the application up for collision attacks.
+Choosing a deprecated, risky or broken hash algorithm, that is insufficiently collision resistant, may compromise the integrity and authenticity of data at rest and in transit by opening the application up for collision attacks.
 
 when performing key derivation together with predictable input or in password hashing, the digest (or hash) of an improper implemented- or used hash function may allow and adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack/collision attack), given the actor can arbitrarily choose the inputs to be hashed and can do so a reasonable amount of times
 
 What is regarded as "reasonable" varies by context and threat model, but in general, "reasonable" could cover any attack that is more efficient than brute force (i.e., on average, attempting half of all possible combinations). Note that some attacks might be more efficient than brute force but are still not regarded as achievable in the real world.
 
-Any algorithm that does not meet the above conditions will generally be considered risky or "weak" for general use in hashing. When a collision attack is discovered and is found to be faster than a birthday attack, a hash function is often denounced as "broken". This is the case for MD5 and SHA-1.
+Any algorithm that does not meet the above conditions will generally be considered risky or to "weak" for general use in hashing. When a collision attack is discovered and is found to be faster than a birthday attack, a hash function is often denounced as "broken". This is the case for MD5 and SHA-1.
 
 Another common issue is using HKDF for key derivation with any type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HKDF aren't design for low-entropy inputs. Doing so will result in producing "weak" hashes that easily can be broken.
 
 ## Impact
 
-- **Loss of Integrity and authenticity**: A weak, risky or broken hashing algorithm, may allow an attacker to compromise the integrity and authenticity of data at rest and in transit.
-- **Loss of Confidentiality**: A  weak, risky or broken hashing algorithm may expose the preimage (input) and in so doing break the confidentiality.
-- **Risk of Brute-Force Attacks**: A  weak, risky or broken hashing is susceptible to brute-force attacks.
+- **Loss of Integrity and authenticity**: A deprecated, risky or broken hashing algorithm, may allow an attacker to compromise the integrity and authenticity of data at rest and in transit.
+- **Loss of Confidentiality**: A  deprecated, risky or broken hashing algorithm may expose the preimage (input) and in so doing break the confidentiality.
+- **Risk of Brute-Force Attacks**: A  deprecated, risky or broken hashing is susceptible to brute-force attacks.
 
 ## Modes of Introduction
 
-- **using a weak, risky or broken hashing algorithm**: E.g: MD5 and SHA-1 has been identified to be vulnerable for collision attacks that are faster than a birthday attack. Meaning that they are denounced as "broken".
+- **using a deprecated, risky or broken hashing algorithm**: E.g: MD5 and SHA-1 has been identified to be vulnerable for collision attacks that are faster than a birthday attack. Meaning that they are denounced as "broken".
 - **Using a insufficiently collision resistant hash**: Choosing a a hashing algorithm of insufficient length may result in loss of integrity or confidentiality.
 - **Using non-resource intensive algorithms on low-entropy input**: Using a integrity based hashing algorithm to hash low-entry input like pin numbers would make brute-force or dictionary attacks trivial.
 

From 8c7a5b7cc8a8c31cffbfa5d71469c6a88157ec75 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:13:41 +0100
Subject: [PATCH 040/117] Update weaknesses/MASVS-CRYPTO/MASWE-0024.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 weaknesses/MASVS-CRYPTO/MASWE-0024.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
index dc4f740d6c4..3b04cbf091d 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
@@ -1,5 +1,5 @@
 ---
-title: Improper use of Message Authentication Code (MAC)
+title: Improper Use of Message Authentication Code (MAC)
 id: MASWE-0024
 alias: weak-mac
 platform: [android, ios]

From 31dae7fee69fc26fa7c656c3422e4ad45916f9ec Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:18:58 +0100
Subject: [PATCH 041/117] Minor corrections to improve language.

---
 weaknesses/MASVS-CRYPTO/MASWE-0024.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
index 3b04cbf091d..f5cf9605aa8 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
@@ -26,7 +26,7 @@ Improper use of MAC by e.g by generating a MAC over a message without the timest
 
 Another common issue is using HMAC with on low-entropy input with any type of general based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HMAC aren't designed for low-entropy inputs or low-entropy keys. Doing so will result in producing "weak" message digest that easily can be exploited.
 
-There could also be issues with a specific and deprecated HMAC implementation.
+A deprecated HMAC implementation may contain bugs that could compromise authenticity of the data.
 
 ## Impact
 

From 910b0e14fb9a6417e0344aa47bac95f710c29672 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:23:11 +0100
Subject: [PATCH 042/117] Update MASWE-0024.md

---
 weaknesses/MASVS-CRYPTO/MASWE-0024.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
index f5cf9605aa8..e8fa088606c 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
@@ -26,7 +26,7 @@ Improper use of MAC by e.g by generating a MAC over a message without the timest
 
 Another common issue is using HMAC with on low-entropy input with any type of general based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HMAC aren't designed for low-entropy inputs or low-entropy keys. Doing so will result in producing "weak" message digest that easily can be exploited.
 
-A deprecated HMAC implementation may contain bugs that could compromise authenticity of the data.
+A deprecated HMAC implementation may contain bugs that could compromise the authenticity of the data.
 
 ## Impact
 
@@ -35,8 +35,8 @@ A deprecated HMAC implementation may contain bugs that could compromise authenti
 
 ## Modes of Introduction
 
-- **Not authenticating including a timestamp**: Creating a MAC without using and a proper timestamp that can be validated for the possibility of replay-attacks.
-- **Using a MAC for other purposes then message authentication**: Using low-entropy inputs or low-entropy keys as input to a HMAC.
+- **Not including a timestamp**: Creating a MAC for message authentication without using and a proper timestamp that can be validated for the possibility of replay-attacks.
+- **Using a MAC with low-entropy keys**: Using low-entropy inputs or low-entropy keys as input to a HMAC.
 
 ## Mitigations
 

From 83db34d752cfe727ca7cd2d7c9647035b5f82a69 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:24:27 +0100
Subject: [PATCH 043/117] Update MASWE-0024.md

---
 weaknesses/MASVS-CRYPTO/MASWE-0024.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
index e8fa088606c..07d92d09684 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
@@ -35,7 +35,7 @@ A deprecated HMAC implementation may contain bugs that could compromise the auth
 
 ## Modes of Introduction
 
-- **Not including a timestamp**: Creating a MAC for message authentication without using and a proper timestamp that can be validated for the possibility of replay-attacks.
+- **Not including a timestamp**: Creating a MAC for message authentication without using a proper timestamp that can be validated for the possibility of replay-attacks.
 - **Using a MAC with low-entropy keys**: Using low-entropy inputs or low-entropy keys as input to a HMAC.
 
 ## Mitigations

From bc6b470460f5e35c36153d6799d1547d542f2e25 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:27:42 +0100
Subject: [PATCH 044/117] Update MASWE-0024.md

---
 weaknesses/MASVS-CRYPTO/MASWE-0024.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
index 07d92d09684..7733f59952e 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
@@ -42,4 +42,4 @@ A deprecated HMAC implementation may contain bugs that could compromise the auth
 
 - **Use MAC with a timestamp**: Generate the MAC over a message with the timestamp included. This should protect the application against replay attacks within a reasonable amount of time. Reasonable, meaning a time frame that is short enough to prevent an attacker from sending an identical message and long enough to allow the message to be sent and digested.
 - **Do not use HMAC together with a low-entropy key**: Ensure the keys used are generated using Ccyptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks.
-- **Do not use deprecated HMCA implementations**: Deprecated HMCA implementation could contain errors that allow for collision attacks. Therefore, only use up to date libraries and functions.
+- **Do not use deprecated HMCA implementations**: Deprecated HMCA implementations could contain errors that allow for collision attacks. Therefore, only use recommended libraries and functions.

From 6a29aae062637d7a1a3cd280c5e8fdb5133198db Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:28:42 +0100
Subject: [PATCH 045/117] Apply suggestions from code review

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 weaknesses/MASVS-CRYPTO/MASWE-0025.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0025.md b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
index 73497c96eb1..84f40369506 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0025.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
@@ -1,5 +1,5 @@
 ---
-title: Signatures created by Deprecated, Risky or Broken algorithms.
+title: Signatures Created by Deprecated, Risky or Broken Algorithms
 id: MASWE-0025
 alias: weak-signatures
 platform: [android, ios]

From 749c3a95f55871713e6e877a40ac01f520295ff7 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:29:43 +0100
Subject: [PATCH 046/117] Update weaknesses/MASVS-CRYPTO/MASWE-0025.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 weaknesses/MASVS-CRYPTO/MASWE-0025.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0025.md b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
index 84f40369506..459b834ecc7 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0025.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
@@ -28,7 +28,7 @@ Using deprecated, risky or broken algorithms for the purpose of ensuring account
 
 ## Modes of Introduction
 
-- **using a weak, risky or broken hashing algorithm**: E.g: MD5 and SHA-1 has been identified to be vulnerable for collision attacks that are faster than a birthday attack. Meaning that they are denounced as "broken".
+- **Using a weak, risky or broken hashing algorithm**: e.g. MD5 and SHA-1 has been identified to be vulnerable for collision attacks that are faster than a birthday attack. Meaning that they are denounced as "broken".
 - **Using a insufficiently collision resistant hash**: Choosing a a hashing algorithm of insufficient length may result in loss of integrity or confidentiality.
 
 ## Mitigations

From 5a523e689d54a534deed0f89627d825fea1c23ed Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:30:43 +0100
Subject: [PATCH 047/117] Apply suggestions from code review

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 weaknesses/MASVS-CRYPTO/MASWE-0025.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0025.md b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
index 459b834ecc7..456a37b8008 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0025.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
@@ -35,4 +35,4 @@ Using deprecated, risky or broken algorithms for the purpose of ensuring account
 
 - **Choose collision resistant algorithm**: Choose a signature algorithm that is sufficiently collision resistant like RSA (3072 bits and higher), ECDSA with NIST P-384 or EdDSA with Edwards448.
 
-- **Choose an signing scheme that make use of algorithms with sufficient bit-lengths**: As our computers gets stronger, the hashes gets weaker, therefore, make sure that you can adjust the bit-length length (strength) of the algorithm of your choosing. When signatures are stored at rest, make sure to follow the software industry's long term recommendations (e.g: ["NIST: Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd)").
+- **Choose an signing scheme that make use of algorithms with sufficient bit-lengths**: As our computers gets stronger, the hashes gets weaker, therefore, make sure that you can adjust the bit-length length (strength) of the algorithm of your choosing. When signatures are stored at rest, make sure to follow the software industry's long term recommendations (e.g. ["NIST: Transition to Post-Quantum Cryptography Standards"](https://csrc.nist.gov/pubs/ir/8547/ipd)).

From e87add91e63daed919e2b882cee819a530bd8d14 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:33:25 +0100
Subject: [PATCH 048/117] Update MASWE-0025.md

---
 weaknesses/MASVS-CRYPTO/MASWE-0025.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0025.md b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
index 456a37b8008..73a965f2232 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0025.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
@@ -28,7 +28,7 @@ Using deprecated, risky or broken algorithms for the purpose of ensuring account
 
 ## Modes of Introduction
 
-- **Using a weak, risky or broken hashing algorithm**: e.g. MD5 and SHA-1 has been identified to be vulnerable for collision attacks that are faster than a birthday attack. Meaning that they are denounced as "broken".
+- **Using a deprecated, risky or broken hashing algorithm**: e.g. MD5 and SHA-1 has been identified to be vulnerable for collision attacks that are faster than a birthday attack. Meaning that they are denounced as "broken".
 - **Using a insufficiently collision resistant hash**: Choosing a a hashing algorithm of insufficient length may result in loss of integrity or confidentiality.
 
 ## Mitigations

From 4985c62ef60007f30c9c890e0c23c52d34a9e2e0 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:34:47 +0100
Subject: [PATCH 049/117] correct spelling

---
 weaknesses/MASVS-CRYPTO/MASWE-0024.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
index 7733f59952e..d63ce88e12e 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
@@ -41,5 +41,5 @@ A deprecated HMAC implementation may contain bugs that could compromise the auth
 ## Mitigations
 
 - **Use MAC with a timestamp**: Generate the MAC over a message with the timestamp included. This should protect the application against replay attacks within a reasonable amount of time. Reasonable, meaning a time frame that is short enough to prevent an attacker from sending an identical message and long enough to allow the message to be sent and digested.
-- **Do not use HMAC together with a low-entropy key**: Ensure the keys used are generated using Ccyptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks.
+- **Do not use HMAC together with a low-entropy key**: Ensure the keys used are generated using cyptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks.
 - **Do not use deprecated HMCA implementations**: Deprecated HMCA implementations could contain errors that allow for collision attacks. Therefore, only use recommended libraries and functions.

From 589aef41f9b7bbff61f13a506ba12d035a2b0380 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:37:08 +0100
Subject: [PATCH 050/117] Update Document/0x04g-Testing-Cryptography.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index e678177bb5b..9a5b656704c 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -17,7 +17,7 @@ Encryption algorithms converts plaintext data into cipher text that conceals the
 
 **Public-key encryption algorithms** operate with two separate keys: the public key and the private key. The public key can be distributed freely while the private key shouldn't be shared with anyone. A message encrypted with the public key can only be decrypted with the private key and vice-versa. Since asymmetric encryption is several times slower than symmetric operations, it's typically only used to encrypt small amounts of data, such as symmetric keys for bulk encryption.
 
-**Hashing** isn't a form of encryption, but it does use cryptography. Hash functions deterministically map arbitrary pieces of data into fixed-length values. It's easy to compute the hash from the input, but very difficult (i.e. infeasible) to determine the original input from the hash. Additionally, the hash will completely change when even a single bit of the input changes. Hash functions are used for password storage, integrity verification (e.g: digital signatures or document management) or file management. Hash functions don't provide an authenticity guarantee, but can be combined as cryptographic primitives to do so.
+**Hashing** isn't a form of encryption, but it does use cryptography. Hash functions deterministically map arbitrary pieces of data into fixed-length values. It's easy to compute the hash from the input, but very difficult (i.e. infeasible) to determine the original input from the hash. Additionally, the hash will completely change when even a single bit of the input changes. Hash functions are used for password storage, integrity verification (e.g. digital signatures or document management) or file management. Hash functions don't provide an authenticity guarantee, but can be combined as cryptographic primitives to do so.
 
 **Message Authentication Codes** (MACs) combine other cryptographic mechanisms (such as symmetric encryption or hashes) with secret keys to provide both integrity and authenticity protection. However, in order to verify a MAC, multiple entities have to share the same secret key and any of those entities can generate a valid MAC. HMACs, the most commonly used type of MAC, rely on hashing as the underlying cryptographic primitive. The full name of an HMAC algorithm usually includes the underlying hash function's type (for example, HMAC-SHA256 uses the SHA-256 hash function).
 

From 6a3d02be825b66f8c4d7526f52cf37d0174dec62 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:37:33 +0100
Subject: [PATCH 051/117] Update Document/0x04g-Testing-Cryptography.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 Document/0x04g-Testing-Cryptography.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 9a5b656704c..905ff8d9ab5 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -118,8 +118,7 @@ Key derivation functions derive bytes suitable for cryptographic operations from
 
 Different KDFs are suitable for different tasks such as:
 
-- Cryptographic key derivation
-
+- Cryptographic key derivation:
     - Together with a non-secret parameter to derive one or more keys from a common secret value. Also known as known as "key diversification"
     - As components of multiparty key-agreement protocols (e.g: [KDF1](https://en.wikipedia.org/wiki/IEEE_P1363)).
     - To derive keys from secret passwords or passphrases.

From 92c7f3b9610209e35e1333786038507f41b459d0 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:38:01 +0100
Subject: [PATCH 052/117] Update Document/0x04g-Testing-Cryptography.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 Document/0x04g-Testing-Cryptography.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 905ff8d9ab5..fffff47b67d 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -125,8 +125,7 @@ Different KDFs are suitable for different tasks such as:
     - To derive keys of different length from the ones provided (e.g: [PBKDF2HMAC](https://en.wikipedia.org/wiki/PBKDF2) or [HKDF](https://en.wikipedia.org/wiki/HKDF)).
     - [Key stretching](https://en.wikipedia.org/wiki/Key_stretching) and [key strengthening](https://en.wikipedia.org/wiki/Key_derivation_function#Key_stretching_and_key_strengthening).
 
-- Password storage
-
+- Password storage:
     - In order to ensure attacker's can't use a stolen password even in the event of a data breach, passwords are stored as hashes computed through a computationally intensive KDF. The ideal password storage's KDF should be demanding on both computational and memory resources.
 
 source: ([Wikipedia, 2025.02.21"](https://en.wikipedia.org/wiki/Key_derivation_function "Key derivation function"))

From 07c2f6ccb5df3a5a51489dae8467a6fb3873bdcb Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 12 Mar 2025 01:38:36 +0100
Subject: [PATCH 053/117] Update Document/0x04g-Testing-Cryptography.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index fffff47b67d..8aaec5c712d 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -128,7 +128,7 @@ Different KDFs are suitable for different tasks such as:
 - Password storage:
     - In order to ensure attacker's can't use a stolen password even in the event of a data breach, passwords are stored as hashes computed through a computationally intensive KDF. The ideal password storage's KDF should be demanding on both computational and memory resources.
 
-source: ([Wikipedia, 2025.02.21"](https://en.wikipedia.org/wiki/Key_derivation_function "Key derivation function"))
+Source: ([Wikipedia, 2025.02.21"](https://en.wikipedia.org/wiki/Key_derivation_function "Key derivation function"))
 
 When using a KDF for cryptographic operations always ensure to use a recommended and approved KDF properly according to the latest recommendations and the software provider's documentation. E.g Only using a key derivation functions that is constructed from hashes against which no non-trivial pre-image or length-extension attacks are known and where attacking the key derivation function directly is infeasible. Using user-supplied input together with HKDF will make it easy for password crackers to execute a preimage attack.
 

From ce405a56f3c13dd4ec65fbc2ae44be1dff9bb10b Mon Sep 17 00:00:00 2001
From: Johan Sydseter <johan.sydseter@admincontrol.com>
Date: Wed, 12 Mar 2025 02:41:30 +0100
Subject: [PATCH 054/117] Align the DEMOs with the wording used elsewhere.

---
 .../MASTG-DEMO-0012/MASTG-DEMO-0012.md         |  6 +++---
 .../MASVS-CRYPTO/MASTG-DEMO-0012/output.txt    |  2 +-
 .../MASVS-CRYPTO/MASTG-DEMO-0012/run.sh        |  2 +-
 .../MASTG-DEMO-0022/MASTG-DEMO-0022.md         |  8 ++++----
 .../MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt  | 18 +++++++++---------
 .../MASVS-CRYPTO/MASTG-DEMO-0022/output.txt    |  5 ++---
 .../MASVS-CRYPTO/MASTG-DEMO-0022/run.sh        |  2 +-
 .../MASTG-DEMO-0023/MASTG-DEMO-0023.md         |  8 ++++----
 .../MASVS-CRYPTO/MASTG-DEMO-0023/output.txt    |  5 ++---
 .../MASVS-CRYPTO/MASTG-DEMO-0023/run.sh        |  2 +-
 .../MASTG-DEMO-0011/MASTG-DEMO-0011.md         |  4 ++--
 .../MASTG-DEMO-0015/MASTG-DEMO-0015.md         |  2 +-
 .../MASTG-DEMO-0016/MASTG-DEMO-0016.md         |  2 +-
 .../MASTG-DEMO-0018/MASTG-DEMO-0018.md         |  2 +-
 ...eneration-with-insufficient-key-length.yml} |  2 +-
 ...g-android-risky-encryption-algorithms.yaml} |  2 +-
 ... mastg-android-risky-encryption-modes.yaml} |  2 +-
 17 files changed, 36 insertions(+), 38 deletions(-)
 rename rules/{mastg-android-weak-key-generation.yml => mastg-android-key-generation-with-insufficient-key-length.yml} (95%)
 rename rules/{mastg-android-weak-encryption-algorithms.yaml => mastg-android-risky-encryption-algorithms.yaml} (90%)
 rename rules/{mastg-android-weak-encryption-modes.yaml => mastg-android-risky-encryption-modes.yaml} (92%)

diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/MASTG-DEMO-0012.md b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/MASTG-DEMO-0012.md
index 4f848aa3dd9..7bfaad522e9 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/MASTG-DEMO-0012.md
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/MASTG-DEMO-0012.md
@@ -1,6 +1,6 @@
 ---
 platform: android
-title: Weak Cryptographic Key Generation
+title: Cryptographic Key Generation With Insufficient Key Length
 code: [java]
 id: MASTG-DEMO-0012
 test: MASTG-TEST-0208
@@ -14,7 +14,7 @@ test: MASTG-TEST-0208
 
 Let's run our @MASTG-TOOL-0110 rule against the sample code.
 
-{{ ../../../../rules/mastg-android-weak-key-generation.yml }}
+{{ ../../../../rules/mastg-android-key-generation-with-insufficient-key-length.yml }}
 
 {{ run.sh }}
 
@@ -26,4 +26,4 @@ The rule has identified some instances in the code file where cryptographic keys
 
 ### Evaluation
 
-The test fails because the key size of the RSA key is set to `1024` bits, and the size of the AES key is set to `128`, which is considered weak in both cases.
+The test fails because the key size of the RSA key is set to `1024` bits, and the size of the AES key is set to `128`, which is considered insufficient in both cases.
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/output.txt b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/output.txt
index 15a6ebb5b8c..d3311fb36db 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/output.txt
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/output.txt
@@ -5,7 +5,7 @@
 └─────────────────┘
 
     MastgTest_reversed.java
-    ❯❱ weak_key_size
+    ❯❱ insufficient_key_size
           Cryptographic implementations with insufficient key length are being used.
 
            27┆ KeyPairGenerator generator = KeyPairGenerator.getInstance("RSA");
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/run.sh b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/run.sh
index 65d4a6e8fa1..bd90759c309 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/run.sh
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/run.sh
@@ -1 +1 @@
-NO_COLOR=true semgrep -c ../../../../rules/mastg-android-weak-key-generation.yml ./MastgTest_reversed.java --text -o output.txt
\ No newline at end of file
+NO_COLOR=true semgrep -c ../../../../rules/mastg-android-key-generation-with-insufficient-key-length.yml ./MastgTest_reversed.java --text -o output.txt
\ No newline at end of file
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MASTG-DEMO-0022.md b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MASTG-DEMO-0022.md
index 6499a6cee01..babab99ee7c 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MASTG-DEMO-0022.md
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MASTG-DEMO-0022.md
@@ -1,6 +1,6 @@
 ---
 platform: android
-title: Uses of Insecure Symmetric Encryption Algorithms in Cipher with semgrep
+title: Uses of Deprecated, Risky or Broken Symmetric Encryption Algorithms in Cipher with semgrep
 id: MASTG-DEMO-0022
 code: [kotlin]
 test: MASTG-TEST-0221
@@ -16,18 +16,18 @@ The code snippet below shows sample code contains use of insecure encryption alg
 
 Let's run our @MASTG-TOOL-0110 rule against the sample code.
 
-{{ ../../../../rules/mastg-android-weak-encryption-algorithms.yaml }}
+{{ ../../../../rules/mastg-android-risky-encryption-algorithms.yaml }}
 
 {{ run.sh }}
 
 ### Observation
 
-The rule has identified two instances in the code file where insecure encryption algorithms are used. The specified line numbers can be located in the reverse-engineered code for further investigation and remediation.
+The rule has identified two instances in the code file where deprecated, risky or broken encryption algorithms are used. The specified line numbers can be located in the reverse-engineered code for further investigation and remediation.
 
 {{ output.txt }}
 
 ### Evaluation
 
-The test fails due to the use of weak encryption algorithms, specifically DES, 3DES, RC4 and Blowfish.
+The test fails due to the use of deprecated, risky or broken encryption algorithms, specifically DES, 3DES, RC4 and Blowfish.
 
 See @MASTG-TEST-0221 for more information.
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt
index 1773b838987..f7153463a5e 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt
@@ -13,7 +13,7 @@ import javax.crypto.SecretKey
 
 class MastgTest(private val context: Context) {
 
-    // Vulnerable encryption using DES (weak algorithm)
+    // Vulnerable encryption using DES (broken algorithm)
     fun vulnerableDesEncryption(data: String): String {
         try {
             // Weak key for DES
@@ -23,7 +23,7 @@ class MastgTest(private val context: Context) {
             val keyFactory = SecretKeyFactory.getInstance("DES")
             val secretKey: Key = keyFactory.generateSecret(keySpec)
 
-            // Weak encryption algorithm (DES)
+            // Risky encryption algorithm (DES)
             val cipher = Cipher.getInstance("DES")
             cipher.init(Cipher.ENCRYPT_MODE, secretKey)
 
@@ -44,7 +44,7 @@ class MastgTest(private val context: Context) {
             val keyFactory = SecretKeyFactory.getInstance("DESede")
             val secretKey: Key = keyFactory.generateSecret(keySpec)
 
-            // Weak encryption algorithm (3DES)
+            // Risky encryption algorithm (3DES)
             val cipher = Cipher.getInstance("DESede")
             cipher.init(Cipher.ENCRYPT_MODE, secretKey)
 
@@ -72,15 +72,15 @@ class MastgTest(private val context: Context) {
         }
     }
 
-    // Insecure encryption using Blowfish (weak algorithm)
+    // Risky encryption using Blowfish (weak algorithm)
     fun vulnerableBlowfishEncryption(data: String): String {
         return try {
-            // Weak key for Blowfish (insecure, small key size)
+            // Weak key for Blowfish (risky, small key size)
             val keyBytes = ByteArray(8) // Only 8 bytes (64-bit key) - not secure
             SecureRandom().nextBytes(keyBytes)
             val secretKey: SecretKey = SecretKeySpec(keyBytes, "Blowfish")
 
-            // Weak encryption algorithm (Blowfish)
+            // Risky encryption algorithm (Blowfish)
             val cipher = Cipher.getInstance("Blowfish")
             cipher.init(Cipher.ENCRYPT_MODE, secretKey)
 
@@ -95,16 +95,16 @@ class MastgTest(private val context: Context) {
     fun mastgTest(): String {
         val sensitiveString = "Hello from the OWASP MASTG Test app."
 
-        // Encrypt with weak DES
+        // Encrypt with broken DES
         val desEncryptedString = vulnerableDesEncryption(sensitiveString)
 
-        // Encrypt with weak 3DES
+        // Encrypt with risky 3DES
         val tripleDesEncryptedString = vulnerable3DesEncryption(sensitiveString)
 
         // Encrypt with deprecated RC4
         val rc4EncryptedString = vulnerableRc4Encryption(sensitiveString)
 
-        // Encrypt with weak Blowfish
+        // Encrypt with risky Blowfish
         val blowfishEncryptedString = vulnerableBlowfishEncryption(sensitiveString)
 
         // Returning the encrypted results
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/output.txt b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/output.txt
index 94de74275bb..20d57ce451d 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/output.txt
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/output.txt
@@ -5,8 +5,8 @@
 └─────────────────┘
                            
     MastgTest_reversed.java
-    ❯❱ rules.weak-encryption-algorithms
-          [MASVS-CRYPTO-1] Weak encryption algorithms found in use.
+    ❯❱ rules.risky-encryption-algorithms
+          [MASVS-CRYPTO-1] Deprecated, risky or broken encryption algorithms found in use.
                                                                    
            39┆ Cipher cipher = Cipher.getInstance("DES");
             ⋮┆----------------------------------------
@@ -15,4 +15,3 @@
            81┆ Cipher cipher = Cipher.getInstance("RC4");
             ⋮┆----------------------------------------
           100┆ Cipher cipher = Cipher.getInstance("Blowfish");
-
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/run.sh b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/run.sh
index 777fb7e9a39..31fdf2d0fda 100755
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/run.sh
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/run.sh
@@ -1 +1 @@
-NO_COLOR=true semgrep -c ../../../../rules/mastg-android-weak-encryption-algorithms.yaml ./MastgTest_reversed.java --text > output.txt
\ No newline at end of file
+NO_COLOR=true semgrep -c ../../../../rules/mastg-android-risky-encryption-algorithms.yaml ./MastgTest_reversed.java --text > output.txt
\ No newline at end of file
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/MASTG-DEMO-0023.md b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/MASTG-DEMO-0023.md
index ca7d28f6cbb..7adc18c526c 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/MASTG-DEMO-0023.md
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/MASTG-DEMO-0023.md
@@ -1,6 +1,6 @@
 ---
 platform: android
-title: Uses of Insecure Encryption Modes in Cipher with semgrep
+title: Uses of Risky or Broken Encryption Modes in Cipher with semgrep
 id: MASTG-DEMO-0023
 code: [kotlin]
 test: MASTG-TEST-0232
@@ -8,7 +8,7 @@ test: MASTG-TEST-0232
 
 ### Sample
 
-The code snippet below shows sample code contains use of insecure encryption modes.
+The code snippet below shows sample code contains use of risky or broken encryption modes.
 
 {{ MastgTest.kt # MastgTest_reversed.java }}
 
@@ -16,13 +16,13 @@ The code snippet below shows sample code contains use of insecure encryption mod
 
 Let's run our @MASTG-TOOL-0110 rule against the sample code.
 
-{{ ../../../../rules/mastg-android-weak-encryption-modes.yaml }}
+{{ ../../../../rules/mastg-android-risky-encryption-modes.yaml }}
 
 {{ run.sh }}
 
 ### Observation
 
-The rule has identified six instances in the code file where insecure encryption modes are used. The specified line numbers can be located in the reverse-engineered code for further investigation and remediation.
+The rule has identified six instances in the code file where risky or broken encryption modes are used. The specified line numbers can be located in the reverse-engineered code for further investigation and remediation.
 
 {{ output.txt }}
 
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/output.txt b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/output.txt
index 9b8be69aaa6..82162e75a5f 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/output.txt
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/output.txt
@@ -5,8 +5,8 @@
 └─────────────────┘
                            
     MastgTest_reversed.java
-    ❯❱ rules.weak-encryption-modes
-          [MASVS-CRYPTO-1] Weak encryption modes found in use.
+    ❯❱ rules.risky-encryption-modes
+          [MASVS-CRYPTO-1] Risky or broken encryption modes found in use.
                                                               
            36┆ Cipher cipher = Cipher.getInstance("AES");
             ⋮┆----------------------------------------
@@ -19,4 +19,3 @@
           118┆ Cipher cipher = Cipher.getInstance("DES/ECB/PKCS5Padding");
             ⋮┆----------------------------------------
           141┆ Cipher cipher = Cipher.getInstance("DESede/ECB/PKCS5Padding");
-
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/run.sh b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/run.sh
index 5b20c928474..98abe4ea041 100755
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/run.sh
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/run.sh
@@ -1 +1 @@
-NO_COLOR=true semgrep -c ../../../../rules/mastg-android-weak-encryption-modes.yaml ./MastgTest_reversed.java --text > output.txt
\ No newline at end of file
+NO_COLOR=true semgrep -c ../../../../rules/mastg-android-risky-encryption-modes.yaml ./MastgTest_reversed.java --text > output.txt
\ No newline at end of file
diff --git a/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0011/MASTG-DEMO-0011.md b/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0011/MASTG-DEMO-0011.md
index d62b171761b..9edc08a2441 100644
--- a/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0011/MASTG-DEMO-0011.md
+++ b/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0011/MASTG-DEMO-0011.md
@@ -1,6 +1,6 @@
 ---
 platform: ios
-title: Uses of Weak Key Size in SecKeyCreateRandomKey with r2
+title: Uses of Insufficient Key Size in SecKeyCreateRandomKey with r2
 code: [swift]
 id: MASTG-DEMO-0011
 test: MASTG-TEST-0209
@@ -37,4 +37,4 @@ In the output we can see how the `kSecAttrKeySizeInBits` attribute is set to `10
 
 {{ evaluation.txt }}
 
-The test fails because the key size is set to `1024` bits, which is considered weak for RSA encryption. The key size should be increased to `2048` bits or higher to provide adequate security against modern cryptographic attacks.
+The test fails because the key size is set to `1024` bits, which is considered insufficient for RSA encryption. The key size should be increased to `2048` bits or higher to provide adequate security against modern cryptographic attacks.
diff --git a/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0015/MASTG-DEMO-0015.md b/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0015/MASTG-DEMO-0015.md
index bdbcd9f5fa4..3ba9ca6b40e 100644
--- a/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0015/MASTG-DEMO-0015.md
+++ b/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0015/MASTG-DEMO-0015.md
@@ -1,6 +1,6 @@
 ---
 platform: ios
-title: Uses of Insecure Hashing Algorithms in CommonCrypto with r2
+title: Uses of Risky or Broken Hashing Algorithms in CommonCrypto with r2
 code: [swift]
 id: MASTG-DEMO-0015
 test: MASTG-TEST-0211
diff --git a/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0016/MASTG-DEMO-0016.md b/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0016/MASTG-DEMO-0016.md
index fb807c9663d..1ea6e84e52d 100644
--- a/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0016/MASTG-DEMO-0016.md
+++ b/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0016/MASTG-DEMO-0016.md
@@ -1,6 +1,6 @@
 ---
 platform: ios
-title: Uses of Insecure Hashing Algorithms in CryptoKit with r2
+title: Uses of Risky or Broken Hashing Algorithms in CryptoKit with r2
 code: [swift]
 id: MASTG-DEMO-0016
 test: MASTG-TEST-0211
diff --git a/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0018/MASTG-DEMO-0018.md b/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0018/MASTG-DEMO-0018.md
index 20d29cb3486..6f2d44dc3c7 100644
--- a/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0018/MASTG-DEMO-0018.md
+++ b/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0018/MASTG-DEMO-0018.md
@@ -1,6 +1,6 @@
 ---
 platform: ios
-title: Uses of Insecure Encryption Algorithms in CommonCrypto with r2
+title: Uses of Deprecated, Risky or Broken Encryption Algorithms in CommonCrypto with r2
 code: [swift]
 id: MASTG-DEMO-0018
 test: MASTG-TEST-0210
diff --git a/rules/mastg-android-weak-key-generation.yml b/rules/mastg-android-key-generation-with-insufficient-key-length.yml
similarity index 95%
rename from rules/mastg-android-weak-key-generation.yml
rename to rules/mastg-android-key-generation-with-insufficient-key-length.yml
index 4b2e42c7bd6..3a71b4e3520 100644
--- a/rules/mastg-android-weak-key-generation.yml
+++ b/rules/mastg-android-key-generation-with-insufficient-key-length.yml
@@ -1,5 +1,5 @@
 rules:
-  - id: weak_key_size
+  - id: insufficient_key_size
     severity: WARNING
     languages:
       - java
diff --git a/rules/mastg-android-weak-encryption-algorithms.yaml b/rules/mastg-android-risky-encryption-algorithms.yaml
similarity index 90%
rename from rules/mastg-android-weak-encryption-algorithms.yaml
rename to rules/mastg-android-risky-encryption-algorithms.yaml
index 1cfa98e6862..10f93230130 100644
--- a/rules/mastg-android-weak-encryption-algorithms.yaml
+++ b/rules/mastg-android-risky-encryption-algorithms.yaml
@@ -1,5 +1,5 @@
 rules:
-  - id: weak-encryption-algorithms
+  - id: risky-encryption-algorithms
     languages:
       - java
     severity: WARNING
diff --git a/rules/mastg-android-weak-encryption-modes.yaml b/rules/mastg-android-risky-encryption-modes.yaml
similarity index 92%
rename from rules/mastg-android-weak-encryption-modes.yaml
rename to rules/mastg-android-risky-encryption-modes.yaml
index d7c913c38f6..2e710ee21d6 100644
--- a/rules/mastg-android-weak-encryption-modes.yaml
+++ b/rules/mastg-android-risky-encryption-modes.yaml
@@ -1,5 +1,5 @@
 rules:
-  - id: weak-encryption-modes
+  - id: risky-encryption-modes
     languages:
       - java
     severity: WARNING

From 83b5bbf016522135483c1be2e580916d35f2d9da Mon Sep 17 00:00:00 2001
From: Johan Sydseter <johan.sydseter@admincontrol.com>
Date: Wed, 12 Mar 2025 02:46:22 +0100
Subject: [PATCH 055/117] Align the tests with the wording used elsewhere.

---
 demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt
index f7153463a5e..0f90a152df3 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt
@@ -16,7 +16,7 @@ class MastgTest(private val context: Context) {
     // Vulnerable encryption using DES (broken algorithm)
     fun vulnerableDesEncryption(data: String): String {
         try {
-            // Weak key for DES
+            // insufficient key for DES
             val keyBytes = ByteArray(8)
             SecureRandom().nextBytes(keyBytes)
             val keySpec = DESKeySpec(keyBytes)
@@ -75,7 +75,7 @@ class MastgTest(private val context: Context) {
     // Risky encryption using Blowfish (weak algorithm)
     fun vulnerableBlowfishEncryption(data: String): String {
         return try {
-            // Weak key for Blowfish (risky, small key size)
+            // insufficient key for Blowfish (risky, small key size)
             val keyBytes = ByteArray(8) // Only 8 bytes (64-bit key) - not secure
             SecureRandom().nextBytes(keyBytes)
             val secretKey: SecretKey = SecretKeySpec(keyBytes, "Blowfish")

From f2c0c6e51ef1e5e19af6b872890cfa9c0b36df52 Mon Sep 17 00:00:00 2001
From: Johan Sydseter <johan.sydseter@admincontrol.com>
Date: Wed, 12 Mar 2025 03:34:46 +0100
Subject: [PATCH 056/117] Add glossary.

---
 Document/0x08c-Glossary.md | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 Document/0x08c-Glossary.md

diff --git a/Document/0x08c-Glossary.md b/Document/0x08c-Glossary.md
new file mode 100644
index 00000000000..952304b4205
--- /dev/null
+++ b/Document/0x08c-Glossary.md
@@ -0,0 +1,34 @@
+---
+hide: toc
+title: Glossary
+---
+
+## Terms
+
+### Broken
+
+The meaning depends on the context. 
+
+A "broken" cryptographic hash algorithm is a function that is denounced as "broken" because a collision attack exist that is faster to execute then a birthday attack ([Wikipedia, "2025.02.19"](https://en.wikipedia.org/wiki/Collision_attack "Collision attack")).
+
+An encryption mode of operation is "broken" if it, when implemented correctly, still faces the risk from known attacks that can "break" the confidentiality of the encrypted data.
+
+### Deprecated
+
+When mentioned as a cryptographic term it means a mode of operation, algorithm or cryptographic function that no longer is recommended to be used for certain cryptographic operations. The function may still be recommended for certain cryptographic operations even when deprecated.
+
+### Improper
+
+Used as a catch-all term to cover security behaviors that are either "Missing" or "Insufficient/Incorrect."
+
+### Insufficient
+
+According to MITRE. A general term used to describe when a security property or behavior can vary in strength on a continuous or sliding scale, instead of a discrete scale. The continuous scale may vary depending on the context and risk tolerance. For example, the requirements for randomness may vary between a random selection for a greeting message versus the generation of a military-strength key. On the other hand, a weakness that allows a buffer overflow is always incorrect - there is not a sliding scale that varies across contexts ([MITRE, "2024.07.07"](https://cwe.mitre.org/documents/glossary/index.html#Insufficient "Glossary")).
+
+### Risky
+
+A "risky" cryptographic hash algorithm is an algorithm without any known attacks, but that is insufficient when used under certain circumstances and therefor cary with it the risk of being compromised by an attack when used in the wrong context or for wrong purposes. The same would be the case for an encryption mode of operation.
+
+### Cryptographic strength
+
+According to NIST. A number associated with the amount of work (that is, the number of operations) that is required to break a cryptographic algorithm or system. If 2N execution operations of the algorithm (or system) are required to break the cryptographic algorithm, then the security strength is N bits ([NIST, security strength](https://csrc.nist.gov/glossary/term/security_strength "security strength")).

From 0bff5047641bd871521a3923df580a9e18283021 Mon Sep 17 00:00:00 2001
From: Johan Sydseter <johan.sydseter@admincontrol.com>
Date: Wed, 12 Mar 2025 03:35:58 +0100
Subject: [PATCH 057/117] clarify term

---
 Document/0x08c-Glossary.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x08c-Glossary.md b/Document/0x08c-Glossary.md
index 952304b4205..434fc8282fc 100644
--- a/Document/0x08c-Glossary.md
+++ b/Document/0x08c-Glossary.md
@@ -27,7 +27,7 @@ According to MITRE. A general term used to describe when a security property or
 
 ### Risky
 
-A "risky" cryptographic hash algorithm is an algorithm without any known attacks, but that is insufficient when used under certain circumstances and therefor cary with it the risk of being compromised by an attack when used in the wrong context or for wrong purposes. The same would be the case for an encryption mode of operation.
+A "risky" cryptographic hash algorithm is an algorithm without any known attacks, but that is insufficient when used under certain circumstances and therefor cary with it the risk of being compromised by an attack when used in the wrong context or for wrong purposes. The same can be considered for a "risky" encryption mode of operation.
 
 ### Cryptographic strength
 

From 53ba03be7fe9a3e533dc69271c5ae7ac9e6972f6 Mon Sep 17 00:00:00 2001
From: Johan Sydseter <johan.sydseter@admincontrol.com>
Date: Wed, 12 Mar 2025 03:37:03 +0100
Subject: [PATCH 058/117] Create subsections for Glossary.

---
 Document/0x08c-Glossary.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Document/0x08c-Glossary.md b/Document/0x08c-Glossary.md
index 434fc8282fc..892cce85838 100644
--- a/Document/0x08c-Glossary.md
+++ b/Document/0x08c-Glossary.md
@@ -3,7 +3,7 @@ hide: toc
 title: Glossary
 ---
 
-## Terms
+## Cryptographic Terms
 
 ### Broken
 
@@ -29,6 +29,6 @@ According to MITRE. A general term used to describe when a security property or
 
 A "risky" cryptographic hash algorithm is an algorithm without any known attacks, but that is insufficient when used under certain circumstances and therefor cary with it the risk of being compromised by an attack when used in the wrong context or for wrong purposes. The same can be considered for a "risky" encryption mode of operation.
 
-### Cryptographic strength
+### Strength
 
 According to NIST. A number associated with the amount of work (that is, the number of operations) that is required to break a cryptographic algorithm or system. If 2N execution operations of the algorithm (or system) are required to break the cryptographic algorithm, then the security strength is N bits ([NIST, security strength](https://csrc.nist.gov/glossary/term/security_strength "security strength")).

From b7f8fc6b328a02b462135d0516bc139748c2d1ac Mon Sep 17 00:00:00 2001
From: Johan Sydseter <johan.sydseter@admincontrol.com>
Date: Wed, 12 Mar 2025 03:39:05 +0100
Subject: [PATCH 059/117] Correct spelling erros

---
 Document/0x08c-Glossary.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Document/0x08c-Glossary.md b/Document/0x08c-Glossary.md
index 892cce85838..2fbc785cc57 100644
--- a/Document/0x08c-Glossary.md
+++ b/Document/0x08c-Glossary.md
@@ -7,7 +7,7 @@ title: Glossary
 
 ### Broken
 
-The meaning depends on the context. 
+The meaning depends on the context.
 
 A "broken" cryptographic hash algorithm is a function that is denounced as "broken" because a collision attack exist that is faster to execute then a birthday attack ([Wikipedia, "2025.02.19"](https://en.wikipedia.org/wiki/Collision_attack "Collision attack")).
 
@@ -27,7 +27,7 @@ According to MITRE. A general term used to describe when a security property or
 
 ### Risky
 
-A "risky" cryptographic hash algorithm is an algorithm without any known attacks, but that is insufficient when used under certain circumstances and therefor cary with it the risk of being compromised by an attack when used in the wrong context or for wrong purposes. The same can be considered for a "risky" encryption mode of operation.
+A "risky" cryptographic hash algorithm is an algorithm without any known attacks, but that is insufficient when used under certain circumstances and because of that cary with it the risk of being compromised by an attack when used in the wrong context or for wrong purposes. The same can be considered for a "risky" encryption mode of operation.
 
 ### Strength
 

From 5aa26990bad644041e90be05c688ecbf3908d71e Mon Sep 17 00:00:00 2001
From: Johan Sydseter <johan.sydseter@admincontrol.com>
Date: Wed, 12 Mar 2025 03:43:20 +0100
Subject: [PATCH 060/117] Correct link

---
 Document/0x05e-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x05e-Testing-Cryptography.md b/Document/0x05e-Testing-Cryptography.md
index 361f0668be9..59022292b60 100644
--- a/Document/0x05e-Testing-Cryptography.md
+++ b/Document/0x05e-Testing-Cryptography.md
@@ -103,7 +103,7 @@ Keeping up-to-date and patched component is one of security principles. The same
 
 #### Older Android versions
 
-For some applications that support older versions of Android (e.g.: only used versions lower than Android 7.0 (API level 24)), bundling an up-to-date library may be the only option. Conscrypt library is a good choice in this situation to keep the cryptography consistent across the different API levels and avoid having to import [Bouncy Castle](https://www.bouncycastle.org/java.html "Bouncy Castle in Java") which is a heavier library.
+For some applications that support older versions of Android (e.g.: only used versions lower than Android 7.0 (API level 24)), bundling an up-to-date library may be the only option. Conscrypt library is a good choice in this situation to keep the cryptography consistent across the different API levels and avoid having to import [Bouncy Castle](https://www.bouncycastle.org/download/bouncy-castle-java/ "Bouncy Castle in Java") which is a heavier library.
 
 [Conscrypt for Android](https://github.com/google/conscrypt#android "Conscrypt - A Java Security Provider") can be imported this way:
 

From 3761c04f7b855af572979076f2e42990adc4258c Mon Sep 17 00:00:00 2001
From: Johan Sydseter <johan.sydseter@admincontrol.com>
Date: Wed, 12 Mar 2025 03:43:56 +0100
Subject: [PATCH 061/117] Change link

---
 Document/0x05e-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x05e-Testing-Cryptography.md b/Document/0x05e-Testing-Cryptography.md
index 59022292b60..d1ab773c5cb 100644
--- a/Document/0x05e-Testing-Cryptography.md
+++ b/Document/0x05e-Testing-Cryptography.md
@@ -103,7 +103,7 @@ Keeping up-to-date and patched component is one of security principles. The same
 
 #### Older Android versions
 
-For some applications that support older versions of Android (e.g.: only used versions lower than Android 7.0 (API level 24)), bundling an up-to-date library may be the only option. Conscrypt library is a good choice in this situation to keep the cryptography consistent across the different API levels and avoid having to import [Bouncy Castle](https://www.bouncycastle.org/download/bouncy-castle-java/ "Bouncy Castle in Java") which is a heavier library.
+For some applications that support older versions of Android (e.g.: only used versions lower than Android 7.0 (API level 24)), bundling an up-to-date library may be the only option. Conscrypt library is a good choice in this situation to keep the cryptography consistent across the different API levels and avoid having to import [Bouncy Castle](https://www.bouncycastle.org/documentation/documentation-java/ "Bouncy Castle in Java") which is a heavier library.
 
 [Conscrypt for Android](https://github.com/google/conscrypt#android "Conscrypt - A Java Security Provider") can be imported this way:
 

From 73de8c2b1bef47053977bfd45042f5923c03bde0 Mon Sep 17 00:00:00 2001
From: Johan Sydseter <johan.sydseter@admincontrol.com>
Date: Thu, 13 Mar 2025 05:35:16 +0100
Subject: [PATCH 062/117] Fixed issues from the linter.

---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 weaknesses/MASVS-CRYPTO/MASWE-0010.md  | 4 ++--
 weaknesses/MASVS-CRYPTO/MASWE-0021.md  | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 8aaec5c712d..98145c5c3de 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -11,7 +11,7 @@ Cryptography plays an especially important role in securing the user's data - ev
 
 The goal of cryptography is to provide constant confidentiality, data integrity, and authenticity, even in the face of an attack. Confidentiality involves ensuring data privacy through the use of encryption. Data integrity deals with data consistency and detection of tampering and modification of data through the use of hashing. Authenticity ensures that the data comes from a trusted source.
 
-Encryption algorithms converts plaintext data into cipher text that conceals the original content. Plaintext data can be restored from the cipher text through decryption. Encryption can be **symmetric** (encryption/decryption with same secret-key) or **asymmetric** (encryption/decryption using a public and private key pair). Symmetric encryption operations do not protect integrity unless used together with a recommended and approved cipher mode that supports an authenticated encryption function with an appropriately random **IV** (Initialization vector) fulfilling the “uniqueness” requirement from "NIST 800-38D" ([NIST, 2007](https://csrc.nist.gov/pubs/sp/800/38/d/final "NIST: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC")).
+Encryption algorithms converts plaintext data into cipher text that conceals the original content. Plaintext data can be restored from the cipher text through decryption. Encryption can be **symmetric** (encryption/decryption with same secret-key) or **asymmetric** (encryption/decryption using a public and private key pair). Symmetric encryption operations do not protect integrity unless used together with a recommended and approved cipher mode that supports an authenticated encryption function with an appropriately random **IV** (Initialization vector) fulfilling the "uniqueness" requirement from "NIST 800-38D" ([NIST, 2007](https://csrc.nist.gov/pubs/sp/800/38/d/final "NIST: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC")).
 
 **Symmetric-key encryption algorithms** use the same key for both encryption and decryption. This type of encryption is fast and suitable for bulk data processing. Since everybody who has access to the key is able to decrypt the encrypted content, this method requires careful key management and centralized control over key distribution.
 
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
index 02cc34d9213..d6765995a7b 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
@@ -25,7 +25,7 @@ status: draft
 Improper Key derivation functions will generate a key using a scheme or iteration count that does not provide a sufficient level of computational effort. This can open up the possibility for brute force password/secret cracking or dictionary attacks.
 In cases where a user-supplied password or pin is used without a sufficiently random salt the resulting output will be identical or similar enough to allow an attacker to execute a brute force attack to find the original password/pin using the KDF as an "oracle".
 A similar issue happens when the salt is user-supplied. Consider a mobile app that generates user keys from a master key on demand during installation. Let's say that a key used in the mobile app is derived from this master key using the username or other user supplied value as salt. Such an implementation can make it possible for an attacker to retrieve the derived key by using the username or supplied user value as input.
-Another common issue is using HKDF or any other type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HKDF aren't design for low-entropy inputs. Therefore password crackers can fairly efficiently crack massive amounts of passwords for KDFs that aren’t purposefully designed to be slow and memory-intensive. A similar issue happens when using deprecated, risky or broken KDF- or password hashing algorithms known to the vulnerable for various types of attacks.
+Another common issue is using HKDF or any other type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HKDF aren't design for low-entropy inputs. Therefore password crackers can fairly efficiently crack massive amounts of passwords for KDFs that aren't purposefully designed to be slow and memory-intensive. A similar issue happens when using deprecated, risky or broken KDF- or password hashing algorithms known to the vulnerable for various types of attacks.
 Also, cryptographic algorithms (such as symmetric encryption or some MACs) expect a secret input of a given size. For example, AES uses a key of exactly 16 bytes. A native implementation might use the user-supplied password directly as an input key. Using a user-supplied password or pin as an input key has the following problems:
 
 - If the password is smaller than the key, the full key space isn't used. The remaining space is padded (spaces are sometimes used for padding).
@@ -34,7 +34,7 @@ Also, cryptographic algorithms (such as symmetric encryption or some MACs) expec
 ## Impact
 
 - **Risk of Brute-Force Attacks**: Improper Key derivation functions open up for brute force password- and secret cracking, key or dictionary attacks such as rainbow tables.
-- **Loss of  Confidentiality**: Improper Key derivation may allow an attacker to guess or find the input and therefore steal the user's password or cryptographic key.
+- **Loss of Confidentiality**: Improper Key derivation may allow an attacker to guess or find the input and therefore steal the user's password or cryptographic key.
 - **Loss of Integrity**: Given that the attacker has access to the user's password or cryptographic key, the overall security of the app and mobile phone may be compromised.
 
 ## Modes of Introduction
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0021.md b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
index 6eb4f28fe6f..b267b89fa02 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0021.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
@@ -36,8 +36,8 @@ Another common issue is using HKDF for key derivation with any type of integrity
 ## Impact
 
 - **Loss of Integrity and authenticity**: A deprecated, risky or broken hashing algorithm, may allow an attacker to compromise the integrity and authenticity of data at rest and in transit.
-- **Loss of Confidentiality**: A  deprecated, risky or broken hashing algorithm may expose the preimage (input) and in so doing break the confidentiality.
-- **Risk of Brute-Force Attacks**: A  deprecated, risky or broken hashing is susceptible to brute-force attacks.
+- **Loss of Confidentiality**: A deprecated, risky or broken hashing algorithm may expose the preimage (input) and in so doing break the confidentiality.
+- **Risk of Brute-Force Attacks**: A deprecated, risky or broken hashing is susceptible to brute-force attacks.
 
 ## Modes of Introduction
 

From 622f12bc265d76973bf91f74f84abe3c5e81ee06 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Tue, 18 Mar 2025 12:17:24 +0100
Subject: [PATCH 063/117] Fix linting

---
 weaknesses/MASVS-NETWORK/MASWE-0047.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/weaknesses/MASVS-NETWORK/MASWE-0047.md b/weaknesses/MASVS-NETWORK/MASWE-0047.md
index 9d78b75d575..453a593709e 100644
--- a/weaknesses/MASVS-NETWORK/MASWE-0047.md
+++ b/weaknesses/MASVS-NETWORK/MASWE-0047.md
@@ -15,7 +15,6 @@ status: new
 
 [Identity pinning (aka. certificate pinning, public key pinning or TLS pinning)](../../Document/0x04f-Testing-Network-Communication.md/#restricting-trust-identity-pinning) refers to associating a mobile app with a specific cryptographic identity, such as a certificate or public key to ensure that the app only communicates with trusted servers.
 
-
 When a mobile app does not implement certificate pinning, or if it is implemented incorrectly, the app remains vulnerable to [Machine-in-the-Middle (MITM)](../../Document/0x04f-Testing-Network-Communication.md#intercepting-network-traffic-through-mitm) attacks which enable attackers to intercept and modify the communication between the app and the intended server. This occurs because when the app is presented a fraudulent certificate that the app may unknowingly trust, thereby gaining access to sensitive data or injecting malicious content into the data stream.
 
 **Limitations**: Certificate pinning adds a layer of trust verification by ensuring that the app only accepts connections to servers with specific, pre-determined certificates or public keys. This reduces the risk of unauthorized interception, even if a trusted Certificate Authority (CA) is compromised. However, it is not foolproof:

From 8d6a31732507c4e47c905a2bfbc11bd753a13152 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Tue, 18 Mar 2025 12:27:39 +0100
Subject: [PATCH 064/117] Update risk and risky definition.

---
 Document/0x08c-Glossary.md | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Document/0x08c-Glossary.md b/Document/0x08c-Glossary.md
index 2fbc785cc57..3d27191efa1 100644
--- a/Document/0x08c-Glossary.md
+++ b/Document/0x08c-Glossary.md
@@ -25,9 +25,13 @@ Used as a catch-all term to cover security behaviors that are either "Missing" o
 
 According to MITRE. A general term used to describe when a security property or behavior can vary in strength on a continuous or sliding scale, instead of a discrete scale. The continuous scale may vary depending on the context and risk tolerance. For example, the requirements for randomness may vary between a random selection for a greeting message versus the generation of a military-strength key. On the other hand, a weakness that allows a buffer overflow is always incorrect - there is not a sliding scale that varies across contexts ([MITRE, "2024.07.07"](https://cwe.mitre.org/documents/glossary/index.html#Insufficient "Glossary")).
 
+### Risk
+
+Reference to risk uses the ISO 3000 defnition: Risk = "effect of uncertainty on objectives."
+
 ### Risky
 
-A "risky" cryptographic hash algorithm is an algorithm without any known attacks, but that is insufficient when used under certain circumstances and because of that cary with it the risk of being compromised by an attack when used in the wrong context or for wrong purposes. The same can be considered for a "risky" encryption mode of operation.
+A "risky" cryptographic hash algorithm that carries with it an effect of uncertainty on the objectives that the specific algorithm must satisfy. The algorithm may therefor be "risky" when used under certain circumstances, and because of that, cary with it the risk of being compromised in an attack when used improperly. The same can be considered when referring to a "risky" encryption mode of operation.
 
 ### Strength
 

From 4e7caae68b971e33073033bc805d3cade760d556 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Tue, 18 Mar 2025 12:28:22 +0100
Subject: [PATCH 065/117] correct grammer

---
 Document/0x08c-Glossary.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x08c-Glossary.md b/Document/0x08c-Glossary.md
index 3d27191efa1..be75b29ca45 100644
--- a/Document/0x08c-Glossary.md
+++ b/Document/0x08c-Glossary.md
@@ -31,7 +31,7 @@ Reference to risk uses the ISO 3000 defnition: Risk = "effect of uncertainty on
 
 ### Risky
 
-A "risky" cryptographic hash algorithm that carries with it an effect of uncertainty on the objectives that the specific algorithm must satisfy. The algorithm may therefor be "risky" when used under certain circumstances, and because of that, cary with it the risk of being compromised in an attack when used improperly. The same can be considered when referring to a "risky" encryption mode of operation.
+A "risky" cryptographic hash algorithm carries with it an effect of uncertainty on the objectives that the specific algorithm must satisfy. The algorithm may therefor be "risky" when used under certain circumstances, and because of that, cary with it the risk of being compromised in an attack when used improperly. The same can be considered when referring to a "risky" encryption mode of operation.
 
 ### Strength
 

From 6994a09a5bf7b8f85e03ad516aa360df25ac7f2c Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Tue, 18 Mar 2025 12:29:29 +0100
Subject: [PATCH 066/117] correct spelling error

---
 Document/0x08c-Glossary.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x08c-Glossary.md b/Document/0x08c-Glossary.md
index be75b29ca45..1d718288189 100644
--- a/Document/0x08c-Glossary.md
+++ b/Document/0x08c-Glossary.md
@@ -31,7 +31,7 @@ Reference to risk uses the ISO 3000 defnition: Risk = "effect of uncertainty on
 
 ### Risky
 
-A "risky" cryptographic hash algorithm carries with it an effect of uncertainty on the objectives that the specific algorithm must satisfy. The algorithm may therefor be "risky" when used under certain circumstances, and because of that, cary with it the risk of being compromised in an attack when used improperly. The same can be considered when referring to a "risky" encryption mode of operation.
+A "risky" cryptographic hash algorithm carries with it an effect of uncertainty on the objectives that the specific algorithm must satisfy. The algorithm is therefore "risky" when used under certain circumstances, and because of that, cary with it the risk of being compromised in an attack when used improperly. The same can be considered when referring to a "risky" encryption mode of operation.
 
 ### Strength
 

From e02f9f52dfbc32f813e31327518b83ccb2445bda Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Tue, 18 Mar 2025 12:30:34 +0100
Subject: [PATCH 067/117] correct spelling

---
 Document/0x08c-Glossary.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x08c-Glossary.md b/Document/0x08c-Glossary.md
index 1d718288189..a2ffb0044a5 100644
--- a/Document/0x08c-Glossary.md
+++ b/Document/0x08c-Glossary.md
@@ -31,7 +31,7 @@ Reference to risk uses the ISO 3000 defnition: Risk = "effect of uncertainty on
 
 ### Risky
 
-A "risky" cryptographic hash algorithm carries with it an effect of uncertainty on the objectives that the specific algorithm must satisfy. The algorithm is therefore "risky" when used under certain circumstances, and because of that, cary with it the risk of being compromised in an attack when used improperly. The same can be considered when referring to a "risky" encryption mode of operation.
+A "risky" cryptographic hash algorithm carries with it an effect of uncertainty on the objectives that the specific algorithm must satisfy. The algorithm is therefore "risky" when used under certain circumstances, and because of that, carries with it the risk of being compromised in an attack when used improperly. The same can be considered when referring to a "risky" encryption mode of operation.
 
 ### Strength
 

From 6d5d7d88f82b76605cfddccb915d62b312ae6f51 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Tue, 18 Mar 2025 12:31:59 +0100
Subject: [PATCH 068/117] tone change in the definition of risky

---
 Document/0x08c-Glossary.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x08c-Glossary.md b/Document/0x08c-Glossary.md
index a2ffb0044a5..49d55cb46c5 100644
--- a/Document/0x08c-Glossary.md
+++ b/Document/0x08c-Glossary.md
@@ -31,7 +31,7 @@ Reference to risk uses the ISO 3000 defnition: Risk = "effect of uncertainty on
 
 ### Risky
 
-A "risky" cryptographic hash algorithm carries with it an effect of uncertainty on the objectives that the specific algorithm must satisfy. The algorithm is therefore "risky" when used under certain circumstances, and because of that, carries with it the risk of being compromised in an attack when used improperly. The same can be considered when referring to a "risky" encryption mode of operation.
+A "risky" cryptographic hash algorithm carries with it an effect of uncertainty on the objectives that the specific algorithm must satisfy. The algorithm is therefore said to be "risky" when used under certain circumstances, and because of that, carries with it the risk of being compromised in an attack when used improperly. The same can be considered when referring to a "risky" encryption mode of operation.
 
 ### Strength
 

From b8e52257d651279c6aa22de92abf3aca74cf0da7 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Tue, 18 Mar 2025 12:36:29 +0100
Subject: [PATCH 069/117] spelling corrections

---
 Document/0x08c-Glossary.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x08c-Glossary.md b/Document/0x08c-Glossary.md
index 49d55cb46c5..92c00c6d5c5 100644
--- a/Document/0x08c-Glossary.md
+++ b/Document/0x08c-Glossary.md
@@ -27,7 +27,7 @@ According to MITRE. A general term used to describe when a security property or
 
 ### Risk
 
-Reference to risk uses the ISO 3000 defnition: Risk = "effect of uncertainty on objectives."
+Reference to risk uses the ISO 3000 definition: Risk = "effect of uncertainty on objectives."
 
 ### Risky
 

From cccdb725ecc1d4aa5b9f3f8ce8ea13b39d96ccd3 Mon Sep 17 00:00:00 2001
From: sydseter <johan.sydseter@admincontrol.com>
Date: Thu, 19 Jun 2025 15:15:24 +0200
Subject: [PATCH 070/117] Add two urls to the ignore config because the server
 suspect the url checker to be a bot and deny access

---
 .github/workflows/config/url-checker-config.json | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/.github/workflows/config/url-checker-config.json b/.github/workflows/config/url-checker-config.json
index 936d06b3dde..03b330d34c7 100644
--- a/.github/workflows/config/url-checker-config.json
+++ b/.github/workflows/config/url-checker-config.json
@@ -119,6 +119,12 @@
         },
         {
             "pattern": "^/checklists/"
+        },
+        {
+            "pattern": "https://techbeacon.com/evolution-devops-new-thinking-gene-kim"
+        },
+        {
+            "pattern": "https://research.checkpoint.com/2020/new-joker-variant-hits-google-play-with-an-old-trick/"
         }
         
     ],

From bbb7183a0d23bd2f68504cc449bcd776f79dcf57 Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Wed, 2 Jul 2025 07:26:22 +0200
Subject: [PATCH 071/117] Apply suggestions from code review

Co-authored-by: Jeroen Beckers <me.githbub@dauntless.be>
---
 tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md |  2 +-
 weaknesses/MASVS-CRYPTO/MASWE-0009.md          |  2 +-
 weaknesses/MASVS-CRYPTO/MASWE-0010.md          | 10 +++++-----
 weaknesses/MASVS-CRYPTO/MASWE-0021.md          | 12 ++++++------
 weaknesses/MASVS-CRYPTO/MASWE-0024.md          |  4 ++--
 weaknesses/MASVS-CRYPTO/MASWE-0025.md          |  8 ++++----
 6 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md b/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md
index bb7775e239f..8e884cbc1d4 100644
--- a/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md
+++ b/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md
@@ -45,7 +45,7 @@ The test case fails if you can find the use of "broken" hashing algorithms withi
 - MD5
 - SHA-1
 
-**Stay up-to-date**: This is a non-exhaustive list of weak, risky or broken algorithms. Make sure to check the latest standards and recommendations from organizations such as the National Institute of Standards and Technology (NIST), the German Federal Office for Information Security (BSI) or any other relevant authority in your region. When building an app that uses hashes that will be stored for a considerable long time. Make sure that you follow NIST recommendations about how to ["Transition to Post-Quantum Cryptography Standards"](https://csrc.nist.gov/pubs/ir/8547/ipd).
+**Stay up-to-date**: This is a non-exhaustive list of weak, risky or broken algorithms. Make sure to check the latest standards and recommendations from organizations such as the National Institute of Standards and Technology (NIST), the German Federal Office for Information Security (BSI) or any other relevant authority in your region. When building an app that uses hashes that will be stored for a considerable long time, be sure to follow NIST recommendations about how to ["Transition to Post-Quantum Cryptography Standards"](https://csrc.nist.gov/pubs/ir/8547/ipd).
 
 **Context Considerations**:
 
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0009.md b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
index bec8dfc7f8b..ffc30b5c2b1 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0009.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
@@ -24,7 +24,7 @@ status: new
 In cryptography, the security strength is heavily influenced by the methods used to generate cryptographic keys. One critical aspect is the key size, also known as the key length, which is measured in bits and must comply with the latest security best practices. Encryption algorithms that use insufficient key sizes are vulnerable to attack, while longer keys typically result in more complex encryption.
 
 However, even with an appropriately sized key, the security of the encryption can be compromised if the key generation process itself is flawed. For example using a pseudorandom number generator (PRNG) not meant for cryptographic purposes can undermine cryptographic security by generating predictable, weak or low-entropy keys. This reduces the effectiveness of the key length and makes it easier for attackers to guess or reproduce keys. Weak PRNG seeds can also produce repetitive patterns, leading to further vulnerabilities. Ensuring the use of strong, cryptographically secure PRNGs called CSPRNGs with high entropy seeding is essential for robust key security.
-The digest (or hash) of an improper implemented- or used hash function may allow and adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack).
+The digest (or hash) of an improper implemented or used hash function may allow an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack).
 
 ## Impact
 
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
index 9463e95159d..ab967ef4ad7 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
@@ -25,15 +25,15 @@ status: placeholder
 Improper Key derivation functions will generate a key using a scheme or iteration count that does not provide a sufficient level of computational effort. This can open up the possibility for brute force password/secret cracking or dictionary attacks.
 In cases where a user-supplied password or pin is used without a sufficiently random salt the resulting output will be identical or similar enough to allow an attacker to execute a brute force attack to find the original password/pin using the KDF as an "oracle".
 A similar issue happens when the salt is user-supplied. Consider a mobile app that generates user keys from a master key on demand during installation. Let's say that a key used in the mobile app is derived from this master key using the username or other user supplied value as salt. Such an implementation can make it possible for an attacker to retrieve the derived key by using the username or supplied user value as input.
-Another common issue is using HKDF or any other type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HKDF aren't design for low-entropy inputs. Therefore password crackers can fairly efficiently crack massive amounts of passwords for KDFs that aren't purposefully designed to be slow and memory-intensive. A similar issue happens when using deprecated, risky or broken KDF- or password hashing algorithms known to the vulnerable for various types of attacks.
-Also, cryptographic algorithms (such as symmetric encryption or some MACs) expect a secret input of a given size. For example, AES uses a key of exactly 16 bytes. A native implementation might use the user-supplied password directly as an input key. Using a user-supplied password or pin as an input key has the following problems:
+Another common issue is using HKDF or any other type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HKDFs aren't designed for low-entropy inputs. Therefore, password crackers can fairly efficiently crack massive amounts of passwords for KDFs that aren't purposefully designed to be slow and memory-intensive. A similar issue happens when using deprecated, risky or broken KDF- or password hashing algorithms known to the vulnerable to various types of attacks.
+Also, cryptographic algorithms (such as symmetric encryption or some MACs) expect a secret input of a given size. For example, AES uses a key of exactly 16 bytes. A naive implementation might use the user-supplied password directly as an input key. Using a user-supplied password or pin as an input key has the following problems:
 
-- If the password is smaller than the key, the full key space isn't used. The remaining space is padded (spaces are sometimes used for padding).
+- If the password is smaller than the key, the full key space isn't used. The remaining space is padded, often with spaces or null bytes.
 - A user-supplied password will realistically consist mostly of displayable and pronounceable characters. Therefore, only some of the possible 256 ASCII characters are used and entropy is decreased by approximately a factor of four.
 
 ## Impact
 
-- **Risk of Brute-Force Attacks**: Improper Key derivation functions open up for brute force password- and secret cracking, key or dictionary attacks such as rainbow tables.
+- **Risk of Brute-Force Attacks**: Improper Key derivation functions expose the app to brute force password- and secret cracking attacks, and key or dictionary attacks such as rainbow tables.
 - **Loss of Confidentiality**: Improper Key derivation may allow an attacker to guess or find the input and therefore steal the user's password or cryptographic key.
 - **Loss of Integrity**: Given that the attacker has access to the user's password or cryptographic key, the overall security of the app and mobile phone may be compromised.
 
@@ -41,7 +41,7 @@ Also, cryptographic algorithms (such as symmetric encryption or some MACs) expec
 
 - **Using static or predictable salt on low-entropy input**: Using user-supplied input together with a static or predictable salt makes it possible for the attacker to to pre-compute the hash value using dictionary attack, effectively disabling the protection that a salt would provide.
 - **Using user-supplied salt**: Using user-supplied salt will make it possible for an attacker to extract all derived keys through a KDF by supplying the user-supplied salt as an argument.
-- **Using non-resource intensive algorithms on low-entropy input**: Using user-supplied input together with HKDF makes it easy for password crackers to execute a preimage attack.
+- **Using non-resource intensive algorithms on low-entropy input**: Using user-supplied input together with a HKDF makes it easy for password crackers to execute a preimage attack.
 - **Use a hash function as a general-purpose KDF**: In scenarios where the information used during key derivation is attacker-controlled, using a integrity based hash function (e.g from the SHA family) as KDF can expose the application to brute force or length-extension attacks.
 - **Using Deprecated, Risky or Broken Algorithms**: Relying on deprecated, risky or inherently broken cryptographic algorithms can result in the generation of weaker keys. As these algorithms often have vulnerabilities or support shorter key lengths, they are more susceptible to modern attacks, compromising the overall security of the app.
 
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0021.md b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
index 1c4b95f06e3..d49e5266956 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0021.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
@@ -24,15 +24,15 @@ status: draft
 
 ---
 
-Choosing a deprecated, risky or broken hash algorithm, that is insufficiently collision resistant, may compromise the integrity and authenticity of data at rest and in transit by opening the application up for collision attacks.
+Choosing a deprecated, risky or broken hash algorithm, that is insufficiently collision resistant, may compromise the integrity and authenticity of data at rest and in transit by making the app vulnerable to collision attacks.
 
-when performing key derivation together with predictable input or in password hashing, the digest (or hash) of an improper implemented- or used hash function may allow and adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack/collision attack), given the actor can arbitrarily choose the inputs to be hashed and can do so a reasonable amount of times
+when performing key derivation together with predictable input or in password hashing, the digest (or hash) of an improper implemented or used hash function may allow an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (second preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack/collision attack), given the actor can arbitrarily choose the inputs to be hashed and can do so a reasonable amount of times.
 
 What is regarded as "reasonable" varies by context and threat model, but in general, "reasonable" could cover any attack that is more efficient than brute force (i.e., on average, attempting half of all possible combinations). Note that some attacks might be more efficient than brute force but are still not regarded as achievable in the real world.
 
-Any algorithm that does not meet the above conditions will generally be considered risky or to "weak" for general use in hashing. When a collision attack is discovered and is found to be faster than a birthday attack, a hash function is often denounced as "broken". This is the case for MD5 and SHA-1.
+Any algorithm that does not meet the above conditions will generally be considered risky or too "weak" for general use in hashing. When a collision attack is discovered and is found to be faster than a birthday attack, a hash function is often denounced as "broken". This is the case for MD5 and SHA-1.
 
-Another common issue is using HKDF for key derivation with any type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HKDF aren't design for low-entropy inputs. Doing so will result in producing "weak" hashes that easily can be broken.
+Another common issue is using a HKDF for key derivation with any type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HKDF aren't designed for low-entropy inputs. Doing so will result in producing "weak" hashes that easily can be broken.
 
 ## Impact
 
@@ -42,8 +42,8 @@ Another common issue is using HKDF for key derivation with any type of integrity
 
 ## Modes of Introduction
 
-- **using a deprecated, risky or broken hashing algorithm**: E.g: MD5 and SHA-1 has been identified to be vulnerable for collision attacks that are faster than a birthday attack. Meaning that they are denounced as "broken".
-- **Using a insufficiently collision resistant hash**: Choosing a a hashing algorithm of insufficient length may result in loss of integrity or confidentiality.
+- **using a deprecated, risky or broken hashing algorithm**: E.g: MD5 and SHA-1 have been identified to be vulnerable to collision attacks that are faster than a birthday attack. This means they are denounced as "broken".
+- **Using an insufficiently collision resistant hash**: Choosing a a hashing algorithm of insufficient length may result in loss of integrity or confidentiality.
 - **Using non-resource intensive algorithms on low-entropy input**: Using a integrity based hashing algorithm to hash low-entry input like pin numbers would make brute-force or dictionary attacks trivial.
 
 ## Mitigations
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
index 2a207492601..41863a0cce9 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
@@ -23,9 +23,9 @@ draft:
 status: draft
 
 ---
-Improper use of MAC by e.g by generating a MAC over a message without the timestamp can make the application susceptible for replay attacks.
+Improper use of a MAC by e.g., generating a MAC over a message without the timestamp can make the application susceptible for replay attacks.
 
-Another common issue is using HMAC with on low-entropy input with any type of general based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HMAC aren't designed for low-entropy inputs or low-entropy keys. Doing so will result in producing "weak" message digest that easily can be exploited.
+Another common issue is using an HMAC with any type of general based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HMAC aren't designed for low-entropy inputs or low-entropy keys. Doing so will result in producing "weak" message digests that easily can be exploited.
 
 A deprecated HMAC implementation may contain bugs that could compromise the authenticity of the data.
 
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0025.md b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
index 712385a0541..85a72146ac6 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0025.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
@@ -25,15 +25,15 @@ Using deprecated, risky or broken algorithms for the purpose of ensuring account
 ## Impact
 
 - **Loss of Integrity and authenticity**: Signature forgery may allow the attacker to compromise the integrity and authenticity of the data by signing the data on behalf of another entity.
-- **Loss of accountability**: Signature forgery opens up for deniability and reduces accountability.
+- **Loss of accountability**: Signature forgery allows for plausible deniability and diminishes accountability.
 
 ## Modes of Introduction
 
-- **Using a deprecated, risky or broken hashing algorithm**: e.g. MD5 and SHA-1 has been identified to be vulnerable for collision attacks that are faster than a birthday attack. Meaning that they are denounced as "broken".
-- **Using a insufficiently collision resistant hash**: Choosing a a hashing algorithm of insufficient length may result in loss of integrity or confidentiality.
+- **Using a deprecated, risky or broken hashing algorithm**: e.g. MD5 and SHA-1 have been identified to be vulnerable for collision attacks that are faster than a birthday attack. Because of this they are denounced as "broken".
+- **Using a insufficiently collision resistant hash**: Choosing a hashing algorithm of insufficient length may result in loss of integrity or confidentiality.
 
 ## Mitigations
 
 - **Choose collision resistant algorithm**: Choose a signature algorithm that is sufficiently collision resistant like RSA (3072 bits and higher), ECDSA with NIST P-384 or EdDSA with Edwards448.
 
-- **Choose an signing scheme that make use of algorithms with sufficient bit-lengths**: As our computers gets stronger, the hashes gets weaker, therefore, make sure that you can adjust the bit-length length (strength) of the algorithm of your choosing. When signatures are stored at rest, make sure to follow the software industry's long term recommendations (e.g. ["NIST: Transition to Post-Quantum Cryptography Standards"](https://csrc.nist.gov/pubs/ir/8547/ipd)).
+- **Choose a signing scheme that make use of algorithms with sufficient bit-lengths**: As our computers gets stronger, previously generated hashes get weaker, therefore, make sure that you can adjust the bit-length length (strength) of the algorithm of your choosing. When signatures are stored at rest, make sure to follow the software industry's long term recommendations (e.g. ["NIST: Transition to Post-Quantum Cryptography Standards"](https://csrc.nist.gov/pubs/ir/8547/ipd)).

From 6698e09e08604595cab602287ec14b15dda29a64 Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Wed, 2 Jul 2025 07:29:04 +0200
Subject: [PATCH 072/117] Apply suggestions from code review

Co-authored-by: Jeroen Beckers <me.githbub@dauntless.be>
---
 Document/0x05e-Testing-Cryptography.md         | 2 +-
 Document/0x08c-Glossary.md                     | 6 +++---
 tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0210.md | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Document/0x05e-Testing-Cryptography.md b/Document/0x05e-Testing-Cryptography.md
index 842e9a45206..88290bc5e56 100644
--- a/Document/0x05e-Testing-Cryptography.md
+++ b/Document/0x05e-Testing-Cryptography.md
@@ -103,7 +103,7 @@ Keeping up-to-date and patched component is one of security principles. The same
 
 #### Older Android versions
 
-For some applications that support older versions of Android (e.g.: only used versions lower than Android 7.0 (API level 24)), bundling an up-to-date library may be the only option. Conscrypt library is a good choice in this situation to keep the cryptography consistent across the different API levels and avoid having to import [Bouncy Castle](https://www.bouncycastle.org/documentation/documentation-java/ "Bouncy Castle in Java") which is a heavier library.
+For some applications that support older versions of Android (e.g., only used on versions lower than Android 7.0 (API level 24)), bundling an up-to-date library may be the only option. Conscrypt library is a good choice in this situation to keep the cryptography consistent across the different API levels and avoid having to import [Bouncy Castle](https://www.bouncycastle.org/documentation/documentation-java/ "Bouncy Castle in Java") which is a heavier library.
 
 [Conscrypt for Android](https://github.com/google/conscrypt#android "Conscrypt - A Java Security Provider") can be imported this way:
 
diff --git a/Document/0x08c-Glossary.md b/Document/0x08c-Glossary.md
index 92c00c6d5c5..724f5d55c0c 100644
--- a/Document/0x08c-Glossary.md
+++ b/Document/0x08c-Glossary.md
@@ -15,15 +15,15 @@ An encryption mode of operation is "broken" if it, when implemented correctly, s
 
 ### Deprecated
 
-When mentioned as a cryptographic term it means a mode of operation, algorithm or cryptographic function that no longer is recommended to be used for certain cryptographic operations. The function may still be recommended for certain cryptographic operations even when deprecated.
+When mentioned as a cryptographic term it means a mode of operation, algorithm or cryptographic function that no longer is recommended to be used for certain cryptographic operations. The function may still be recommended for specific other cryptographic operations even when deprecated.
 
 ### Improper
 
-Used as a catch-all term to cover security behaviors that are either "Missing" or "Insufficient/Incorrect."
+Used as a catch-all term to cover security behaviors that are either "Missing" or "Insufficient/Incorrect".
 
 ### Insufficient
 
-According to MITRE. A general term used to describe when a security property or behavior can vary in strength on a continuous or sliding scale, instead of a discrete scale. The continuous scale may vary depending on the context and risk tolerance. For example, the requirements for randomness may vary between a random selection for a greeting message versus the generation of a military-strength key. On the other hand, a weakness that allows a buffer overflow is always incorrect - there is not a sliding scale that varies across contexts ([MITRE, "2024.07.07"](https://cwe.mitre.org/documents/glossary/index.html#Insufficient "Glossary")).
+According to MITRE: _A general term used to describe when a security property or behavior can vary in strength on a continuous or sliding scale, instead of a discrete scale. The continuous scale may vary depending on the context and risk tolerance. For example, the requirements for randomness may vary between a random selection for a greeting message versus the generation of a military-strength key. On the other hand, a weakness that allows a buffer overflow is always incorrect - there is not a sliding scale that varies across contexts_ ([MITRE, "2024.07.07"](https://cwe.mitre.org/documents/glossary/index.html#Insufficient "Glossary")).
 
 ### Risk
 
diff --git a/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0210.md b/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0210.md
index c4e1c82a430..d48b7b1ddc5 100644
--- a/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0210.md
+++ b/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0210.md
@@ -44,7 +44,7 @@ The test case fails if you can find the use of encryption algorithms within the
 
 **Stay up-to-date**: This is a non-exhaustive list of deprecated, risky and broken algorithms. Make sure to check the latest standards and recommendations from organizations such as the National Institute of Standards and Technology (NIST), the German Federal Office for Information Security (BSI) or any other relevant authority in your region.
 
-Some algorithms may not be considered to have insufficient strength, but may have **inappropriate configurations** that should be avoided. Such as using a seed or IV not generated by Cryptographically secure PRNGs (CSPRNG) or not being considered quantum-safe. For example, an AES 128-bit key size is considered insufficient considering quantum computing attacks. When building an app that uses data that will be stored for a considerable long time. Make sure that you follow NIST recommendations about how to ["Transition to Post-Quantum Cryptography Standards"](https://csrc.nist.gov/pubs/ir/8547/ipd).
+Some algorithms may not be considered to have insufficient strength, but may have **inappropriate configurations** that should be avoided. Such as using a seed or IV not generated by Cryptographically secure PRNGs (CSPRNG) or not being considered quantum-safe. For example, an AES 128-bit key size is considered insufficient considering quantum computing attacks. When building an app that uses data that will be stored for a considerable long time. Make sure that you follow NIST recommendations on how to ["Transition to Post-Quantum Cryptography Standards"](https://csrc.nist.gov/pubs/ir/8547/ipd).
 
 **Context Considerations**:
 

From dab97dafcfd73019632142067cc423beb9de67e4 Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Wed, 2 Jul 2025 07:58:46 +0200
Subject: [PATCH 073/117] Apply suggestions from code review

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
---
 Document/0x04g-Testing-Cryptography.md        | 31 +++++++++++--------
 .../MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt |  2 +-
 weaknesses/MASVS-CRYPTO/MASWE-0009.md         |  2 +-
 weaknesses/MASVS-CRYPTO/MASWE-0024.md         |  4 +--
 weaknesses/MASVS-CRYPTO/MASWE-0025.md         |  2 +-
 5 files changed, 23 insertions(+), 18 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 98145c5c3de..4a2cfefb387 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -11,13 +11,13 @@ Cryptography plays an especially important role in securing the user's data - ev
 
 The goal of cryptography is to provide constant confidentiality, data integrity, and authenticity, even in the face of an attack. Confidentiality involves ensuring data privacy through the use of encryption. Data integrity deals with data consistency and detection of tampering and modification of data through the use of hashing. Authenticity ensures that the data comes from a trusted source.
 
-Encryption algorithms converts plaintext data into cipher text that conceals the original content. Plaintext data can be restored from the cipher text through decryption. Encryption can be **symmetric** (encryption/decryption with same secret-key) or **asymmetric** (encryption/decryption using a public and private key pair). Symmetric encryption operations do not protect integrity unless used together with a recommended and approved cipher mode that supports an authenticated encryption function with an appropriately random **IV** (Initialization vector) fulfilling the "uniqueness" requirement from "NIST 800-38D" ([NIST, 2007](https://csrc.nist.gov/pubs/sp/800/38/d/final "NIST: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC")).
+An encryption algorithm converts plaintext data into ciphertext, which conceals the original content. The plaintext data can be restored from the ciphertext through decryption. There are two types of encryption: **symmetric** (encryption and decryption use the same secret key) and **asymmetric** (encryption and decryption use a public and private key pair). Symmetric encryption operations do not protect data integrity unless they are used with an approved cipher mode that supports authenticated encryption with a random initialization vector (IV) that fulfills the "uniqueness" requirement [NIST SP 800-38D - "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", 2007](https://csrc.nist.gov/pubs/sp/800/38/d/final).
 
 **Symmetric-key encryption algorithms** use the same key for both encryption and decryption. This type of encryption is fast and suitable for bulk data processing. Since everybody who has access to the key is able to decrypt the encrypted content, this method requires careful key management and centralized control over key distribution.
 
 **Public-key encryption algorithms** operate with two separate keys: the public key and the private key. The public key can be distributed freely while the private key shouldn't be shared with anyone. A message encrypted with the public key can only be decrypted with the private key and vice-versa. Since asymmetric encryption is several times slower than symmetric operations, it's typically only used to encrypt small amounts of data, such as symmetric keys for bulk encryption.
 
-**Hashing** isn't a form of encryption, but it does use cryptography. Hash functions deterministically map arbitrary pieces of data into fixed-length values. It's easy to compute the hash from the input, but very difficult (i.e. infeasible) to determine the original input from the hash. Additionally, the hash will completely change when even a single bit of the input changes. Hash functions are used for password storage, integrity verification (e.g. digital signatures or document management) or file management. Hash functions don't provide an authenticity guarantee, but can be combined as cryptographic primitives to do so.
+**Hashing** isn't a form of encryption, but it does use cryptography. Hash functions map arbitrary pieces of data into fixed-length values in a deterministic way. While it's easy to compute the hash from the input, it's very difficult (i.e., infeasible) to determine the original input from the hash. Additionally, the hash changes completely when even a single bit of the input changes. Hash functions are used for storing passwords, verifying integrity (e.g., digital signatures or document management), and managing files. Although hash functions don't provide an authenticity guarantee, they can be combined as cryptographic primitives to do so.
 
 **Message Authentication Codes** (MACs) combine other cryptographic mechanisms (such as symmetric encryption or hashes) with secret keys to provide both integrity and authenticity protection. However, in order to verify a MAC, multiple entities have to share the same secret key and any of those entities can generate a valid MAC. HMACs, the most commonly used type of MAC, rely on hashing as the underlying cryptographic primitive. The full name of an HMAC algorithm usually includes the underlying hash function's type (for example, HMAC-SHA256 uses the SHA-256 hash function).
 
@@ -46,8 +46,8 @@ The names of cryptographic APIs depend on the particular mobile platform.
 Please make sure that:
 
 - Cryptographic algorithms are up to date and in-line with industry standards. This includes, but is not limited to outdated block ciphers (e.g. DES), stream ciphers (e.g. RC4), as well as hash functions (e.g. MD5) and broken random number generators like Dual_EC_DRBG (even if they are NIST certified). All of these should be marked as insecure and should not be used and removed from the application and server.
-- Key lengths are in-line with industry standards and provide protection for sufficient amount of time. A comparison of different key lengths and the protection they provide, taking into account Moore's law, is available [online](https://www.keylength.com/ "Keylength comparison").
-- Through NIST SP 800-131A on "Transitioning the Use of Cryptographic Algorithms and Key Lengths" [(NIST, 2024)](https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd "NIST: Transitioning the Use of Cryptographic Algorithms and Key Lengths"), NIST provides recommendations and guidance on how to align with future recommendations and how to transition to stronger cryptographic keys and more robust algorithms.
+- Key lengths are in line with industry standards and provide sufficient protection over a long period of time. A comparison of different key lengths and the protection they provide, taking Moore's Law into account, is available [online](https://www.keylength.com/ "Keylength comparison").
+- Through [NIST SP 800-131A - "Transitioning the Use of Cryptographic Algorithms and Key Lengths", 2024](https://csrc.nist.gov/pubs/sp/800/131/a/r3/ipd), NIST provides recommendations and guidance on aligning with future recommendations and transitioning to stronger cryptographic keys and more robust algorithms.
 - Cryptographic means are not mixed with each other: e.g. you do not sign with a public key, or try to reuse a key pair used for a signature to do encryption.
 - Cryptographic parameters are well defined within reasonable range. This includes, but is not limited to: cryptographic salt, which should be at least the same length as hash function output, reasonable choice of password derivation function and iteration count (e.g. PBKDF2, scrypt or bcrypt), IVs being random and unique, fit-for-purpose block encryption modes (e.g. ECB should not be used, except specific cases), key management being done properly (e.g. 3DES should have three independent keys) and so on.
 
@@ -58,7 +58,7 @@ Recommended algorithms:
 - Digital signature algorithms: RSA (3072 bits and higher), ECDSA with NIST P-384 or EdDSA with Edwards448.
 - Key establishment algorithms: RSA (3072 bits and higher), DH (3072 bits or higher), ECDH with NIST P-384
 
-**Please note:** The Recommendations are based on current industry perception regarding what is considered to be appropriate and are in line with NIST recommendations beyond 2030, but does not necessarily take into account quantum computing advancements. For advice on post-quantum, please see **Post-Quantum** below.
+**Please note:** The recommendations are based on the current industry perception of what is considered appropriate. They align with NIST recommendations beyond 2030 but do not necessarily take into account advancements in quantum computing. For advice on post-quantum cryptography, please see the ["Post-Quantum"](#post-quantum) section below.
 
 Additionally, you should always rely on secure hardware (if available) for storing encryption keys, performing cryptographic operations, etc.
 
@@ -67,20 +67,25 @@ For more information on algorithm choice and best practices, see the following r
 - ["Commercial National Security Algorithm Suite and Quantum Computing FAQ"](https://web.archive.org/web/20250305234320/https://cryptome.org/2016/01/CNSA-Suite-and-Quantum-Computing-FAQ.pdf "Commercial National Security Algorithm Suite and Quantum Computing FAQ")
 - [NIST recommendations (2019)](https://www.keylength.com/en/4/ "NIST recommendations")
 - [BSI recommendations (2019)](https://www.keylength.com/en/8/ "BSI recommendations")
-- NIST advises using RSA-based key-transport schemes with a minimum modulus length of at least 2048 bits according to 800-56B Rev. 2 ([NIST, 2019](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final "NIST: Recommendation for Pair-Wise Key-Establishment Using Integer Factorization Cryptography"))
-- NIST advises using ECC-based key-agreement schemes, such as Elliptic Curve Diffie-Hellman (ECDH), utilizing curves between P-224 to P-521 according to 800-56A Rev. 3 ([NIST, 2018](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final "NIST: Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography")).
-- RSA, ECDSA and EdDSA are approved techniques by NIST for digital signature generation according to "FIPS 186-5" ([NIST, 2023](https://csrc.nist.gov/pubs/fips/186-5/final "NIST: Digital Signature Standard (DSS)")). Keep in mind that DSA only shall be used to verify previously generated digital signatures.
-- Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters, NIST SP 800-186 [(NIST, 2023)(https://csrc.nist.gov/pubs/sp/800/186/final "NIST: Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters")]
+- [NIST SP 800-56B Revision 2 - "Recommendation for Pair-Wise Key-Establishment Using Integer Factorization Cryptography", 2019](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final): NIST advises using RSA-based key-transport schemes with a minimum modulus length of at least 2048 bits.
+- [NIST SP 800-56A Revision 3 - "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography", 2018](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final): NIST advises using ECC-based key-agreement schemes, such as Elliptic Curve Diffie-Hellman (ECDH), utilizing curves from P-224 to P-521.
+- [FIPS 186-5 - "Digital Signature Standard (DSS)", 2023](https://csrc.nist.gov/pubs/fips/186-5/final): NIST approves RSA, ECDSA, and EdDSA for digital signature generation. DSA should only be used to verify previously generated signatures.
+- [NIST SP 800-186 - "Recommendations for Discrete Logarithm-Based Cryptography: Elliptic Curve Domain Parameters", 2023](https://csrc.nist.gov/pubs/sp/800/186/final): Provides recommendations for elliptic curve domain parameters used in discrete logarithm-based cryptography.
 
 ## Post-Quantum
 
 ### Public-key encryption algorithms
 
-NIST has approved CRYSTALS-Kyber as a post-quantum key encapsulation mechanism (KEM) to establish a shared secret key over a public channel. The secret can then be used with symmetric-key cryptographic algorithms to perform encryption and decryption. This according to FIPS 203 ([NIST, 2024](https://csrc.nist.gov/pubs/fips/203/final "NIST: Module-Lattice-Based Key-Encapsulation Mechanism Standard")).
+In 2024, NIST approved CRYSTALS-Kyber as a post-quantum key encapsulation mechanism (KEM) for establishing a shared secret over a public channel. This shared secret can then be used with symmetric-key algorithms for encryption and decryption.
+
+- [FIPS 203 - "Module-Lattice-Based Key-Encapsulation Mechanism Standard", 2024](https://csrc.nist.gov/pubs/fips/203/final): Specifies CRYSTALS-Kyber as the standard for post-quantum key encapsulation.
 
 ## Signatures
 
-NIST has approved [SLH-DSA](https://csrc.nist.gov/pubs/fips/205/final "NIST: Stateless Hash-Based Digital Signature Standard") (NIST, 2024) and [ML-DSA](https://csrc.nist.gov/pubs/fips/204/final "NIST: Module-Lattice-Based Digital Signature Standard") (NIST, 2024) as recommended digital signature algorithm to be used for post-quatum signature generation and verification.
+In 2024, NIST approved SLH-DSA and ML-DSA as recommended digital signature algorithms for post-quantum signature generation and verification.
+
+- [FIPS 205 - "Stateless Hash-Based Digital Signature Standard", 2024](https://csrc.nist.gov/pubs/fips/205/final): Specifies SLH-DSA for post-quantum digital signatures.
+- [FIPS 204 - "Module-Lattice-Based Digital Signature Standard", 2024](https://csrc.nist.gov/pubs/fips/204/final): Specifies ML-DSA for post-quantum digital signatures.
 
 ## Common Configuration Issues
 
@@ -113,8 +118,8 @@ Secret keys must be stored in secure device storage whenever symmetric cryptogra
 
 ### Improper Key Derivation Functions
 
-When talking about key derivation functions KDF in the context of mobile application we are usually referring to cryptographic key derivation and not password storage. This chapter mainly focus on KDF in the context of cryptographic key derivation and not KDF in the context of password storage. For general advice on password storage, please read the [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html).
-Key derivation functions derive bytes suitable for cryptographic operations from passwords or other data sources using a pseudo-random function (PRF)
+When discussing key derivation functions (KDFs) in the context of mobile applications, we are usually referring to cryptographic key derivation rather than password storage. This chapter focuses primarily on KDF in the context of cryptographic key derivation, rather than password storage. For general advice on password storage, please refer to the [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html).
+KDFs derive bytes suitable for cryptographic operations from passwords or other data sources using a pseudorandom function (PRF).
 
 Different KDFs are suitable for different tasks such as:
 
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt
index 0f90a152df3..d72f0c97684 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt
@@ -16,7 +16,7 @@ class MastgTest(private val context: Context) {
     // Vulnerable encryption using DES (broken algorithm)
     fun vulnerableDesEncryption(data: String): String {
         try {
-            // insufficient key for DES
+            // Insufficient key for DES
             val keyBytes = ByteArray(8)
             SecureRandom().nextBytes(keyBytes)
             val keySpec = DESKeySpec(keyBytes)
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0009.md b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
index ffc30b5c2b1..98e58e26357 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0009.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
@@ -36,7 +36,7 @@ The digest (or hash) of an improper implemented or used hash function may allow
 
 - **Inadequate Entropy During Key Generation**: Using a poor source of randomness can lead to predictable cryptographic keys. If the randomness lacks sufficient entropy, the generated keys may be easier for attackers to guess or recreate, compromising the security of the system.
 - **Insufficient Key Length**: Cryptographic keys that are too short provide inadequate security. For example, keys shorter than recommended lengths for modern algorithms may be vulnerable to brute force attacks, making them easier for attackers to break.
-- **Using Outdated, Risky or Broken Algorithms**: Relying on deprecated, risky or inherently or broken cryptographic algorithms can result in the generation of weaker keys. As these algorithms often have vulnerabilities or support shorter key lengths, they are more susceptible to modern attacks, compromising the overall security of the app.
+- **Using Outdated, Risky or Broken Algorithms**: Relying on deprecated, risky or inherently broken cryptographic algorithms can result in the generation of weaker keys. As these algorithms often have vulnerabilities or support shorter key lengths, they are more susceptible to modern attacks, compromising the overall security of the app.
 
 ## Mitigations
 
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
index 41863a0cce9..db5e4c1728f 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
@@ -42,5 +42,5 @@ A deprecated HMAC implementation may contain bugs that could compromise the auth
 ## Mitigations
 
 - **Use MAC with a timestamp**: Generate the MAC over a message with the timestamp included. This should protect the application against replay attacks within a reasonable amount of time. Reasonable, meaning a time frame that is short enough to prevent an attacker from sending an identical message and long enough to allow the message to be sent and digested.
-- **Do not use HMAC together with a low-entropy key**: Ensure the keys used are generated using cyptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks.
-- **Do not use deprecated HMCA implementations**: Deprecated HMCA implementations could contain errors that allow for collision attacks. Therefore, only use recommended libraries and functions.
+- **Do not use HMAC together with a low-entropy key**: Ensure the keys used are generated using cryptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks.
+- **Do not use deprecated HMAC implementations**: Deprecated HMAC implementations could contain errors that allow for collision attacks. Therefore, only use recommended libraries and functions.
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0025.md b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
index 85a72146ac6..1f6021faff2 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0025.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
@@ -15,7 +15,7 @@ refs:
 - https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf
 - https://csrc.nist.gov/pubs/ir/8547/ipd
 draft:
-  description: The use of algorithms with insufficient strength for signatures such as SHA1withRSA, etc. in a security sensitive context should be avoided to ensure the integrity and authenticity of the data.
+  description: The use of algorithms with insufficient strength for signatures such as SHA1withRSA, etc. in a security-sensitive context should be avoided to ensure the integrity and authenticity of the data.
   topics: null
 status: draft
 

From 65b8dfae3a38aea6e0364c186b6e8fde6d7dee46 Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Wed, 2 Jul 2025 08:32:28 +0200
Subject: [PATCH 074/117] Fix typos and improve clarity in cryptography chapter

---
 Document/0x04g-Testing-Cryptography.md | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 4a2cfefb387..a1bb829cac8 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -151,24 +151,24 @@ When using a password hashing algorithm as a KDF, also ensure to choose an appro
 
 It is fundamentally impossible to produce truly random numbers on any deterministic device. Pseudo-random number generators (PRNG) compensate for this by producing a stream of pseudo-random numbers - a stream of numbers that appear as if they were randomly generated. The quality of the generated numbers varies with the type of algorithm used. Cryptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks (e.g. it is statistically infeasible to predict the next number produced).
 
-PRNG can be vulnerable when developers use a regular PRNG for cryptographic purposes, instead of a cryptographically-secure PRNG (["Cryptographically secure pseudorandom number generator", 2025.01.31](https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator "WIkipedia: Cryptographically secure pseudorandom number generator")). 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.
+PRNGs can be vulnerable when developers use a regular PRNG for cryptographic purposes, instead of a cryptographically secure PRNG (["Cryptographically secure pseudorandom number generator", 2025.01.31](https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator "Wikipedia: Cryptographically secure pseudorandom number generator")). 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 meet this condition.
 
-Mobile SDKs offer standard implementations of PRNG algorithms that produce numbers with sufficient artificial randomness. We'll introduce the available APIs in the Android and iOS specific sections.
+Mobile SDKs offer standard implementations of PRNG algorithms that produce numbers with sufficient artificial randomness. We'll introduce the available APIs in the Android and iOS-specific sections.
 
 ### Weak, Risky or Broken Hashing
 
 Make sure to choose a hash function that is built for the purpose you intend it for.
-When hashes are needed for integrity checks, choose an algorithm that is sufficiently collision resistant like the integrity algorithms SHA-256, SHA-384, SHA-512, BLAKE3 and the SHA-3 family. Choosing a risky or broken algorithm may compromise the integrity and authenticity of data at rest and in transit. Also keep in mind that hash functions used for integrity checks, like the SHA series, should not be used for key derivation together with predictable input or in password hashing.
+When hashes are needed for integrity checks, choose an algorithm that is sufficiently collision resistant, such as the integrity algorithms SHA-256, SHA-384, SHA-512, BLAKE3, and the SHA-3 family. Choosing a risky or broken algorithm may compromise the integrity and authenticity of data at rest and in transit. Also keep in mind that hash functions used for integrity checks, like the SHA series, should not be used for key derivation together with predictable input or in password hashing.
 
 ### Custom Implementations of Cryptography
 
-Inventing proprietary cryptographic functions is time consuming, difficult, and likely to fail. Instead, we can use well-known algorithms that are widely regarded as secure. Mobile operating systems offer standard cryptographic APIs that implement those algorithms.
+Inventing proprietary cryptographic functions is time-consuming, difficult, and likely to fail. Instead, we can use well-known algorithms that are widely regarded as secure. Mobile operating systems offer standard cryptographic APIs that implement those algorithms.
 
 Carefully inspect all the cryptographic methods used within the source code, especially those that are directly applied to sensitive data. All cryptographic operations should use standard cryptographic APIs for Android and iOS (we'll write about those in more detail in the platform-specific chapters). Any cryptographic operations that don't invoke standard routines from known providers should be closely inspected. Pay close attention to standard algorithms that have been modified. Remember that encoding isn't the same as encryption! Always investigate further when you find bit manipulation operators like XOR (exclusive OR).
 
-At all implementations of cryptography, you need to ensure that the following always takes place:
+In all implementations of cryptography, you need to ensure that the following always takes place:
 
-- Worker keys (like intermediary/derived keys in AES/DES/Rijndael) are properly removed from memory after consumption or in case of error.
+- Working keys (like intermediary/derived keys in AES/DES/Rijndael) are properly removed from memory after consumption or in case of error.
 - The inner state of a cipher should be removed from memory as soon as possible.
 
 ### Inadequate AES Configuration
@@ -177,15 +177,15 @@ Advanced Encryption Standard (AES) is the widely accepted standard for symmetric
 
 As of this writing, no efficient cryptanalytic attacks against AES have been discovered. However, implementation details and configurable parameters such as the block cipher mode leave some margin for error.
 
-#### Recommendations for Block Cipher Mode
+#### Inadequate Block Cipher Mode
 
 Block-based encryption is performed upon discrete input blocks (for example, AES has 128-bit blocks). If the plaintext is larger than the block size, the plaintext is internally split up into blocks of the given input size and encryption is performed on each block. A block cipher mode of operation (or block mode) determines if the result of encrypting the previous block impacts subsequent blocks.
 
-[ECB (Electronic Codebook)](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_%28ECB%29 "Electronic Codebook (ECB)") divides the input into fixed-size blocks that are encrypted separately using the same key. If multiple divided blocks contain the same plaintext, they will be encrypted into identical ciphertext blocks which makes patterns in data easier to identify. In some situations, an attacker might also be able to replay the encrypted data.
+Avoid using the [ECB (Electronic Codebook)](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_%28ECB%29 "Electronic Codebook (ECB)") mode. ECB divides the input into fixed-size blocks that are encrypted separately using the same key. If multiple divided blocks contain the same plaintext, they will be encrypted into identical ciphertext blocks which makes patterns in data easier to identify. In some situations, an attacker might also be able to replay the encrypted data.
 
 <img src="Images/Chapters/0x07c/EncryptionMode.png" width="550px" />
 
-Verify that Cipher Block Chaining (CBC) mode is used instead of ECB. In CBC mode, plaintext blocks are XORed with the previous ciphertext block. This ensures that each encrypted block is unique and randomized even if blocks contain the same information. Please note that it is best to combine CBC with an HMAC and/or ensure that no errors are given such as "Padding error", "MAC error", "decryption failed" in order to be more resistant to a padding oracle attack.
+For new designs, prefer authenticated encryption with associated data (AEAD) modes such as Galois/Counter Mode (GCM) or Counter with CBC-MAC (CCM), as these provide both confidentiality and integrity. If GCM or CCM are not available, Cipher Block Chaining (CBC) mode is better than ECB, but should be combined with an HMAC and/or ensure that no errors are given such as "Padding error", "MAC error", or "decryption failed" to be more resistant to padding oracle attacks. In CBC mode, plaintext blocks are XORed with the previous ciphertext block, ensuring that each encrypted block is unique and randomized even if blocks contain the same information.
 
 When storing encrypted data, we recommend using a block mode that also protects the integrity of the stored data, such as Galois/Counter Mode (GCM). The latter has the additional benefit that the algorithm is mandatory for each TLSv1.2 implementation, and thus is available on all modern platforms. To protect the integrity and authenticity of the data using CBC mode, it is recommended to combine the techniques of the Counter (CTR) mode and the Cipher Block Chaining-Message Authentication Code (CBC-MAC) into what is called CCM Mode ([NIST, 2004](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final "NIST: Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality")).
 
@@ -197,11 +197,11 @@ CBC, OFB, CFB, PCBC, GCM mode require an initialization vector (IV) as an initia
 
 Pay attention to cryptographic libraries used in the code: many open source libraries provide examples in their documentations that might follow bad practices (e.g. using a hardcoded IV). A popular mistake is copy-pasting example code without changing the IV value.
 
-#### Using the same key for encryption and authentication
+#### Using the Same Key for Encryption and Authentication
 
 One common mistake is to reuse the same key for CBC encryption and CBC-MAC. Reuse of keys for different purposes is generally not recommended, but in the case of CBC-MAC the mistake can lead to a MitM attack (["CBC-MAC", 2024.10.11](https://en.wikipedia.org/wiki/CBC-MAC "Wikipedia: CBC-MAC")).
 
-#### Initialization Vectors in stateful operation modes
+#### Initialization Vectors in Stateful Operation Modes
 
 Please note that the usage of IVs is different when using CTR and GCM mode in which the initialization vector is often a counter (in CTR combined with a nonce). So here using a predictable IV with its own stateful model is exactly what is needed. In CTR you have a new nonce plus counter as an input to every new block operation. For example: for a 5120 bit long plaintext: you have 20 blocks, so you need 20 input vectors consisting of a nonce and counter. Whereas in GCM you have a single IV per cryptographic operation, which should not be repeated with the same key. See section 8 of the [documentation from NIST on GCM](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode and GMAC") for more details and recommendations of the IV.
 
@@ -219,7 +219,7 @@ Therefore it is best to consider the following, if keys are still needed at the
 - **Keys in a Remote Server**: you can use remote Key vaults such as Amazon KMS or Azure Key Vault. For some use cases, developing an orchestration layer between the app and the remote resource might be a suitable option. For instance, a serverless function running on a Function as a Service (FaaS) system (e.g. AWS Lambda or Google Cloud Functions) which forwards requests to retrieve an API key or secret. There are other alternatives such as Amazon Cognito, Google Identity Platform or Azure Active Directory.
 - **Keys inside Secure Hardware-backed Storage**: make sure that all cryptographic actions and the key itself remain in the Trusted Execution Environment (e.g. use [Android Keystore](https://developer.android.com/training/articles/keystore.html "Android keystore system")) or [Secure Enclave](https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_secure_enclave "Storing Keys in the Secure Enclave") (e.g. use the Keychain). Refer to the [Android Data Storage](0x05d-Testing-Data-Storage.md#storing-keys-using-hardware-backed-android-keystore) and [iOS Data Storage](0x06d-Testing-Data-Storage.md#the-keychain) chapters for more information.
 - **Keys protected by Envelope Encryption**: If keys are stored outside of the TEE / SE, consider using multi-layered encryption: an _envelope encryption_ approach (see [OWASP Cryptographic Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#encrypting-stored-keys "OWASP Cryptographic Storage Cheat Sheet: Encrypting Stored Keys"), [Google Cloud Key management guide](https://cloud.google.com/kms/docs/envelope-encryption?hl=en "Google Cloud Key management guide: Envelope encryption"), [AWS Well-Architected Framework guide](https://docs.aws.amazon.com/wellarchitected/latest/financial-services-industry-lens/use-envelope-encryption-with-customer-master-keys.html "AWS Well-Architected Framework")), or [a HPKE approach](https://tools.ietf.org/html/draft-irtf-cfrg-hpke-08 "Hybrid Public Key Encryption") to encrypt data encryption keys with key encryption keys.
-- **Keys in Memory**: make sure that keys live in memory for the shortest time possible and consider zeroing out and nullifying keys after successful cryptographic operations, and in case of error. For general cryptocoding guidelines, refer to [Clean memory of secret data](https://github.com/veorq/cryptocoding#clean-memory-of-secret-data/ "The Cryptocoding Guidelines by @veorq: Clean memory of secret data").
+- **Keys in Memory**: make sure that keys live in memory for the shortest time possible and consider zeroing out and nullifying keys after successful cryptographic operations, and in case of error. Note: In some languages and platforms (such as those with garbage collection or memory management optimizations), reliably zeroing memory may not be possible, as the runtime may move or copy memory or delay actual erasure. For general cryptocoding guidelines, refer to [Clean memory of secret data](https://github.com/veorq/cryptocoding#clean-memory-of-secret-data/ "The Cryptocoding Guidelines by @veorq: Clean memory of secret data").
 
 Note: given the ease of memory dumping, never share the same key among accounts and/or devices, other than public keys used for signature verification or encryption.
 

From 35c2aec372d37c6bfb9b5b622a7eb25255e6c961 Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Wed, 2 Jul 2025 08:33:03 +0200
Subject: [PATCH 075/117] Update Document/0x05d-Testing-Data-Storage.md

---
 Document/0x05d-Testing-Data-Storage.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x05d-Testing-Data-Storage.md b/Document/0x05d-Testing-Data-Storage.md
index ee00175871d..2a46f519af3 100644
--- a/Document/0x05d-Testing-Data-Storage.md
+++ b/Document/0x05d-Testing-Data-Storage.md
@@ -546,7 +546,7 @@ Deriving a key from a user provided passphrase is a common solution (depending o
 
 Each time the application needs to perform a cryptographic operation, the user's passphrase is needed. Either the user is prompted for it every time, which isn't an ideal user experience, or the passphrase is kept in memory as long as the user is authenticated. Keeping the passphrase in memory is not a best-practice, as any cryptographic material must only be kept in memory while it is being used. Zeroing out a key is often a very challenging task as explained in ["Cleaning out Key Material"](#cleaning-out-key-material).
 
-Additionally, consider that keys derived from a passphrase have their own weaknesses. For instance, the passwords or passphrases might be reused by the user or easy to guess. Please refer to the [Testing Cryptography chapter](0x04g-Testing-Cryptography.md#improper-key-derivation-functions) for more information.
+Additionally, consider that keys derived from a passphrase have their own weaknesses. For instance, the passwords or passphrases might be reused by the user or easy to guess. Please refer to the chapter ["Testing Cryptography"](0x04g-Testing-Cryptography.md#improper-key-derivation-functions) for more information.
 
 #### Cleaning out Key Material
 

From 10012aee737cd8599433e5b852d3b146e35fa36f Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 2 Jul 2025 09:13:41 +0200
Subject: [PATCH 076/117] Update Document/0x08c-Glossary.md

Co-authored-by: Jeroen Beckers <me.githbub@dauntless.be>
---
 Document/0x08c-Glossary.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x08c-Glossary.md b/Document/0x08c-Glossary.md
index 724f5d55c0c..3a632f39928 100644
--- a/Document/0x08c-Glossary.md
+++ b/Document/0x08c-Glossary.md
@@ -11,7 +11,7 @@ The meaning depends on the context.
 
 A "broken" cryptographic hash algorithm is a function that is denounced as "broken" because a collision attack exist that is faster to execute then a birthday attack ([Wikipedia, "2025.02.19"](https://en.wikipedia.org/wiki/Collision_attack "Collision attack")).
 
-An encryption mode of operation is "broken" if it, when implemented correctly, still faces the risk from known attacks that can "break" the confidentiality of the encrypted data.
+A cryptographic mode of operation is "broken" if it, when implemented correctly, still faces the risk from known attacks that can "break" the confidentiality of the encrypted data.
 
 ### Deprecated
 

From 0bd1418193e96fbb43e70a7f7ee095d04534f946 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 2 Jul 2025 09:13:55 +0200
Subject: [PATCH 077/117] Update
 demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
---
 demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt
index d72f0c97684..a2b90aecd36 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt
@@ -72,7 +72,7 @@ class MastgTest(private val context: Context) {
         }
     }
 
-    // Risky encryption using Blowfish (weak algorithm)
+    // Risky encryption using Blowfish (risky algorithm)
     fun vulnerableBlowfishEncryption(data: String): String {
         return try {
             // insufficient key for Blowfish (risky, small key size)

From 53d9b2d93fa0ef2ce19aad7d4defa6a44b66cb10 Mon Sep 17 00:00:00 2001
From: sydseter <johan.sydseter@admincontrol.com>
Date: Wed, 2 Jul 2025 09:23:10 +0200
Subject: [PATCH 078/117] Removed quotes.

---
 Document/0x08c-Glossary.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Document/0x08c-Glossary.md b/Document/0x08c-Glossary.md
index 3a632f39928..ac3f956c57c 100644
--- a/Document/0x08c-Glossary.md
+++ b/Document/0x08c-Glossary.md
@@ -9,9 +9,9 @@ title: Glossary
 
 The meaning depends on the context.
 
-A "broken" cryptographic hash algorithm is a function that is denounced as "broken" because a collision attack exist that is faster to execute then a birthday attack ([Wikipedia, "2025.02.19"](https://en.wikipedia.org/wiki/Collision_attack "Collision attack")).
+A broken cryptographic hash algorithm is a function that is denounced as broken because a collision attack exist that is faster to execute then a birthday attack ([Wikipedia, "2025.02.19"](https://en.wikipedia.org/wiki/Collision_attack "Collision attack")).
 
-A cryptographic mode of operation is "broken" if it, when implemented correctly, still faces the risk from known attacks that can "break" the confidentiality of the encrypted data.
+A cryptographic mode of operation is broken if it, when implemented correctly, still faces the risk from known attacks that can break the confidentiality of the encrypted data.
 
 ### Deprecated
 
@@ -19,7 +19,7 @@ When mentioned as a cryptographic term it means a mode of operation, algorithm o
 
 ### Improper
 
-Used as a catch-all term to cover security behaviors that are either "Missing" or "Insufficient/Incorrect".
+Used as a catch-all term to cover security behaviors that are either missing or insufficient/incorrect.
 
 ### Insufficient
 
@@ -31,7 +31,7 @@ Reference to risk uses the ISO 3000 definition: Risk = "effect of uncertainty on
 
 ### Risky
 
-A "risky" cryptographic hash algorithm carries with it an effect of uncertainty on the objectives that the specific algorithm must satisfy. The algorithm is therefore said to be "risky" when used under certain circumstances, and because of that, carries with it the risk of being compromised in an attack when used improperly. The same can be considered when referring to a "risky" encryption mode of operation.
+A risky cryptographic hash algorithm carries with it an "effect of uncertainty on the objectives" that the specific algorithm must satisfy. The algorithm is therefore said to be risky when used under certain circumstances, and because of that, carries with it the risk of being compromised in an attack when used improperly. The same can be considered when referring to a risky encryption mode of operation.
 
 ### Strength
 

From e9c5362563319c7b3fb7959809c08a8e08431453 Mon Sep 17 00:00:00 2001
From: sydseter <johan.sydseter@admincontrol.com>
Date: Wed, 2 Jul 2025 09:26:08 +0200
Subject: [PATCH 079/117] Add KDF to the glossary

---
 Document/0x08c-Glossary.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Document/0x08c-Glossary.md b/Document/0x08c-Glossary.md
index ac3f956c57c..877bed5d4b4 100644
--- a/Document/0x08c-Glossary.md
+++ b/Document/0x08c-Glossary.md
@@ -25,6 +25,10 @@ Used as a catch-all term to cover security behaviors that are either missing or
 
 According to MITRE: _A general term used to describe when a security property or behavior can vary in strength on a continuous or sliding scale, instead of a discrete scale. The continuous scale may vary depending on the context and risk tolerance. For example, the requirements for randomness may vary between a random selection for a greeting message versus the generation of a military-strength key. On the other hand, a weakness that allows a buffer overflow is always incorrect - there is not a sliding scale that varies across contexts_ ([MITRE, "2024.07.07"](https://cwe.mitre.org/documents/glossary/index.html#Insufficient "Glossary")).
 
+### KDF
+
+KDF stands for key derivation function which is a cryptographic algorithm that derives one or more secret keys from a secret value such as a master key, a password, or a passphrase using a pseudorandom function (which typically uses a cryptographic hash function or block cipher).
+
 ### Risk
 
 Reference to risk uses the ISO 3000 definition: Risk = "effect of uncertainty on objectives."

From 94da712f938e6c9f2770e81fcf088a9f2670e6ce Mon Sep 17 00:00:00 2001
From: sydseter <johan.sydseter@admincontrol.com>
Date: Wed, 2 Jul 2025 10:13:57 +0200
Subject: [PATCH 080/117] Simplify example

---
 weaknesses/MASVS-CRYPTO/MASWE-0010.md | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
index ab967ef4ad7..5d2b8faa29b 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
@@ -25,8 +25,12 @@ status: placeholder
 Improper Key derivation functions will generate a key using a scheme or iteration count that does not provide a sufficient level of computational effort. This can open up the possibility for brute force password/secret cracking or dictionary attacks.
 In cases where a user-supplied password or pin is used without a sufficiently random salt the resulting output will be identical or similar enough to allow an attacker to execute a brute force attack to find the original password/pin using the KDF as an "oracle".
 A similar issue happens when the salt is user-supplied. Consider a mobile app that generates user keys from a master key on demand during installation. Let's say that a key used in the mobile app is derived from this master key using the username or other user supplied value as salt. Such an implementation can make it possible for an attacker to retrieve the derived key by using the username or supplied user value as input.
-Another common issue is using HKDF or any other type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HKDFs aren't designed for low-entropy inputs. Therefore, password crackers can fairly efficiently crack massive amounts of passwords for KDFs that aren't purposefully designed to be slow and memory-intensive. A similar issue happens when using deprecated, risky or broken KDF- or password hashing algorithms known to the vulnerable to various types of attacks.
-Also, cryptographic algorithms (such as symmetric encryption or some MACs) expect a secret input of a given size. For example, AES uses a key of exactly 16 bytes. A naive implementation might use the user-supplied password directly as an input key. Using a user-supplied password or pin as an input key has the following problems:
+
+HKDFs or any other type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 aren't designed for low-entropy inputs like in the username example above. Therefore, password crackers can fairly efficiently crack massive amounts of passwords for KDFs that aren't purposefully designed to be slow and memory-intensive. 
+A similar issue happens when using deprecated, risky or broken KDF- or password hashing algorithms known to the vulnerable to various types of attacks.
+Also, cryptographic algorithms (such as symmetric encryption or some MACs) expect a secret input of a given size.
+
+For example, AES uses a key of exactly 16 bytes. A naive implementation might use a username, a user-supplied password or pin directly as an input key. Using a username, a user-supplied password or pin as an input key has the following problems:
 
 - If the password is smaller than the key, the full key space isn't used. The remaining space is padded, often with spaces or null bytes.
 - A user-supplied password will realistically consist mostly of displayable and pronounceable characters. Therefore, only some of the possible 256 ASCII characters are used and entropy is decreased by approximately a factor of four.

From e675b9c131169e26dae40e540b4be04c389e2e3e Mon Sep 17 00:00:00 2001
From: sydseter <johan.sydseter@admincontrol.com>
Date: Wed, 2 Jul 2025 10:21:08 +0200
Subject: [PATCH 081/117] Simplify language

---
 weaknesses/MASVS-CRYPTO/MASWE-0010.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
index 5d2b8faa29b..2da66b3a4e3 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
@@ -30,7 +30,7 @@ HKDFs or any other type of integrity based hashing algorithm like MD5, SHA-1, SH
 A similar issue happens when using deprecated, risky or broken KDF- or password hashing algorithms known to the vulnerable to various types of attacks.
 Also, cryptographic algorithms (such as symmetric encryption or some MACs) expect a secret input of a given size.
 
-For example, AES uses a key of exactly 16 bytes. A naive implementation might use a username, a user-supplied password or pin directly as an input key. Using a username, a user-supplied password or pin as an input key has the following problems:
+For example, AES uses a key of exactly 16 bytes. A naive implementation might use a username, a low entropy password or pin directly as an input key. Using a username, a low entropy password or pin as an input key has the following problems:
 
 - If the password is smaller than the key, the full key space isn't used. The remaining space is padded, often with spaces or null bytes.
 - A user-supplied password will realistically consist mostly of displayable and pronounceable characters. Therefore, only some of the possible 256 ASCII characters are used and entropy is decreased by approximately a factor of four.
@@ -43,9 +43,9 @@ For example, AES uses a key of exactly 16 bytes. A naive implementation might us
 
 ## Modes of Introduction
 
-- **Using static or predictable salt on low-entropy input**: Using user-supplied input together with a static or predictable salt makes it possible for the attacker to to pre-compute the hash value using dictionary attack, effectively disabling the protection that a salt would provide.
-- **Using user-supplied salt**: Using user-supplied salt will make it possible for an attacker to extract all derived keys through a KDF by supplying the user-supplied salt as an argument.
-- **Using non-resource intensive algorithms on low-entropy input**: Using user-supplied input together with a HKDF makes it easy for password crackers to execute a preimage attack.
+- **Using static or predictable salt on low-entropy input**: Using an enumerable pin code or low entropy password together with a static or predictable salt makes it possible for the attacker to to pre-compute the hash value using dictionary attack, effectively disabling the protection that a salt would provide.
+- **Using user-supplied salt**: Using a low entropy salt will make it possible for an attacker to extract all derived keys through a KDF by supplying the low entropy salt as an argument.
+- **Using non-resource intensive algorithms on low-entropy input**: Using an enumerable pin code or low entropy password together with a HKDF makes it easy for password crackers to execute a preimage attack.
 - **Use a hash function as a general-purpose KDF**: In scenarios where the information used during key derivation is attacker-controlled, using a integrity based hash function (e.g from the SHA family) as KDF can expose the application to brute force or length-extension attacks.
 - **Using Deprecated, Risky or Broken Algorithms**: Relying on deprecated, risky or inherently broken cryptographic algorithms can result in the generation of weaker keys. As these algorithms often have vulnerabilities or support shorter key lengths, they are more susceptible to modern attacks, compromising the overall security of the app.
 

From cad89819b6d7988a60250f89e4bdb971c523e440 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Wed, 2 Jul 2025 11:16:37 +0200
Subject: [PATCH 082/117] Update weaknesses/MASVS-CRYPTO/MASWE-0010.md

Co-authored-by: Jeroen Beckers <me.githbub@dauntless.be>
---
 weaknesses/MASVS-CRYPTO/MASWE-0010.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
index 2da66b3a4e3..7f495a0a3e7 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
@@ -52,5 +52,5 @@ For example, AES uses a key of exactly 16 bytes. A naive implementation might us
 ## Mitigations
 
 - **Generate random salt using CSPRNGs with high entropy seeding**: Ensuring the use of strong, cryptographically secure PRNGs called CSPRNGs with high entropy seeding is essential for robust key security.
-- **Use Recommended and Approved algorithms that are fit for purpose**: In cases where the input is user-controlled, use key derivation functions such as Argon2, scrypt, bcrypt or PBKDF2 that provides a sufficient level of computational effort. Otherwise, ensure the input is thoroughly random using a recommended CSPRNG that guarantees high entropy seeding.
+- **Use Recommended and Approved algorithms that are fit for purpose**: In cases where the input is user-controlled, use key derivation functions such as Argon2, scrypt, bcrypt or PBKDF2 that provide a sufficient level of computational effort. Otherwise, ensure the input is thoroughly random using a recommended CSPRNG that guarantees high entropy seeding.
 - **Prefer HKDF and other KDFs that were designed specifically for key derivation**: HKDF and other KDFs specifically meant for key derivation will ensure the app isn't exposed to length-extension attacks.

From f3497a852c8d7aac381d275e9dc25c23c050ccc1 Mon Sep 17 00:00:00 2001
From: sydseter <johan.sydseter@admincontrol.com>
Date: Wed, 2 Jul 2025 11:19:13 +0200
Subject: [PATCH 083/117] Lint corrections

---
 weaknesses/MASVS-CRYPTO/MASWE-0010.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
index 2da66b3a4e3..5aad790fb42 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
@@ -26,7 +26,7 @@ Improper Key derivation functions will generate a key using a scheme or iteratio
 In cases where a user-supplied password or pin is used without a sufficiently random salt the resulting output will be identical or similar enough to allow an attacker to execute a brute force attack to find the original password/pin using the KDF as an "oracle".
 A similar issue happens when the salt is user-supplied. Consider a mobile app that generates user keys from a master key on demand during installation. Let's say that a key used in the mobile app is derived from this master key using the username or other user supplied value as salt. Such an implementation can make it possible for an attacker to retrieve the derived key by using the username or supplied user value as input.
 
-HKDFs or any other type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 aren't designed for low-entropy inputs like in the username example above. Therefore, password crackers can fairly efficiently crack massive amounts of passwords for KDFs that aren't purposefully designed to be slow and memory-intensive. 
+HKDFs or any other type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 aren't designed for low-entropy inputs like in the username example above. Therefore, password crackers can fairly efficiently crack massive amounts of passwords for KDFs that aren't purposefully designed to be slow and memory-intensive.
 A similar issue happens when using deprecated, risky or broken KDF- or password hashing algorithms known to the vulnerable to various types of attacks.
 Also, cryptographic algorithms (such as symmetric encryption or some MACs) expect a secret input of a given size.
 

From 7e2f57fe9a25206288079f4b516ed4440c7df455 Mon Sep 17 00:00:00 2001
From: sydseter <johan.sydseter@admincontrol.com>
Date: Wed, 2 Jul 2025 11:40:46 +0200
Subject: [PATCH 084/117] Add more terms to the glossary

---
 Document/0x08c-Glossary.md | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/Document/0x08c-Glossary.md b/Document/0x08c-Glossary.md
index 877bed5d4b4..73c3e3203a0 100644
--- a/Document/0x08c-Glossary.md
+++ b/Document/0x08c-Glossary.md
@@ -5,6 +5,10 @@ title: Glossary
 
 ## Cryptographic Terms
 
+### Block cipher
+
+A symmetric encryption algorithm that encrypts data in fixed-size blocks, rather than one bit at a time like stream ciphers.
+
 ### Broken
 
 The meaning depends on the context.
@@ -25,10 +29,18 @@ Used as a catch-all term to cover security behaviors that are either missing or
 
 According to MITRE: _A general term used to describe when a security property or behavior can vary in strength on a continuous or sliding scale, instead of a discrete scale. The continuous scale may vary depending on the context and risk tolerance. For example, the requirements for randomness may vary between a random selection for a greeting message versus the generation of a military-strength key. On the other hand, a weakness that allows a buffer overflow is always incorrect - there is not a sliding scale that varies across contexts_ ([MITRE, "2024.07.07"](https://cwe.mitre.org/documents/glossary/index.html#Insufficient "Glossary")).
 
-### KDF
+### KDF - key derivation function
 
 KDF stands for key derivation function which is a cryptographic algorithm that derives one or more secret keys from a secret value such as a master key, a password, or a passphrase using a pseudorandom function (which typically uses a cryptographic hash function or block cipher).
 
+### Master key
+
+A key that's used to protect other keys, either by encrypting them or by deriving new keys from it.
+
+### Mode of operation
+
+A mode of operation specifies how to repeatedly encrypt or decrypt a single block of data using a block cipher.
+
 ### Risk
 
 Reference to risk uses the ISO 3000 definition: Risk = "effect of uncertainty on objectives."
@@ -37,6 +49,10 @@ Reference to risk uses the ISO 3000 definition: Risk = "effect of uncertainty on
 
 A risky cryptographic hash algorithm carries with it an "effect of uncertainty on the objectives" that the specific algorithm must satisfy. The algorithm is therefore said to be risky when used under certain circumstances, and because of that, carries with it the risk of being compromised in an attack when used improperly. The same can be considered when referring to a risky encryption mode of operation.
 
+### Stream ciphers
+
+A type of symmetric encryption algorithm that encrypts data one bit or byte at a time.
+
 ### Strength
 
 According to NIST. A number associated with the amount of work (that is, the number of operations) that is required to break a cryptographic algorithm or system. If 2N execution operations of the algorithm (or system) are required to break the cryptographic algorithm, then the security strength is N bits ([NIST, security strength](https://csrc.nist.gov/glossary/term/security_strength "security strength")).

From 384f6afad00aef1ed6e94bb5ea7d7a64b8ca6ddb Mon Sep 17 00:00:00 2001
From: sydseter <johan.sydseter@admincontrol.com>
Date: Wed, 2 Jul 2025 11:43:46 +0200
Subject: [PATCH 085/117] Fix build

---
 weaknesses/MASVS-CRYPTO/MASWE-0024.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
index db5e4c1728f..85f850dca62 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
@@ -17,7 +17,7 @@ refs:
 - https://web.archive.org/web/20170810051504/http://www.tcs.hut.fi/old/papers/aura/aura-csfws97.pdf
 - https://en.wikipedia.org/wiki/Replay_attack
 draft:
-  description: Improper use of MAC. E.g: allowing the user to control the input.
+  description: Improper use of MAC. E.g. allowing the user to control the input.
     may expose cryptographic vulnerabilities, affecting data integrity.
   topics: null
 status: draft

From ee8f342ec54d29d3484eda9491895bdd837baea9 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sat, 5 Jul 2025 00:03:14 +0200
Subject: [PATCH 086/117] Update 0x08c-Glossary.md

---
 Document/0x08c-Glossary.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x08c-Glossary.md b/Document/0x08c-Glossary.md
index 73c3e3203a0..69a961f7331 100644
--- a/Document/0x08c-Glossary.md
+++ b/Document/0x08c-Glossary.md
@@ -43,7 +43,7 @@ A mode of operation specifies how to repeatedly encrypt or decrypt a single bloc
 
 ### Risk
 
-Reference to risk uses the ISO 3000 definition: Risk = "effect of uncertainty on objectives."
+Risk refers to the ISO 3000 definition: Risk = "effect of uncertainty on objectives".
 
 ### Risky
 

From a6efdb74aadd850ec8f8fd85f3d86871f853cf5c Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sat, 5 Jul 2025 00:08:37 +0200
Subject: [PATCH 087/117] Update MASWE-0010.md

---
 weaknesses/MASVS-CRYPTO/MASWE-0010.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
index 612af75a296..206c37e7206 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
@@ -23,7 +23,7 @@ status: placeholder
 ## Overview
 
 Improper Key derivation functions will generate a key using a scheme or iteration count that does not provide a sufficient level of computational effort. This can open up the possibility for brute force password/secret cracking or dictionary attacks.
-In cases where a user-supplied password or pin is used without a sufficiently random salt the resulting output will be identical or similar enough to allow an attacker to execute a brute force attack to find the original password/pin using the KDF as an "oracle".
+In cases where a user-supplied password or pin is used without a sufficiently random salt the resulting output will be identical or similar enough to allow an attacker to execute a brute force attack to find the original password/pin using the key derivation function as an "oracle".
 A similar issue happens when the salt is user-supplied. Consider a mobile app that generates user keys from a master key on demand during installation. Let's say that a key used in the mobile app is derived from this master key using the username or other user supplied value as salt. Such an implementation can make it possible for an attacker to retrieve the derived key by using the username or supplied user value as input.
 
 HKDFs or any other type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 aren't designed for low-entropy inputs like in the username example above. Therefore, password crackers can fairly efficiently crack massive amounts of passwords for KDFs that aren't purposefully designed to be slow and memory-intensive.

From 3638bf6c041bc126a8c1cc4dbbf1f74eac4a3b19 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sat, 5 Jul 2025 00:09:41 +0200
Subject: [PATCH 088/117] Update MASWE-0010.md

---
 weaknesses/MASVS-CRYPTO/MASWE-0010.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
index 206c37e7206..58e696d9539 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
@@ -23,7 +23,7 @@ status: placeholder
 ## Overview
 
 Improper Key derivation functions will generate a key using a scheme or iteration count that does not provide a sufficient level of computational effort. This can open up the possibility for brute force password/secret cracking or dictionary attacks.
-In cases where a user-supplied password or pin is used without a sufficiently random salt the resulting output will be identical or similar enough to allow an attacker to execute a brute force attack to find the original password/pin using the key derivation function as an "oracle".
+In cases where a user-supplied password or pin is used without a sufficiently random salt the resulting output will be identical or similar enough to allow an attacker to execute a brute force attack to find the original password/pin using the KDF (key derivation function) as an "oracle".
 A similar issue happens when the salt is user-supplied. Consider a mobile app that generates user keys from a master key on demand during installation. Let's say that a key used in the mobile app is derived from this master key using the username or other user supplied value as salt. Such an implementation can make it possible for an attacker to retrieve the derived key by using the username or supplied user value as input.
 
 HKDFs or any other type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 aren't designed for low-entropy inputs like in the username example above. Therefore, password crackers can fairly efficiently crack massive amounts of passwords for KDFs that aren't purposefully designed to be slow and memory-intensive.

From 08989104baf0f657e14b0d04c6106e79a4d25c89 Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Thu, 10 Jul 2025 09:02:01 +0200
Subject: [PATCH 089/117] rm new content that should go into new PRs

---
 weaknesses/MASVS-CRYPTO/MASWE-0010.md | 34 ---------------------------
 weaknesses/MASVS-CRYPTO/MASWE-0021.md | 27 ---------------------
 weaknesses/MASVS-CRYPTO/MASWE-0024.md | 20 ----------------
 weaknesses/MASVS-CRYPTO/MASWE-0025.md | 16 -------------
 4 files changed, 97 deletions(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
index 58e696d9539..34db7c2cfb0 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
@@ -20,37 +20,3 @@ status: placeholder
 
 ---
 
-## Overview
-
-Improper Key derivation functions will generate a key using a scheme or iteration count that does not provide a sufficient level of computational effort. This can open up the possibility for brute force password/secret cracking or dictionary attacks.
-In cases where a user-supplied password or pin is used without a sufficiently random salt the resulting output will be identical or similar enough to allow an attacker to execute a brute force attack to find the original password/pin using the KDF (key derivation function) as an "oracle".
-A similar issue happens when the salt is user-supplied. Consider a mobile app that generates user keys from a master key on demand during installation. Let's say that a key used in the mobile app is derived from this master key using the username or other user supplied value as salt. Such an implementation can make it possible for an attacker to retrieve the derived key by using the username or supplied user value as input.
-
-HKDFs or any other type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 aren't designed for low-entropy inputs like in the username example above. Therefore, password crackers can fairly efficiently crack massive amounts of passwords for KDFs that aren't purposefully designed to be slow and memory-intensive.
-A similar issue happens when using deprecated, risky or broken KDF- or password hashing algorithms known to the vulnerable to various types of attacks.
-Also, cryptographic algorithms (such as symmetric encryption or some MACs) expect a secret input of a given size.
-
-For example, AES uses a key of exactly 16 bytes. A naive implementation might use a username, a low entropy password or pin directly as an input key. Using a username, a low entropy password or pin as an input key has the following problems:
-
-- If the password is smaller than the key, the full key space isn't used. The remaining space is padded, often with spaces or null bytes.
-- A user-supplied password will realistically consist mostly of displayable and pronounceable characters. Therefore, only some of the possible 256 ASCII characters are used and entropy is decreased by approximately a factor of four.
-
-## Impact
-
-- **Risk of Brute-Force Attacks**: Improper Key derivation functions expose the app to brute force password- and secret cracking attacks, and key or dictionary attacks such as rainbow tables.
-- **Loss of Confidentiality**: Improper Key derivation may allow an attacker to guess or find the input and therefore steal the user's password or cryptographic key.
-- **Loss of Integrity**: Given that the attacker has access to the user's password or cryptographic key, the overall security of the app and mobile phone may be compromised.
-
-## Modes of Introduction
-
-- **Using static or predictable salt on low-entropy input**: Using an enumerable pin code or low entropy password together with a static or predictable salt makes it possible for the attacker to to pre-compute the hash value using dictionary attack, effectively disabling the protection that a salt would provide.
-- **Using user-supplied salt**: Using a low entropy salt will make it possible for an attacker to extract all derived keys through a KDF by supplying the low entropy salt as an argument.
-- **Using non-resource intensive algorithms on low-entropy input**: Using an enumerable pin code or low entropy password together with a HKDF makes it easy for password crackers to execute a preimage attack.
-- **Use a hash function as a general-purpose KDF**: In scenarios where the information used during key derivation is attacker-controlled, using a integrity based hash function (e.g from the SHA family) as KDF can expose the application to brute force or length-extension attacks.
-- **Using Deprecated, Risky or Broken Algorithms**: Relying on deprecated, risky or inherently broken cryptographic algorithms can result in the generation of weaker keys. As these algorithms often have vulnerabilities or support shorter key lengths, they are more susceptible to modern attacks, compromising the overall security of the app.
-
-## Mitigations
-
-- **Generate random salt using CSPRNGs with high entropy seeding**: Ensuring the use of strong, cryptographically secure PRNGs called CSPRNGs with high entropy seeding is essential for robust key security.
-- **Use Recommended and Approved algorithms that are fit for purpose**: In cases where the input is user-controlled, use key derivation functions such as Argon2, scrypt, bcrypt or PBKDF2 that provide a sufficient level of computational effort. Otherwise, ensure the input is thoroughly random using a recommended CSPRNG that guarantees high entropy seeding.
-- **Prefer HKDF and other KDFs that were designed specifically for key derivation**: HKDF and other KDFs specifically meant for key derivation will ensure the app isn't exposed to length-extension attacks.
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0021.md b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
index d49e5266956..936ab61ec9e 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0021.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
@@ -24,30 +24,3 @@ status: draft
 
 ---
 
-Choosing a deprecated, risky or broken hash algorithm, that is insufficiently collision resistant, may compromise the integrity and authenticity of data at rest and in transit by making the app vulnerable to collision attacks.
-
-when performing key derivation together with predictable input or in password hashing, the digest (or hash) of an improper implemented or used hash function may allow an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (second preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack/collision attack), given the actor can arbitrarily choose the inputs to be hashed and can do so a reasonable amount of times.
-
-What is regarded as "reasonable" varies by context and threat model, but in general, "reasonable" could cover any attack that is more efficient than brute force (i.e., on average, attempting half of all possible combinations). Note that some attacks might be more efficient than brute force but are still not regarded as achievable in the real world.
-
-Any algorithm that does not meet the above conditions will generally be considered risky or too "weak" for general use in hashing. When a collision attack is discovered and is found to be faster than a birthday attack, a hash function is often denounced as "broken". This is the case for MD5 and SHA-1.
-
-Another common issue is using a HKDF for key derivation with any type of integrity based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HKDF aren't designed for low-entropy inputs. Doing so will result in producing "weak" hashes that easily can be broken.
-
-## Impact
-
-- **Loss of Integrity and authenticity**: A deprecated, risky or broken hashing algorithm, may allow an attacker to compromise the integrity and authenticity of data at rest and in transit.
-- **Loss of Confidentiality**: A deprecated, risky or broken hashing algorithm may expose the preimage (input) and in so doing break the confidentiality.
-- **Risk of Brute-Force Attacks**: A deprecated, risky or broken hashing is susceptible to brute-force attacks.
-
-## Modes of Introduction
-
-- **using a deprecated, risky or broken hashing algorithm**: E.g: MD5 and SHA-1 have been identified to be vulnerable to collision attacks that are faster than a birthday attack. This means they are denounced as "broken".
-- **Using an insufficiently collision resistant hash**: Choosing a a hashing algorithm of insufficient length may result in loss of integrity or confidentiality.
-- **Using non-resource intensive algorithms on low-entropy input**: Using a integrity based hashing algorithm to hash low-entry input like pin numbers would make brute-force or dictionary attacks trivial.
-
-## Mitigations
-
-- **Choose collision resistant algorithm**: Choose an algorithm that is sufficiently collision resistant like the integrity algorithms SHA-256, SHA-384, SHA-512, BLAKE3 and the SHA-3 family
-- **Choose an algorithm with sufficient bit-lengths**: As our computers gets stronger, the hashes gets weaker, therefore, make sure that you can adjust the bit-length length of the algorithm of your choosing. When hashes are stored at rest, make sure to follow the software industry's long term recommendations (e.g: ["NIST: Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd)").
-- **Choose an algorithm fit for it's purpose**: When you want to ensure the data's integrity choose a integrity based algorithm. When you want to hash low-entropy input choose a password hash algorithm. Don't try to be clever. Follow recommendations and guidelines.
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
index 85f850dca62..d4d97c5e4e9 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
@@ -23,24 +23,4 @@ draft:
 status: draft
 
 ---
-Improper use of a MAC by e.g., generating a MAC over a message without the timestamp can make the application susceptible for replay attacks.
 
-Another common issue is using an HMAC with any type of general based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HMAC aren't designed for low-entropy inputs or low-entropy keys. Doing so will result in producing "weak" message digests that easily can be exploited.
-
-A deprecated HMAC implementation may contain bugs that could compromise the authenticity of the data.
-
-## Impact
-
-- **Loss of Integrity and authenticity**: Improper use of MAC may result in replay attacks or, in worse case, broken authentication that could compromise the integrity of a system.
-- **Loss of Confidentiality**: Using MAC for other purposes than authentication may lead to a complete loss of confidentiality.
-
-## Modes of Introduction
-
-- **Not including a timestamp**: Creating a MAC for message authentication without using a proper timestamp that can be validated for the possibility of replay-attacks.
-- **Using a MAC with low-entropy keys**: Using low-entropy inputs or low-entropy keys as input to a HMAC.
-
-## Mitigations
-
-- **Use MAC with a timestamp**: Generate the MAC over a message with the timestamp included. This should protect the application against replay attacks within a reasonable amount of time. Reasonable, meaning a time frame that is short enough to prevent an attacker from sending an identical message and long enough to allow the message to be sent and digested.
-- **Do not use HMAC together with a low-entropy key**: Ensure the keys used are generated using cryptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks.
-- **Do not use deprecated HMAC implementations**: Deprecated HMAC implementations could contain errors that allow for collision attacks. Therefore, only use recommended libraries and functions.
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0025.md b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
index 1f6021faff2..6d8a0f60dc0 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0025.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
@@ -20,20 +20,4 @@ draft:
 status: draft
 
 ---
-Using deprecated, risky or broken algorithms for the purpose of ensuring accountability and non-reputation through the use of signatures could make it possible for an attacker to execute digital signature forgery and compromise the integrity and authenticity of the data at rest and in transit.
 
-## Impact
-
-- **Loss of Integrity and authenticity**: Signature forgery may allow the attacker to compromise the integrity and authenticity of the data by signing the data on behalf of another entity.
-- **Loss of accountability**: Signature forgery allows for plausible deniability and diminishes accountability.
-
-## Modes of Introduction
-
-- **Using a deprecated, risky or broken hashing algorithm**: e.g. MD5 and SHA-1 have been identified to be vulnerable for collision attacks that are faster than a birthday attack. Because of this they are denounced as "broken".
-- **Using a insufficiently collision resistant hash**: Choosing a hashing algorithm of insufficient length may result in loss of integrity or confidentiality.
-
-## Mitigations
-
-- **Choose collision resistant algorithm**: Choose a signature algorithm that is sufficiently collision resistant like RSA (3072 bits and higher), ECDSA with NIST P-384 or EdDSA with Edwards448.
-
-- **Choose a signing scheme that make use of algorithms with sufficient bit-lengths**: As our computers gets stronger, previously generated hashes get weaker, therefore, make sure that you can adjust the bit-length length (strength) of the algorithm of your choosing. When signatures are stored at rest, make sure to follow the software industry's long term recommendations (e.g. ["NIST: Transition to Post-Quantum Cryptography Standards"](https://csrc.nist.gov/pubs/ir/8547/ipd)).

From 9e569eed656a1882f0f39da9e520d788b511bf1a Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Thu, 10 Jul 2025 09:06:52 +0200
Subject: [PATCH 090/117] Revert status in MASWE-0021 from draft to placeholder
 and rm cwe link which is already in mappings

---
 weaknesses/MASVS-CRYPTO/MASWE-0021.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0021.md b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
index 936ab61ec9e..4b96bf2e88b 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0021.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
@@ -12,7 +12,6 @@ mappings:
 refs:
 - https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality
 - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf
-- https://cwe.mitre.org/data/definitions/328.html
 - https://en.wikipedia.org/wiki/Collision_attack
 - https://csrc.nist.gov/pubs/ir/8547/ipd
 draft:
@@ -20,7 +19,7 @@ draft:
     sensitive context may compromise data integrity and authenticity.
   topics:
   - Broken hashing algorithms (e.g. MD5, SHA1, etc.)
-status: draft
+status: placeholder
 
 ---
 

From 27283b0f21ac23114420fb9710f40ace5cdd52d8 Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Thu, 10 Jul 2025 09:08:14 +0200
Subject: [PATCH 091/117] Revert status in MASWE-0024 from draft to placeholder

---
 weaknesses/MASVS-CRYPTO/MASWE-0024.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
index d4d97c5e4e9..24401576ca3 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
@@ -20,7 +20,7 @@ draft:
   description: Improper use of MAC. E.g. allowing the user to control the input.
     may expose cryptographic vulnerabilities, affecting data integrity.
   topics: null
-status: draft
+status: placeholder
 
 ---
 

From 010fa9f6f37ef6bba4497c8fd7de10661a7a684b Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Thu, 10 Jul 2025 09:09:36 +0200
Subject: [PATCH 092/117] Revert status in MASWE-0025 from draft to placeholder

---
 weaknesses/MASVS-CRYPTO/MASWE-0025.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0025.md b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
index 6d8a0f60dc0..7cc762225a6 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0025.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
@@ -17,7 +17,7 @@ refs:
 draft:
   description: The use of algorithms with insufficient strength for signatures such as SHA1withRSA, etc. in a security-sensitive context should be avoided to ensure the integrity and authenticity of the data.
   topics: null
-status: draft
+status: placeholder
 
 ---
 

From 230d5a67639ecce7ad532bf4af3a99ca21bd3d14 Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Thu, 10 Jul 2025 09:43:15 +0200
Subject: [PATCH 093/117] rm glossary which will be added separately

---
 Document/0x08c-Glossary.md | 58 --------------------------------------
 1 file changed, 58 deletions(-)
 delete mode 100644 Document/0x08c-Glossary.md

diff --git a/Document/0x08c-Glossary.md b/Document/0x08c-Glossary.md
deleted file mode 100644
index 69a961f7331..00000000000
--- a/Document/0x08c-Glossary.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-hide: toc
-title: Glossary
----
-
-## Cryptographic Terms
-
-### Block cipher
-
-A symmetric encryption algorithm that encrypts data in fixed-size blocks, rather than one bit at a time like stream ciphers.
-
-### Broken
-
-The meaning depends on the context.
-
-A broken cryptographic hash algorithm is a function that is denounced as broken because a collision attack exist that is faster to execute then a birthday attack ([Wikipedia, "2025.02.19"](https://en.wikipedia.org/wiki/Collision_attack "Collision attack")).
-
-A cryptographic mode of operation is broken if it, when implemented correctly, still faces the risk from known attacks that can break the confidentiality of the encrypted data.
-
-### Deprecated
-
-When mentioned as a cryptographic term it means a mode of operation, algorithm or cryptographic function that no longer is recommended to be used for certain cryptographic operations. The function may still be recommended for specific other cryptographic operations even when deprecated.
-
-### Improper
-
-Used as a catch-all term to cover security behaviors that are either missing or insufficient/incorrect.
-
-### Insufficient
-
-According to MITRE: _A general term used to describe when a security property or behavior can vary in strength on a continuous or sliding scale, instead of a discrete scale. The continuous scale may vary depending on the context and risk tolerance. For example, the requirements for randomness may vary between a random selection for a greeting message versus the generation of a military-strength key. On the other hand, a weakness that allows a buffer overflow is always incorrect - there is not a sliding scale that varies across contexts_ ([MITRE, "2024.07.07"](https://cwe.mitre.org/documents/glossary/index.html#Insufficient "Glossary")).
-
-### KDF - key derivation function
-
-KDF stands for key derivation function which is a cryptographic algorithm that derives one or more secret keys from a secret value such as a master key, a password, or a passphrase using a pseudorandom function (which typically uses a cryptographic hash function or block cipher).
-
-### Master key
-
-A key that's used to protect other keys, either by encrypting them or by deriving new keys from it.
-
-### Mode of operation
-
-A mode of operation specifies how to repeatedly encrypt or decrypt a single block of data using a block cipher.
-
-### Risk
-
-Risk refers to the ISO 3000 definition: Risk = "effect of uncertainty on objectives".
-
-### Risky
-
-A risky cryptographic hash algorithm carries with it an "effect of uncertainty on the objectives" that the specific algorithm must satisfy. The algorithm is therefore said to be risky when used under certain circumstances, and because of that, carries with it the risk of being compromised in an attack when used improperly. The same can be considered when referring to a risky encryption mode of operation.
-
-### Stream ciphers
-
-A type of symmetric encryption algorithm that encrypts data one bit or byte at a time.
-
-### Strength
-
-According to NIST. A number associated with the amount of work (that is, the number of operations) that is required to break a cryptographic algorithm or system. If 2N execution operations of the algorithm (or system) are required to break the cryptographic algorithm, then the security strength is N bits ([NIST, security strength](https://csrc.nist.gov/glossary/term/security_strength "security strength")).

From 4d8cde49e897177d6f022449ac58e09f0ee7b3a2 Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Thu, 10 Jul 2025 10:01:08 +0200
Subject: [PATCH 094/117] fix run.sh output redirection for semgrep command

---
 demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/run.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 mode change 100644 => 100755 demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/run.sh

diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/run.sh b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/run.sh
old mode 100644
new mode 100755
index bd90759c309..84d5857cbb6
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/run.sh
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/run.sh
@@ -1 +1 @@
-NO_COLOR=true semgrep -c ../../../../rules/mastg-android-key-generation-with-insufficient-key-length.yml ./MastgTest_reversed.java --text -o output.txt
\ No newline at end of file
+NO_COLOR=true semgrep -c ../../../../rules/mastg-android-key-generation-with-insufficient-key-length.yml ./MastgTest_reversed.java --text > output.txt
\ No newline at end of file

From ddee2d8da5a9252c44e1aa947498b3054cfe96ba Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sun, 13 Jul 2025 19:52:59 +0200
Subject: [PATCH 095/117] Update weaknesses/MASVS-CRYPTO/MASWE-0009.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 weaknesses/MASVS-CRYPTO/MASWE-0009.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0009.md b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
index 98e58e26357..18278d6ab0f 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0009.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
@@ -34,7 +34,7 @@ The digest (or hash) of an improper implemented or used hash function may allow
 
 ## Modes of Introduction
 
-- **Inadequate Entropy During Key Generation**: Using a poor source of randomness can lead to predictable cryptographic keys. If the randomness lacks sufficient entropy, the generated keys may be easier for attackers to guess or recreate, compromising the security of the system.
+- **Insufficient Entropy**: Using a source of randomness with insufficient entropy can lead to predictable cryptographic keys.
 - **Insufficient Key Length**: Cryptographic keys that are too short provide inadequate security. For example, keys shorter than recommended lengths for modern algorithms may be vulnerable to brute force attacks, making them easier for attackers to break.
 - **Using Outdated, Risky or Broken Algorithms**: Relying on deprecated, risky or inherently broken cryptographic algorithms can result in the generation of weaker keys. As these algorithms often have vulnerabilities or support shorter key lengths, they are more susceptible to modern attacks, compromising the overall security of the app.
 

From d00d9f22f95fe5181632ca84bd58ec3d989b2513 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sun, 13 Jul 2025 19:55:14 +0200
Subject: [PATCH 096/117] Update weaknesses/MASVS-CRYPTO/MASWE-0009.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 weaknesses/MASVS-CRYPTO/MASWE-0009.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0009.md b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
index 18278d6ab0f..4b250d25835 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0009.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
@@ -36,7 +36,7 @@ The digest (or hash) of an improper implemented or used hash function may allow
 
 - **Insufficient Entropy**: Using a source of randomness with insufficient entropy can lead to predictable cryptographic keys.
 - **Insufficient Key Length**: Cryptographic keys that are too short provide inadequate security. For example, keys shorter than recommended lengths for modern algorithms may be vulnerable to brute force attacks, making them easier for attackers to break.
-- **Using Outdated, Risky or Broken Algorithms**: Relying on deprecated, risky or inherently broken cryptographic algorithms can result in the generation of weaker keys. As these algorithms often have vulnerabilities or support shorter key lengths, they are more susceptible to modern attacks, compromising the overall security of the app.
+- **Using Risky or Broken Algorithms**: Relying on deprecated, risky or inherently broken cryptographic algorithms can result in the generation of weaker keys. As these algorithms often have vulnerabilities or support shorter key lengths, they are more susceptible to modern attacks, compromising the overall security of the app.
 
 ## Mitigations
 

From 43e13ddcc86b157e0b541364b3597d2ba04cf7dd Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sun, 13 Jul 2025 19:56:32 +0200
Subject: [PATCH 097/117] Update weaknesses/MASVS-CRYPTO/MASWE-0009.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 weaknesses/MASVS-CRYPTO/MASWE-0009.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0009.md b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
index 4b250d25835..7f80a3b806c 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0009.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
@@ -29,7 +29,7 @@ The digest (or hash) of an improper implemented or used hash function may allow
 ## Impact
 
 - **Risk of Brute-Force Attacks**: Improper key generation, whether due to shorter key length or predictable random number generator (PRNG) inputs, increases the risk of brute-force attacks. Attackers can more easily guess or systematically try possible keys until they find the correct one.
-- **Loss of Confidentiality**: Encryption relies on strong keys to maintain the confidentiality of sensitive data. Weak seed values can allow attackers to decrypt and access confidential information, leading to unauthorized disclosure and potential data breaches.
+- **Loss of Confidentiality**: Encryption relies on strong keys to maintain the confidentiality of sensitive data. Seed values with insufficient entropy can allow attackers to decrypt and access confidential information, leading to unauthorized disclosure and potential data breaches.
 - **Loss of Integrity**: Improper key generation can compromise data integrity, allowing attackers to exploit vulnerabilities and potentially alter or tamper with the information without detection.
 
 ## Modes of Introduction

From 4c8ff30e2ce99316dfa22286cc7cc01b18060a51 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sun, 13 Jul 2025 19:59:09 +0200
Subject: [PATCH 098/117] Update weaknesses/MASVS-CRYPTO/MASWE-0009.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 weaknesses/MASVS-CRYPTO/MASWE-0009.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0009.md b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
index 7f80a3b806c..bb24ecb3472 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0009.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
@@ -23,7 +23,7 @@ status: new
 
 In cryptography, the security strength is heavily influenced by the methods used to generate cryptographic keys. One critical aspect is the key size, also known as the key length, which is measured in bits and must comply with the latest security best practices. Encryption algorithms that use insufficient key sizes are vulnerable to attack, while longer keys typically result in more complex encryption.
 
-However, even with an appropriately sized key, the security of the encryption can be compromised if the key generation process itself is flawed. For example using a pseudorandom number generator (PRNG) not meant for cryptographic purposes can undermine cryptographic security by generating predictable, weak or low-entropy keys. This reduces the effectiveness of the key length and makes it easier for attackers to guess or reproduce keys. Weak PRNG seeds can also produce repetitive patterns, leading to further vulnerabilities. Ensuring the use of strong, cryptographically secure PRNGs called CSPRNGs with high entropy seeding is essential for robust key security.
+However, even with a sufficiently large key size, the security of the encryption can be compromised if the key generation process is flawed. Failing to use strong, cryptographically secure pseudorandom number generators (CSPRNGs) with sufficient entropy can generate predictable keys that are easier for attackers to guess or reproduce and that are susceptible to repetitive patterns.
 The digest (or hash) of an improper implemented or used hash function may allow an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack).
 
 ## Impact

From 0718d360dd5bc2d30ef70d75527749f7b1c347f1 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sun, 13 Jul 2025 20:02:50 +0200
Subject: [PATCH 099/117] Update weaknesses/MASVS-CRYPTO/MASWE-0009.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 weaknesses/MASVS-CRYPTO/MASWE-0009.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0009.md b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
index bb24ecb3472..4ae3a54092c 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0009.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0009.md
@@ -24,7 +24,6 @@ status: new
 In cryptography, the security strength is heavily influenced by the methods used to generate cryptographic keys. One critical aspect is the key size, also known as the key length, which is measured in bits and must comply with the latest security best practices. Encryption algorithms that use insufficient key sizes are vulnerable to attack, while longer keys typically result in more complex encryption.
 
 However, even with a sufficiently large key size, the security of the encryption can be compromised if the key generation process is flawed. Failing to use strong, cryptographically secure pseudorandom number generators (CSPRNGs) with sufficient entropy can generate predictable keys that are easier for attackers to guess or reproduce and that are susceptible to repetitive patterns.
-The digest (or hash) of an improper implemented or used hash function may allow an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack).
 
 ## Impact
 

From 1d55c289e7e9d3c9803e36abf1160c64c3b23268 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sun, 13 Jul 2025 20:05:01 +0200
Subject: [PATCH 100/117] Update Document/0x04g-Testing-Cryptography.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index a1bb829cac8..414efeb75fd 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -147,7 +147,7 @@ Unfortunately, "brute-force" attacks are quite liable to succeed where users sel
 In cases where the input is user-controlled, use password hashing algorithm like Argon2, scrypt, bcrypt or PBKDF2 as a key derivation function to provide a sufficient level of computational effort.
 When using a password hashing algorithm as a KDF, also ensure to choose an appropriate iteration count that can provide sufficient computational efforts. Meaning that they make password or secret cracking attacks infeasible or expensive. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to implementation algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2"). Also see ["OWASP Password Storage Cheat Sheet"](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction "OWASP Cheat Sheet Series: Password Storage Cheat Sheet") for recommendation on iteration count when using key derivation functions using Argon2, scrypt, bcrypt or PBKDF2.
 
-### Random Number Generators
+### Improper Random Number Generation
 
 It is fundamentally impossible to produce truly random numbers on any deterministic device. Pseudo-random number generators (PRNG) compensate for this by producing a stream of pseudo-random numbers - a stream of numbers that appear as if they were randomly generated. The quality of the generated numbers varies with the type of algorithm used. Cryptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks (e.g. it is statistically infeasible to predict the next number produced).
 

From 8e2bbab5f0deece1c25e3a217cd30df0eb0d55ff Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sun, 13 Jul 2025 20:05:24 +0200
Subject: [PATCH 101/117] Update Document/0x04g-Testing-Cryptography.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 414efeb75fd..98a17e82fe2 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -171,7 +171,7 @@ In all implementations of cryptography, you need to ensure that the following al
 - Working keys (like intermediary/derived keys in AES/DES/Rijndael) are properly removed from memory after consumption or in case of error.
 - The inner state of a cipher should be removed from memory as soon as possible.
 
-### Inadequate AES Configuration
+### Improper Encryption
 
 Advanced Encryption Standard (AES) is the widely accepted standard for symmetric encryption in mobile apps. It's an iterative block cipher that is based on a series of linked mathematical operations. AES performs a variable number of rounds on the input, each of which involve substitution and permutation of the bytes in the input block. Each round uses a 128-bit round key which is derived from the original AES key.
 

From 203e04db384d23b3ed5d4fce40282d0a962fb7ff Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sun, 13 Jul 2025 20:06:06 +0200
Subject: [PATCH 102/117] Update Document/0x04g-Testing-Cryptography.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 98a17e82fe2..a1946cb0de1 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -177,7 +177,7 @@ Advanced Encryption Standard (AES) is the widely accepted standard for symmetric
 
 As of this writing, no efficient cryptanalytic attacks against AES have been discovered. However, implementation details and configurable parameters such as the block cipher mode leave some margin for error.
 
-#### Inadequate Block Cipher Mode
+#### Broken Block Cipher Modes
 
 Block-based encryption is performed upon discrete input blocks (for example, AES has 128-bit blocks). If the plaintext is larger than the block size, the plaintext is internally split up into blocks of the given input size and encryption is performed on each block. A block cipher mode of operation (or block mode) determines if the result of encrypting the previous block impacts subsequent blocks.
 

From 446a76dceccae60e2fb4e7813872fa55073df8b6 Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sun, 13 Jul 2025 20:06:29 +0200
Subject: [PATCH 103/117] Update Document/0x04g-Testing-Cryptography.md

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
---
 Document/0x04g-Testing-Cryptography.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index a1946cb0de1..f51c84b49c8 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -155,7 +155,7 @@ PRNGs can be vulnerable when developers use a regular PRNG for cryptographic pur
 
 Mobile SDKs offer standard implementations of PRNG algorithms that produce numbers with sufficient artificial randomness. We'll introduce the available APIs in the Android and iOS-specific sections.
 
-### Weak, Risky or Broken Hashing
+### Improper Hashing
 
 Make sure to choose a hash function that is built for the purpose you intend it for.
 When hashes are needed for integrity checks, choose an algorithm that is sufficiently collision resistant, such as the integrity algorithms SHA-256, SHA-384, SHA-512, BLAKE3, and the SHA-3 family. Choosing a risky or broken algorithm may compromise the integrity and authenticity of data at rest and in transit. Also keep in mind that hash functions used for integrity checks, like the SHA series, should not be used for key derivation together with predictable input or in password hashing.

From 28e48dd01c9c7c32efdd67e8b051b9dd948b166e Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sun, 13 Jul 2025 22:46:21 +0200
Subject: [PATCH 104/117] Create .lycheeignore

---
 .lycheeignore | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 .lycheeignore

diff --git a/.lycheeignore b/.lycheeignore
new file mode 100644
index 00000000000..460c145a8e4
--- /dev/null
+++ b/.lycheeignore
@@ -0,0 +1,3 @@
+# ignore these false positives from the link checker
+
+https://pure.tugraz.at/ws/portalfiles/portal/23858147/main.pdf

From dcf36f9abb1aa9ec38c19cf8ef134c31ec8e5ffa Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sun, 13 Jul 2025 22:50:52 +0200
Subject: [PATCH 105/117] Delete .lycheeignore

---
 .lycheeignore | 3 ---
 1 file changed, 3 deletions(-)
 delete mode 100644 .lycheeignore

diff --git a/.lycheeignore b/.lycheeignore
deleted file mode 100644
index 460c145a8e4..00000000000
--- a/.lycheeignore
+++ /dev/null
@@ -1,3 +0,0 @@
-# ignore these false positives from the link checker
-
-https://pure.tugraz.at/ws/portalfiles/portal/23858147/main.pdf

From e245e6624e050c5bdbb13c4721be87164bbacf9d Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sun, 13 Jul 2025 22:52:30 +0200
Subject: [PATCH 106/117] Ignore false positive

---
 .markdownlinkcheck.json | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/.markdownlinkcheck.json b/.markdownlinkcheck.json
index 07052b6db26..d09069fbffc 100644
--- a/.markdownlinkcheck.json
+++ b/.markdownlinkcheck.json
@@ -1,11 +1,13 @@
 {
-    "ignorePatterns": [],
+    "ignorePatterns": [
+        "https://pure.tugraz.at/ws/portalfiles/portal/23858147/main.pdf"
+    ],
     "httpHeaders": [{
         "urls": [
-            "https://", "http://"
+            "https://", "http://"         
         ],
         "headers": {
             "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0"
         }
     }]
-}
\ No newline at end of file
+}

From 9815f0b1fb0a2b71a4112f7e471011ba62dd3b7b Mon Sep 17 00:00:00 2001
From: Uncle Joe <1244005+sydseter@users.noreply.github.com>
Date: Sun, 13 Jul 2025 22:54:48 +0200
Subject: [PATCH 107/117] Update .markdownlinkcheck.json

---
 .markdownlinkcheck.json | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/.markdownlinkcheck.json b/.markdownlinkcheck.json
index d09069fbffc..6b54e4f11b1 100644
--- a/.markdownlinkcheck.json
+++ b/.markdownlinkcheck.json
@@ -1,7 +1,5 @@
 {
-    "ignorePatterns": [
-        "https://pure.tugraz.at/ws/portalfiles/portal/23858147/main.pdf"
-    ],
+    "ignorePatterns": [ ],
     "httpHeaders": [{
         "urls": [
             "https://", "http://"         

From b21f2e82bf13d42097f372828f8114338be2202a Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Mon, 14 Jul 2025 09:25:34 +0200
Subject: [PATCH 108/117] Apply suggestions from code review

---
 Document/0x04g-Testing-Cryptography.md         |  2 +-
 .../MASTG-DEMO-0022/MASTG-DEMO-0022.md         |  8 ++++----
 .../MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt  | 18 +++++++++---------
 .../MASVS-CRYPTO/MASTG-DEMO-0022/run.sh        |  2 +-
 .../MASTG-DEMO-0023/MASTG-DEMO-0023.md         |  8 ++++----
 .../MASVS-CRYPTO/MASTG-DEMO-0023/run.sh        |  2 +-
 .../MASTG-DEMO-0015/MASTG-DEMO-0015.md         |  2 +-
 .../MASTG-DEMO-0016/MASTG-DEMO-0016.md         |  2 +-
 .../MASTG-DEMO-0018/MASTG-DEMO-0018.md         |  2 +-
 .../identify-security-relevant-contexts.md     |  2 +-
 ...generation-with-insufficient-key-length.yml |  4 ++--
 ...tg-android-risky-encryption-algorithms.yaml |  6 +++---
 .../mastg-android-risky-encryption-modes.yaml  |  6 +++---
 techniques/android/MASTG-TECH-0014.md          |  2 +-
 .../android/MASVS-CRYPTO/MASTG-TEST-0221.md    |  8 ++++----
 .../android/MASVS-CRYPTO/MASTG-TEST-0232.md    |  8 ++++----
 tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0210.md | 12 ++++++------
 tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md | 10 +++++-----
 weaknesses/MASVS-CRYPTO/MASWE-0010.md          |  2 +-
 weaknesses/MASVS-CRYPTO/MASWE-0021.md          |  4 ++--
 weaknesses/MASVS-CRYPTO/MASWE-0024.md          | 15 +++++++++++----
 weaknesses/MASVS-CRYPTO/MASWE-0025.md          |  4 ++--
 weaknesses/MASVS-CRYPTO/MASWE-0027.md          |  4 ++--
 23 files changed, 70 insertions(+), 63 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index f51c84b49c8..299ab800f1b 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -74,7 +74,7 @@ For more information on algorithm choice and best practices, see the following r
 
 ## Post-Quantum
 
-### Public-key encryption algorithms
+### Public-Key Encryption Algorithms
 
 In 2024, NIST approved CRYSTALS-Kyber as a post-quantum key encapsulation mechanism (KEM) for establishing a shared secret over a public channel. This shared secret can then be used with symmetric-key algorithms for encryption and decryption.
 
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MASTG-DEMO-0022.md b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MASTG-DEMO-0022.md
index babab99ee7c..64a8b8a2eed 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MASTG-DEMO-0022.md
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MASTG-DEMO-0022.md
@@ -1,6 +1,6 @@
 ---
 platform: android
-title: Uses of Deprecated, Risky or Broken Symmetric Encryption Algorithms in Cipher with semgrep
+title: Uses of Broken Symmetric Encryption Algorithms in Cipher with semgrep
 id: MASTG-DEMO-0022
 code: [kotlin]
 test: MASTG-TEST-0221
@@ -16,18 +16,18 @@ The code snippet below shows sample code contains use of insecure encryption alg
 
 Let's run our @MASTG-TOOL-0110 rule against the sample code.
 
-{{ ../../../../rules/mastg-android-risky-encryption-algorithms.yaml }}
+{{ ../../../../rules/mastg-android-broken-encryption-algorithms.yaml }}
 
 {{ run.sh }}
 
 ### Observation
 
-The rule has identified two instances in the code file where deprecated, risky or broken encryption algorithms are used. The specified line numbers can be located in the reverse-engineered code for further investigation and remediation.
+The rule has identified several instances in the code file where broken encryption algorithms are used. The specified line numbers can be located in the reverse-engineered code for further investigation and remediation.
 
 {{ output.txt }}
 
 ### Evaluation
 
-The test fails due to the use of deprecated, risky or broken encryption algorithms, specifically DES, 3DES, RC4 and Blowfish.
+The test fails due to the use of broken encryption algorithms, specifically DES, 3DES, RC4 and Blowfish.
 
 See @MASTG-TEST-0221 for more information.
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt
index a2b90aecd36..3da7a3b3f3d 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/MastgTest.kt
@@ -16,14 +16,14 @@ class MastgTest(private val context: Context) {
     // Vulnerable encryption using DES (broken algorithm)
     fun vulnerableDesEncryption(data: String): String {
         try {
-            // Insufficient key for DES
+            // Insufficient key length for DES
             val keyBytes = ByteArray(8)
             SecureRandom().nextBytes(keyBytes)
             val keySpec = DESKeySpec(keyBytes)
             val keyFactory = SecretKeyFactory.getInstance("DES")
             val secretKey: Key = keyFactory.generateSecret(keySpec)
 
-            // Risky encryption algorithm (DES)
+            // Broken encryption algorithm (DES)
             val cipher = Cipher.getInstance("DES")
             cipher.init(Cipher.ENCRYPT_MODE, secretKey)
 
@@ -44,7 +44,7 @@ class MastgTest(private val context: Context) {
             val keyFactory = SecretKeyFactory.getInstance("DESede")
             val secretKey: Key = keyFactory.generateSecret(keySpec)
 
-            // Risky encryption algorithm (3DES)
+            // Broken encryption algorithm (3DES)
             val cipher = Cipher.getInstance("DESede")
             cipher.init(Cipher.ENCRYPT_MODE, secretKey)
 
@@ -72,15 +72,15 @@ class MastgTest(private val context: Context) {
         }
     }
 
-    // Risky encryption using Blowfish (risky algorithm)
+    // Encryption using Blowfish (broken algorithm)
     fun vulnerableBlowfishEncryption(data: String): String {
         return try {
-            // insufficient key for Blowfish (risky, small key size)
+            // Insufficient key length for Blowfish
             val keyBytes = ByteArray(8) // Only 8 bytes (64-bit key) - not secure
             SecureRandom().nextBytes(keyBytes)
             val secretKey: SecretKey = SecretKeySpec(keyBytes, "Blowfish")
 
-            // Risky encryption algorithm (Blowfish)
+            // Broken encryption algorithm (Blowfish)
             val cipher = Cipher.getInstance("Blowfish")
             cipher.init(Cipher.ENCRYPT_MODE, secretKey)
 
@@ -98,13 +98,13 @@ class MastgTest(private val context: Context) {
         // Encrypt with broken DES
         val desEncryptedString = vulnerableDesEncryption(sensitiveString)
 
-        // Encrypt with risky 3DES
+        // Broken with risky 3DES
         val tripleDesEncryptedString = vulnerable3DesEncryption(sensitiveString)
 
-        // Encrypt with deprecated RC4
+        // Encrypt with broken RC4
         val rc4EncryptedString = vulnerableRc4Encryption(sensitiveString)
 
-        // Encrypt with risky Blowfish
+        // Encrypt with broken Blowfish
         val blowfishEncryptedString = vulnerableBlowfishEncryption(sensitiveString)
 
         // Returning the encrypted results
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/run.sh b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/run.sh
index 31fdf2d0fda..87a7781fd2f 100755
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/run.sh
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/run.sh
@@ -1 +1 @@
-NO_COLOR=true semgrep -c ../../../../rules/mastg-android-risky-encryption-algorithms.yaml ./MastgTest_reversed.java --text > output.txt
\ No newline at end of file
+NO_COLOR=true semgrep -c ../../../../rules/mastg-android-broken-encryption-algorithms.yaml ./MastgTest_reversed.java --text > output.txt
\ No newline at end of file
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/MASTG-DEMO-0023.md b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/MASTG-DEMO-0023.md
index 7adc18c526c..e53b35533d8 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/MASTG-DEMO-0023.md
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/MASTG-DEMO-0023.md
@@ -1,6 +1,6 @@
 ---
 platform: android
-title: Uses of Risky or Broken Encryption Modes in Cipher with semgrep
+title: Uses of Broken Encryption Modes in Cipher with semgrep
 id: MASTG-DEMO-0023
 code: [kotlin]
 test: MASTG-TEST-0232
@@ -8,7 +8,7 @@ test: MASTG-TEST-0232
 
 ### Sample
 
-The code snippet below shows sample code contains use of risky or broken encryption modes.
+The code snippet below shows sample code contains use of broken encryption modes.
 
 {{ MastgTest.kt # MastgTest_reversed.java }}
 
@@ -16,13 +16,13 @@ The code snippet below shows sample code contains use of risky or broken encrypt
 
 Let's run our @MASTG-TOOL-0110 rule against the sample code.
 
-{{ ../../../../rules/mastg-android-risky-encryption-modes.yaml }}
+{{ ../../../../rules/mastg-android-broken-encryption-modes.yaml }}
 
 {{ run.sh }}
 
 ### Observation
 
-The rule has identified six instances in the code file where risky or broken encryption modes are used. The specified line numbers can be located in the reverse-engineered code for further investigation and remediation.
+The rule has identified six instances in the code file where broken encryption modes are used. The specified line numbers can be located in the reverse-engineered code for further investigation and remediation.
 
 {{ output.txt }}
 
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/run.sh b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/run.sh
index 98abe4ea041..c82850c9c85 100755
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/run.sh
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/run.sh
@@ -1 +1 @@
-NO_COLOR=true semgrep -c ../../../../rules/mastg-android-risky-encryption-modes.yaml ./MastgTest_reversed.java --text > output.txt
\ No newline at end of file
+NO_COLOR=true semgrep -c ../../../../rules/mastg-android-broken-encryption-modes.yaml ./MastgTest_reversed.java --text > output.txt
\ No newline at end of file
diff --git a/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0015/MASTG-DEMO-0015.md b/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0015/MASTG-DEMO-0015.md
index 3ba9ca6b40e..46d92ea4ad4 100644
--- a/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0015/MASTG-DEMO-0015.md
+++ b/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0015/MASTG-DEMO-0015.md
@@ -1,6 +1,6 @@
 ---
 platform: ios
-title: Uses of Risky or Broken Hashing Algorithms in CommonCrypto with r2
+title: Uses of Broken Hashing Algorithms in CommonCrypto with r2
 code: [swift]
 id: MASTG-DEMO-0015
 test: MASTG-TEST-0211
diff --git a/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0016/MASTG-DEMO-0016.md b/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0016/MASTG-DEMO-0016.md
index 1ea6e84e52d..6ac9e7e2b61 100644
--- a/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0016/MASTG-DEMO-0016.md
+++ b/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0016/MASTG-DEMO-0016.md
@@ -1,6 +1,6 @@
 ---
 platform: ios
-title: Uses of Risky or Broken Hashing Algorithms in CryptoKit with r2
+title: Uses of Broken Hashing Algorithms in CryptoKit with r2
 code: [swift]
 id: MASTG-DEMO-0016
 test: MASTG-TEST-0211
diff --git a/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0018/MASTG-DEMO-0018.md b/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0018/MASTG-DEMO-0018.md
index 6664524b2b4..7b993eccb3b 100644
--- a/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0018/MASTG-DEMO-0018.md
+++ b/demos/ios/MASVS-CRYPTO/MASTG-DEMO-0018/MASTG-DEMO-0018.md
@@ -1,6 +1,6 @@
 ---
 platform: ios
-title: Uses of Deprecated, Risky or Broken Encryption Algorithms in CommonCrypto with r2
+title: Uses of Broken Encryption Algorithms in CommonCrypto with r2
 code: [swift]
 id: MASTG-DEMO-0018
 test: MASTG-TEST-0210
diff --git a/prerequisites/identify-security-relevant-contexts.md b/prerequisites/identify-security-relevant-contexts.md
index bf44a21ecba..20f4a4fe18e 100644
--- a/prerequisites/identify-security-relevant-contexts.md
+++ b/prerequisites/identify-security-relevant-contexts.md
@@ -4,7 +4,7 @@ When developing a mobile application, it's crucial to accurately identify and ha
 
 Properly distinguishing security-relevant contexts helps in minimizing false positives during security testing. False positives can divert attention from real issues and waste valuable resources. Here are some common scenarios:
 
-- **Random Number Generation**: Using predictable random number generators can be a serious security flaw in contexts like authentication or encryption key generation. However, not all uses of random numbers are security-sensitive. For instance, using a less robust random number generator for non-security purposes like shuffling a list of items in a game is generally acceptable.
+- **Random Number Generation**: Using random number generators with insufficient entropy can be a serious security flaw in contexts like authentication or encryption key generation, as predictable values can be exploited by attackers. However, not all uses of random numbers are security-sensitive. For example, using a less robust generator for non-security purposes, such as shuffling items in a game, is generally acceptable.
 
 - **Hashing**: Hashing is often used in security for storing passwords or ensuring data integrity. However, hashing a non-sensitive value, like a device's screen resolution for analytics, isn't a security concern.
 
diff --git a/rules/mastg-android-key-generation-with-insufficient-key-length.yml b/rules/mastg-android-key-generation-with-insufficient-key-length.yml
index 3a71b4e3520..00207e9c622 100644
--- a/rules/mastg-android-key-generation-with-insufficient-key-length.yml
+++ b/rules/mastg-android-key-generation-with-insufficient-key-length.yml
@@ -1,10 +1,10 @@
 rules:
-  - id: insufficient_key_size
+  - id: mastg-android-insufficient-key-length
     severity: WARNING
     languages:
       - java
     metadata:
-      summary: This rule looks for methods that create a short key size in encryption algorithms.
+      summary: This rule looks for methods that create keys with insufficient length in encryption algorithms.
     message: "[MASVS-CRYPTO] Make sure that the key size is according to security best practices"
     pattern-either:
       - pattern: |
diff --git a/rules/mastg-android-risky-encryption-algorithms.yaml b/rules/mastg-android-risky-encryption-algorithms.yaml
index 10f93230130..aef0b7b8e54 100644
--- a/rules/mastg-android-risky-encryption-algorithms.yaml
+++ b/rules/mastg-android-risky-encryption-algorithms.yaml
@@ -1,9 +1,9 @@
 rules:
-  - id: risky-encryption-algorithms
+  - id: mastg-android-broken-encryption-algorithms
     languages:
       - java
     severity: WARNING
     metadata:
-      summary: This rule looks for risky or broken encryption algorithms.
-    message: "[MASVS-CRYPTO-1] Risky or broken encryption algorithms found in use."
+      summary: This rule looks for broken encryption algorithms.
+    message: "[MASVS-CRYPTO-1] Broken encryption algorithms found in use."
     pattern-regex: Cipher\.getInstance\("?(DES|DESede|RC4|Blowfish)(/[A-Za-z0-9]+(/[A-Za-z0-9]+)?)?"?\)
diff --git a/rules/mastg-android-risky-encryption-modes.yaml b/rules/mastg-android-risky-encryption-modes.yaml
index 2e710ee21d6..de2fbdc0809 100644
--- a/rules/mastg-android-risky-encryption-modes.yaml
+++ b/rules/mastg-android-risky-encryption-modes.yaml
@@ -1,11 +1,11 @@
 rules:
-  - id: risky-encryption-modes
+  - id: mastg-android-broken-encryption-modes
     languages:
       - java
     severity: WARNING
     metadata:
-      summary: This rule looks for predictable encryption modes.
-    message: "[MASVS-CRYPTO-1] Predictable encryption modes found in use."
+      summary: This rule looks for broken encryption modes.
+    message: "[MASVS-CRYPTO-1] Broken encryption modes found in use."
     pattern-either:
       - pattern: Cipher.getInstance("AES")
       - pattern-regex: Cipher\.getInstance\("?[A-Za-z0-9]+/ECB(/[A-Za-z0-9]+)?"?\)
diff --git a/techniques/android/MASTG-TECH-0014.md b/techniques/android/MASTG-TECH-0014.md
index e3d7e7798a9..2c9708d6273 100644
--- a/techniques/android/MASTG-TECH-0014.md
+++ b/techniques/android/MASTG-TECH-0014.md
@@ -17,7 +17,7 @@ grep 'android:minSdkVersion' AndroidManifest.xml
 
 This command searches for the `android:minSdkVersion` attribute within the manifest file. Ensuring a higher `minSdkVersion` can reduce security risks, as older versions of Android may not include the latest security features and fixes.
 
-## Example: Using semgrep for Identifying Predictable Seed
+## Example: Using semgrep for Identifying Seeds With Insufficient Entropy
 
 semgrep is a more advanced tool that can be used for pattern matching in code. It's particularly useful for identifying complex coding patterns that might lead to security vulnerabilities. For example, to find instances where a deterministic seed is used with the `SecureRandom` class (which can compromise the randomness and thus the security), you can use a semgrep rule like:
 
diff --git a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0221.md b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0221.md
index 73f40c8535b..0df1e193f47 100644
--- a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0221.md
+++ b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0221.md
@@ -1,5 +1,5 @@
 ---
-title: Symmetric Encryption Algorithms with Insufficient Strength
+title: Broken Symmetric Encryption Algorithms
 platform: android
 id: MASTG-TEST-0221
 type: [static, dynamic]
@@ -10,16 +10,16 @@ profiles: [L1, L2]
 
 ## Overview
 
-To test for the [use of encryption algorithms with insufficient strength](../../../Document/0x04g-Testing-Cryptography.md#identifying-insecure-andor-deprecated-cryptographic-algorithms) in Android apps, we need to focus on methods from cryptographic frameworks and libraries that are used to perform encryption and decryption operations.
+To test for the [use of broken encryption algorithms](../../../Document/0x04g-Testing-Cryptography.md#identifying-insecure-andor-deprecated-cryptographic-algorithms) in Android apps, we need to focus on methods from cryptographic frameworks and libraries that are used to perform encryption and decryption operations.
 
 - [`Cipher.getInstance`](https://developer.android.com/reference/javax/crypto/Cipher#getInstance(java.lang.String)): Initializes a Cipher object for encryption or decryption. The `algorithm` parameter can be one of the [supported algorithms](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#Cipher).
 - [`SecretKeyFactory.getInstance`](https://developer.android.com/reference/javax/crypto/SecretKeyFactory#getInstance(java.lang.String)): Returns a SecretKeyFactory object that converts keys into key specifications and vice versa. The `algorithm` parameter can be one of the [supported algorithms](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#SecretKeyFactory).
 - [`KeyGenerator.getInstance`](https://developer.android.com/reference/javax/crypto/KeyGenerator#getInstance(java.lang.String)): Returns a `KeyGenerator` object that generates secret keys for symmetric algorithms. The `algorithm` parameter can be one of the [supported algorithms](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#KeyGenerator).
 
-Some deprecated, risky or broken symmetric encryption algorithms include:
+Some broken symmetric encryption algorithms include:
 
 - **DES (Data Encryption Standard)**: 56-bit key, breakable, [withdrawn by NIST in 2005](https://csrc.nist.gov/pubs/fips/46-3/final).
-- **3DES (Triple DES, officially the Triple Data Encryption Algorithm (TDEA or Triple DEA))**: 64-bit with insufficient block size, [vulnerable to Sweet32 birthday attacks](https://sweet32.info/), [withdrawn by NIST on January 1, 2024](https://csrc.nist.gov/pubs/sp/800/67/r2/final).
+- **3DES (Triple DES, officially the Triple Data Encryption Algorithm (TDEA or Triple DEA))**: 64-bit block size, [vulnerable to Sweet32 birthday attacks](https://sweet32.info/), [withdrawn by NIST on January 1, 2024](https://csrc.nist.gov/pubs/sp/800/67/r2/final).
 - **RC4**: Predictable key stream, allows plaintext recovery [RC4 Weakness](https://www.rc4nomore.com/), disapproved by [NIST](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-52r1.pdf) in 2014 and prohibited by [IETF](https://datatracker.ietf.org/doc/html/rfc7465) in 2015.
 - **Blowfish**: 64-bit block size, [vulnerable to Sweet32 attacks](https://en.wikipedia.org/wiki/Birthday_attack), never FIPS-approved, and listed under ["Non-Approved algorithms" in FIPS](https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp2092.pdf).
 
diff --git a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md
index 2c986547683..4a9052337d6 100644
--- a/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md
+++ b/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md
@@ -1,5 +1,5 @@
 ---
-title: Risky or Broken Symmetric Encryption Modes
+title: Broken Symmetric Encryption Modes
 platform: android
 id: MASTG-TEST-0232
 type: [static, dynamic]
@@ -10,7 +10,7 @@ profiles: [L1, L2]
 
 ## Overview
 
-To test for the [use of risky or broken encryption modes](../../../Document/0x04g-Testing-Cryptography.md#weak-block-cipher-mode) in Android apps, we need to focus on methods from cryptographic frameworks and libraries that are used to configure and apply encryption modes.
+To test for the [use of broken encryption modes](../../../Document/0x04g-Testing-Cryptography.md#weak-block-cipher-mode) in Android apps, we need to focus on methods from cryptographic frameworks and libraries that are used to configure and apply encryption modes.
 
 In Android development, the `Cipher` class from the Java Cryptography Architecture (JCA) is the primary API that allows you to specify the encryption mode for cryptographic operations. [`Cipher.getInstance`](https://developer.android.com/reference/javax/crypto/Cipher#getInstance(java.lang.String)) defines the transformation string, which includes the encryption algorithm, mode of operation, and padding scheme. The general format is `"Algorithm/Mode/Padding"`. For example:
 
@@ -41,8 +41,8 @@ In the transformation strings like `"RSA/ECB/OAEPPadding"` or `"RSA/ECB/PKCS1Pad
 
 ## Observation
 
-The output should contain a list of locations where risky or broken encryption modes are used in cryptographic operations.
+The output should contain a list of locations where broken encryption modes are used in cryptographic operations.
 
 ## Evaluation
 
-The test case fails if any risky or broken modes are identified in the app.
+The test case fails if any broken modes are identified in the app.
diff --git a/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0210.md b/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0210.md
index d48b7b1ddc5..468c4999ab1 100644
--- a/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0210.md
+++ b/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0210.md
@@ -1,6 +1,6 @@
 ---
 platform: ios
-title: Symmetric Encryption Algorithms with insufficient strength
+title: Broken Symmetric Encryption Algorithms
 id: MASTG-TEST-0210
 type: [static, dynamic]
 weakness: MASWE-0020
@@ -9,7 +9,7 @@ profiles: [L1, L2]
 
 ## Overview
 
-To test for the use of encryption algorithms with insufficient strength in iOS apps, we need to focus on methods from cryptographic frameworks and libraries that are used to perform encryption and decryption operations.
+To test for the use of broken encryption algorithms in iOS apps, we need to focus on methods from cryptographic frameworks and libraries that are used to perform encryption and decryption operations.
 
 - **CommonCrypto**: The [`CCCrypt`](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/CCCrypt.3cc.html) function is used for **symmetric algorithms** and specifies the algorithm in its second parameter `alg`. This includes:
     - `kCCAlgorithmAES128`
@@ -19,7 +19,7 @@ To test for the use of encryption algorithms with insufficient strength in iOS a
     - `kCCAlgorithmRC4`
     - `kCCAlgorithmRC2`
 
-- **CryptoKit**: This library does not support encryption algorithms with insufficient strength. It supports the following **symmetric algorithms**:
+- **CryptoKit**: This library does not support broken encryption algorithms. It supports the following **symmetric algorithms**:
     - `AES.GCM`
     - `ChaChaPoly`
 
@@ -35,16 +35,16 @@ The output should contain the disassembled code of the functions using the relev
 
 ## Evaluation
 
-The test case fails if you can find the use of encryption algorithms within the source code with insufficient strength. For example:
+The test case fails if you can find the use of broken encryption algorithms within the source code. For example:
 
 - DES
 - 3DES
 - RC2
 - RC4
 
-**Stay up-to-date**: This is a non-exhaustive list of deprecated, risky and broken algorithms. Make sure to check the latest standards and recommendations from organizations such as the National Institute of Standards and Technology (NIST), the German Federal Office for Information Security (BSI) or any other relevant authority in your region.
+**Stay up-to-date**: This is a non-exhaustive list of broken algorithms. Make sure to check the latest standards and recommendations from organizations such as the National Institute of Standards and Technology (NIST), the German Federal Office for Information Security (BSI) or any other relevant authority in your region.
 
-Some algorithms may not be considered to have insufficient strength, but may have **inappropriate configurations** that should be avoided. Such as using a seed or IV not generated by Cryptographically secure PRNGs (CSPRNG) or not being considered quantum-safe. For example, an AES 128-bit key size is considered insufficient considering quantum computing attacks. When building an app that uses data that will be stored for a considerable long time. Make sure that you follow NIST recommendations on how to ["Transition to Post-Quantum Cryptography Standards"](https://csrc.nist.gov/pubs/ir/8547/ipd).
+Some algorithms may not be considered broken as a whole, but may have **risky configurations** that should be avoided. For example, using a seed or IV that is not generated by a cryptographically secure pseudorandom number generator (CSPRNG) or that is not considered quantum-safe. For instance, an AES 128-bit key size is insufficient in the face of quantum computing attacks. This is important when building an app that uses data that will be stored for a long time. Make sure you follow the NIST recommendations from [NIST IR 8547 "Transition to Post-Quantum Cryptography Standards", 2024](https://csrc.nist.gov/pubs/ir/8547/ipd).
 
 **Context Considerations**:
 
diff --git a/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md b/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md
index 8e884cbc1d4..2df5cbc7b38 100644
--- a/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md
+++ b/tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0211.md
@@ -1,6 +1,6 @@
 ---
 platform: ios
-title: Risky or Broken Hashing Algorithms
+title: Broken Hashing Algorithms
 id: MASTG-TEST-0211
 type: [static, dynamic]
 weakness: MASWE-0021
@@ -9,7 +9,7 @@ profiles: [L1, L2]
 
 ## Overview
 
-To test for the use of risky or broken hashing algorithms in iOS apps, we need to focus on methods from cryptographic frameworks and libraries that are used to perform hashing operations.
+To test for the use of broken hashing algorithms in iOS apps, we need to focus on methods from cryptographic frameworks and libraries that are used to perform hashing operations.
 
 - **CommonCrypto**: [CommonDigest.h](https://web.archive.org/web/20240606000312/https://opensource.apple.com/source/CommonCrypto/CommonCrypto-36064/CommonCrypto/CommonDigest.h) defines the following **hashing algorithms**:
     - `CC_MD2`
@@ -40,15 +40,15 @@ The output should contain the disassembled code of the functions using the relev
 
 ## Evaluation
 
-The test case fails if you can find the use of "broken" hashing algorithms within the source code. For example:
+The test case fails if you can find the use of broken hashing algorithms within the source code. For example:
 
 - MD5
 - SHA-1
 
-**Stay up-to-date**: This is a non-exhaustive list of weak, risky or broken algorithms. Make sure to check the latest standards and recommendations from organizations such as the National Institute of Standards and Technology (NIST), the German Federal Office for Information Security (BSI) or any other relevant authority in your region. When building an app that uses hashes that will be stored for a considerable long time, be sure to follow NIST recommendations about how to ["Transition to Post-Quantum Cryptography Standards"](https://csrc.nist.gov/pubs/ir/8547/ipd).
+**Stay up-to-date**: This is a non-exhaustive list of broken algorithms. Make sure to check the latest standards and recommendations from organizations such as the National Institute of Standards and Technology (NIST), the German Federal Office for Information Security (BSI) or any other relevant authority in your region. This is important when building an app that uses data that will be stored for a long time. Make sure you follow the NIST recommendations from [NIST IR 8547 "Transition to Post-Quantum Cryptography Standards", 2024](https://csrc.nist.gov/pubs/ir/8547/ipd).
 
 **Context Considerations**:
 
 To reduce false positives, make sure you understand the context in which the algorithm is being used before reporting the associated code as insecure. Ensure that it is being used in a security-relevant context to protect sensitive data.
 
-For example, using MD5 for hashing passwords is considered risky, but using MD5 for checksums or non-cryptographic purposes is acceptable.
+For example, using the broken algorithm MD5 for hashing passwords is disallowed by NIST, as it is no longer considered secure for cryptographic purposes. However, using MD5 for checksums or other non-cryptographic tasks, where security is not a concern, is generally acceptable.
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
index 34db7c2cfb0..847c7a3a512 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md
@@ -14,7 +14,7 @@ refs:
 draft:
   description: e.g. PBKDF2 with insufficient iterations, lack of salt, etc.
   topics:
-  - improper cryptography
+  - sources with insufficient entropy
   - lack of salt encryption when doing PBKDF2
 status: placeholder
 
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0021.md b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
index 4b96bf2e88b..4d19d105017 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0021.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0021.md
@@ -1,7 +1,7 @@
 ---
-title: Deprecated, Risky or Broken Hashing
+title: Improper Hashing
 id: MASWE-0021
-alias: weak-hashing
+alias: improper-hashing
 platform: [android, ios]
 profiles: [L1, L2]
 mappings:
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
index 24401576ca3..c0d5c0af7c7 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md
@@ -1,7 +1,7 @@
 ---
 title: Improper Use of Message Authentication Code (MAC)
 id: MASWE-0024
-alias: weak-mac
+alias: improper-mac
 platform: [android, ios]
 profiles: [L1, L2]
 mappings:
@@ -17,9 +17,16 @@ refs:
 - https://web.archive.org/web/20170810051504/http://www.tcs.hut.fi/old/papers/aura/aura-csfws97.pdf
 - https://en.wikipedia.org/wiki/Replay_attack
 draft:
-  description: Improper use of MAC. E.g. allowing the user to control the input.
-    may expose cryptographic vulnerabilities, affecting data integrity.
-  topics: null
+  description: Improper use of MACs in security sensitive contexts affecting data integrity.
+  topics:
+  - Using HMAC with keys with insufficient entropy
+  - Using HMAC with missing timestamp (or nonce)
+  - Using MAC‑then‑encrypt or encrypt‑then‑MAC incorrectly, leaking information via timing or error messages
+  - Allowing predictors (users or attackers) to control data inputs, creating scenarios where forged or replayed tags bypass integrity checks.
+  - Hash functions lacking collision resistance (e.g., MD5 or SHA‑1 used in HMAC)
+  - Use of non‑cryptographic checksums (e.g., CRC‑32 instead of HMAC)
+  - MAC constructions that fail outside narrow assumptions (e.g., raw CBC‑MAC on variable‑length messages)
+  - Tags that are too short significantly lower the effort required for forgery
 status: placeholder
 
 ---
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0025.md b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
index 7cc762225a6..f1df81e7189 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0025.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0025.md
@@ -1,7 +1,7 @@
 ---
-title: Signatures Created by Deprecated, Risky or Broken Algorithms
+title: Improper Generation of Cryptographic Signatures
 id: MASWE-0025
-alias: weak-signatures
+alias: improper-signature-generation
 platform: [android, ios]
 profiles: [L1, L2]
 mappings:
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0027.md b/weaknesses/MASVS-CRYPTO/MASWE-0027.md
index cb38f4774e4..3d76b0d98b3 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0027.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0027.md
@@ -1,7 +1,7 @@
 ---
-title: Cryptographically Predictable Pseudo-Random Number Generator (PRNG)
+title: Improper Random Number Generation
 id: MASWE-0027
-alias: insecure-random
+alias: improper-random-number-generation
 platform: ["android", "ios"]
 profiles: ["L1", "L2"]
 mappings:

From ab4cee0f079d1e22b82a3fc520f5c1baa91d7cec Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Mon, 14 Jul 2025 09:27:53 +0200
Subject: [PATCH 109/117] Apply suggestions from code review

---
 weaknesses/MASVS-CRYPTO/MASWE-0019.md |  7 +++----
 weaknesses/MASVS-CRYPTO/MASWE-0020.md | 28 +++++++++++++--------------
 weaknesses/MASVS-CRYPTO/MASWE-0023.md |  4 ++--
 3 files changed, 18 insertions(+), 21 deletions(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0019.md b/weaknesses/MASVS-CRYPTO/MASWE-0019.md
index 1baa84ba934..31628cb46f3 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0019.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0019.md
@@ -1,6 +1,5 @@
 ---
-title: Deprecated, Risky, or Broken Cryptography Implementations
-
+title: Risky Cryptography Implementations
 id: MASWE-0019
 alias: potentially-weak-crypto-impl
 platform: [android, ios]
@@ -30,7 +29,7 @@ refs:
 
 ## Overview
 
-Deprecated, risky, or noncompliant cryptographic implementations, such as those that do not meet established security standards such as FIPS 140-2/3 (Federal Information Processing Standards), may use algorithms that have not been sufficiently tested or that lack certification, may not follow best practices for secure key management, or may include custom cryptographic solutions that haven't undergone rigorous peer review or formal validation.
+Risky or noncompliant cryptographic implementations, such as those that do not meet established security standards such as FIPS 140-2/3 (Federal Information Processing Standards), may use algorithms that have not been sufficiently tested or that lack certification, may not follow best practices for secure key management, or may include custom cryptographic solutions that haven't undergone rigorous peer review or formal validation.
 
 ## Impact
 
@@ -38,7 +37,7 @@ Custom cryptographic implementations created without following established stand
 
 The impact associated with such defects can be very broad and difficult to predict or measure:
 
-- **Data breaches**: Deprecated, risky, or broken encryption can lead to unauthorized access to sensitive data, resulting in data breaches.
+- **Data breaches**: Risky cryptography implementations can lead to unauthorized access to sensitive data, resulting in data breaches.
 - **Compromised confidentiality, integrity, and authenticity**: The core principles of cryptography (confidentiality, integrity, and authenticity) are compromised. Attackers can decrypt, manipulate, or impersonate legitimate users or systems.
 
 ## Modes of Introduction
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0020.md b/weaknesses/MASVS-CRYPTO/MASWE-0020.md
index e10b170f643..81cbb8f520a 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0020.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0020.md
@@ -1,5 +1,5 @@
 ---
-title: Deprecated, Risky, or Broken Encryption
+title: Improper Encryption
 id: MASWE-0020
 alias: weak-encryption
 platform: [android, ios]
@@ -21,26 +21,24 @@ status: new
 
 ## Overview
 
-Deprecated, risky, or broken encryption refers to cryptographic systems or implementations that are vulnerable to attack, allowing unauthorized individuals to decrypt secured data. This can be due to a number of reasons, including the use of deprecated, risky or broken algorithms, deprecated or risky encryption modes such as ECB and improper implementation practices such as the use of a non-random or empty Initialization Vector (IV).
+Improper encryption refers to cryptographic systems or implementations that are vulnerable to attack, allowing unauthorized individuals to decrypt secured data.
 
 ## Impact
 
-- **Loss of Confidentiality**: Deprecated, risky, or broken encryption may enable attackers to decipher and obtain sensitive information, resulting in unauthorized exposure and possible data breaches.
-
-- **Loss of Integrity**: Deprecated, risky, or broken encryption can compromise the integrity of data, allowing adversaries to alter or manipulate the information without detection.
+- **Loss of Confidentiality**: Improper encryption may enable attackers to decipher and obtain sensitive information, resulting in unauthorized exposure and possible data breaches.
+- **Loss of Integrity**: Improper encryption can compromise the integrity of data, allowing adversaries to alter or manipulate the information without detection.
 
 ## Mode of Introduction
 
-- **Use of Deprecated Algorithms** : Relying on deprecated, risky or vulnerable encryption algorithms can allow threat actors to attack the cipher text, key or exploit known vulnerabilities in the algorithm, for example through brute force attacks.
-- **Insecure Modes of Operation**: Using modes that are considered deprecated or risky increase the attack surface of encrypted information. For example the use of AES/ECB is deprecated as it divides the plaintext into blocks and encrypts each block separately using the same key. This makes the cipher text vulnerable to "known plaintext attacks" and leaks information about the structure of the original plaintext.
-
-- **Predictable Initialization Vectors (IVs)**: If IVs are not random or unique, they can be exploited in attacks like ciphertext injection or pattern recognition. This compromises the confidentiality of encrypted data, especially in modes like CBC (Cipher Block Chaining).
-- **Short Keys**: Short or easily guessable keys compromise encryption strength. The use of small key sizes (e.g., 56-bit keys in DES) can make the encryption susceptible to brute-force attacks. Best practices recommend keys of at least 256 bits for strong encryption.
-- **Misuse of Non-Cryptographic Operations**: Relying on techniques such as XOR, Base64 encoding, or simple obfuscation methods for security purposes. These methods provide no actual encryption and can be easily reversed or decoded, exposing sensitive data.
+- **Broken Algorithms**: Relying on broken encryption algorithms (i.e., that are deprecated or disallowed by NIST or other standards) such as RC4.
+- **Risky Algorithm Configurations**: Using IVs with insufficient entropy or reusing them in modes like AES-CBC or AES-CTR breaks semantic security, allowing attackers to detect patterns or recover plaintext differences. In AEAD modes like AES-GCM, reusing nonces or using authentication tags of insufficient length compromises both confidentiality and integrity.
+- **Broken Modes of Operation**: Using modes that are considered broken. For example, AES-ECB is broken due to practical known-plaintext attacks and it's disallowed by NIST.
+- **Insufficient Key Length**: The use of insufficient key sizes (e.g., 128-bit keys in AES) can compromise encryption strength making the encryption susceptible to brute-force attacks.
+- **Non-Cryptographic Operations**: Relying on techniques such as XOR, Base64 encoding, or simple obfuscation methods for security purposes. These methods provide no actual encryption and can be easily reversed or decoded, exposing sensitive data.
 
 ## Mitigations
 
-- **Use Secure Encryption Modes**: Choose secure modes such as `AES/GCM/NoPadding` and avoid insecure modes such as ECB.
-- **Ensure Proper Initialization Vector Management**: Generate IVs using cryptographically secure random number generators and ensure they are unique for every operation.
-- **Use Strong Key Sizes**: Enforce key lengths of at least 256 bits for AES and avoid using small or short keys such as 56-bit DES keys.
-- **Rely on Proper Cryptographic Libraries**: Avoid using XOR, Base64 encoding, or obfuscation as substitutes for encryption and rely on well-vetted cryptographic libraries.
+- **Use Secure Encryption Modes**: Choose secure modes (e.g. approved by NIST) such as `AES/GCM/NoPadding`.
+- **Ensure Proper Initialization Vector Management**: Generate IVs using cryptographically secure random number generators (with sufficient entropy) and ensure they are unique for every operation.
+- **Use Sufficiently Long Keys**: Enforce sufficiently long keys such as those approved by NIST, e.g., a minimum of 256 bits for AES.
+- **Rely on Proper Cryptographic Primitives**: Rely on well-vetted cryptographic primitives that have undergone rigorous peer review and formal validation.
diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0023.md b/weaknesses/MASVS-CRYPTO/MASWE-0023.md
index 0ec5347330e..fd327cdaa7e 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0023.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0023.md
@@ -1,7 +1,7 @@
 ---
-title: Predictable Padding
+title: Risky Padding
 id: MASWE-0023
-alias: weak-padding
+alias: risky-padding
 platform: [android, ios]
 profiles: [L1, L2]
 mappings:

From f357e7c8386f97ada64ac7e05ea34a65b5708d50 Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Mon, 14 Jul 2025 09:29:21 +0200
Subject: [PATCH 110/117] Clarify language in MASWE-0027.md regarding PRNG
 predictability and update terminology for random APIs

---
 weaknesses/MASVS-CRYPTO/MASWE-0027.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0027.md b/weaknesses/MASVS-CRYPTO/MASWE-0027.md
index 3d76b0d98b3..47203c29d02 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0027.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0027.md
@@ -21,7 +21,7 @@ status: new
 
 ## Overview
 
-A [pseudorandom number generator (PRNG)](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) algorithm generates sequences based on a seed that may be predictable. Common implementations are not cryptographically secure. For example, they typically use a linear congruential formula, allowing an attacker to predict future outputs, given enough observed outputs. Therefore, it is not suitable for security-critical applications or protecting sensitive data.
+A [pseudorandom number generator (PRNG)](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) algorithm generates sequences based on a seed with insufficient entropy that may be predictable. Common implementations are not cryptographically secure. For example, they typically use a linear congruential formula, allowing an attacker to predict future outputs, given enough observed outputs. Therefore, it is not suitable for security-critical applications or protecting sensitive data.
 
 ## Impact
 
@@ -29,7 +29,7 @@ A [pseudorandom number generator (PRNG)](https://en.wikipedia.org/wiki/Pseudoran
 
 ## Modes of Introduction
 
-- **Insecure Random APIs**: The app may use many existing APIs to generate random numbers insecurely.
+- **Risky Random APIs**: The app may use many existing APIs to generate random numbers with insufficient entropy.
 - **Non-random Sources**: The app may use custom methods to create "supposedly random" values, using non-random sources such as the current time.
 
 ## Mitigations

From 7a802694c9e3e992eb1c21ab8c5ffef49fd7ac52 Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Mon, 14 Jul 2025 09:30:22 +0200
Subject: [PATCH 111/117] Apply suggestions from code review

---
 weaknesses/MASVS-CRYPTO/MASWE-0023.md | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0023.md b/weaknesses/MASVS-CRYPTO/MASWE-0023.md
index fd327cdaa7e..a4510cd628a 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0023.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0023.md
@@ -24,14 +24,14 @@ status: new
 
 ## Overview
 
-**Outdated or predictable padding schemes** can leave mobile apps susceptible to [padding oracle attacks](https://www.usenix.org/legacy/event/woot10/tech/full_papers/Rizzo.pdf), a type of side-channel exploit that lets attackers decrypt or manipulate data **without** knowing the key. These attacks arise when the app reveals whether a padding error occurred (through error messages or timing differences), creating an **oracle**. By submitting modified ciphertexts and observing the app's response, an attacker can gradually recover plaintext or forge ciphertext, compromising both confidentiality and integrity.
+[Padding oracle attacks](https://www.usenix.org/legacy/event/woot10/tech/full_papers/Rizzo.pdf) are a type of side-channel exploit that lets attackers decrypt or manipulate data **without** knowing the key. These attacks aren't due to the padding scheme bring broken itself, they arise when the app reveals whether a padding error occurred (through error messages or timing differences), creating an **oracle**. By submitting modified ciphertexts and observing the app's response, an attacker can gradually recover plaintext or forge ciphertext, compromising both confidentiality and integrity.
 
-Below are two common examples of cryptographic contexts where predictable padding can become a problem:
+Below are two common examples of cryptographic contexts where risky padding can become a problem:
 
-- **Symmetric Cryptography**: In block cipher modes (e.g., AES-CBC), **PKCS#7 padding** is widely used. It becomes vulnerable to padding oracle attacks if the system leaks detailed error messages or timing differences. To mitigate this, cryptographers often use **authenticated encryption modes** like AES-GCM or pair AES-CBC with a separate integrity check (e.g., HMAC in an Encrypt-then-MAC scheme).
+- **Symmetric Cryptography**: In block cipher modes (e.g., AES-CBC), **PKCS#7 padding** is widely used and it's not broken (not disallowed by NIST). However, it becomes vulnerable to padding oracle attacks if the system leaks detailed error messages or timing differences. To mitigate this, cryptographers often use **authenticated encryption modes** like AES-GCM or pair AES-CBC with a separate integrity check (e.g., HMAC in an Encrypt-then-MAC scheme).
 - **Asymmetric Cryptography**: With RSA, **PKCS#1 v1.5** is known to be susceptible to attacks such as [Bleichenbacher](https://link.springer.com/content/pdf/10.1007/BFb0055716.pdf) (based on padding oracles). This older scheme is now discouraged or disallowed by various standards (for example, see [RFC 8017, Section 7.2](https://datatracker.ietf.org/doc/html/rfc8017#section-7.2) from November 2016 or [NIST SP 800-131A Rev.2, Section 6](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf) from March 2019).
 
-However, simply using a predictable padding scheme does not guarantee a padding oracle vulnerability. As mentioned above, the app must **also** leak information (the "oracle") that indicates whether a padding error has occurred. If both conditions are met, attackers can use these signals to recover sensitive data or to craft malicious ciphertext.
+However, simply using a padding scheme susceptible to padding oracle attacks does not guarantee a vulnerability. As mentioned above, the app must **also** leak information (the "oracle") that indicates whether a padding error has occurred. If both conditions are met, attackers can use these signals to recover sensitive data or to craft malicious ciphertext.
 
 ## Impact
 
@@ -40,11 +40,12 @@ However, simply using a predictable padding scheme does not guarantee a padding
 
 ## Modes of Introduction
 
-- **Insecure Padding for Symmetric Encryption**: Using padding schemes like PKCS#7 without additional message authentication (e.g., HMAC) for symmetric encryption algorithms like AES in block cipher modes (e.g., CBC).
-- **Insecure Padding for Asymmetric Encryption**: Using predictable padding schemes like PKCS#1 v1.5 for RSA asymmetric encryption.
+- **Unauthenticated Padding for Symmetric Encryption**:  Using padding schemes like PKCS#7 without authenticating the ciphertext (e.g., with HMAC) allows padding oracle attacks in modes like AES-CBC.
+- **Risky Padding in Asymmetric Encryption**: Using schemes like PKCS#1 v1.5 for RSA encryption without strict, uniform handling of invalid ciphertext enables oracle attacks.
+- **Exposure of Cryptographic Errors**: Revealing detailed error messages or timing variations during decryption can leak information exploitable by attackers.
 
 ## Mitigations
 
 - **Use Authenticated Symmetric Encryption Modes**: Prefer authenticated encryption modes like AES-GCM, which eliminate the need for separate padding validation and incorporate integrity checks. If AES-CBC must be used, adopt the Encrypt-then-MAC paradigm (e.g., append HMAC). See [NIST SP 800-175B Rev.1, Section 4.3](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf).
-- **Use Secure Padding Schemes for Asymmetric Encryption**: Replace predictable schemes like PKCS#1 v1.5 with secure ones such as OAEP (Optimal Asymmetric Encryption Padding). See [NIST SP 800-56B Rev.2, Section 7.2.2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf).
+- **Use Secure Padding Schemes for Asymmetric Encryption**: Replace risky schemes like PKCS#1 v1.5 with secure ones such as OAEP (Optimal Asymmetric Encryption Padding). See [NIST SP 800-56B Rev.2, Section 7.2.2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf).
 - **Don't Expose Cryptographic Errors**: Do not expose cryptographic error messages, such as padding errors, to users. This prevents attackers from gaining clues about the padding's correctness.

From 0cef21283b3bdc6f04b3908b278b34e4b12ff7cd Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Mon, 14 Jul 2025 09:39:14 +0200
Subject: [PATCH 112/117] fix rules names

---
 demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/MASTG-DEMO-0007.md | 2 +-
 demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/output.txt         | 4 ++--
 demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/run.sh             | 2 +-
 ...s.yaml => mastg-android-broken-encryption-algorithms.yaml} | 0
 ...-modes.yaml => mastg-android-broken-encryption-modes.yaml} | 0
 ...tg-android-key-generation-with-insufficient-key-length.yml | 2 +-
 ...yml => mastg-android-random-apis-insufficient-entropy.yml} | 4 ++--
 7 files changed, 7 insertions(+), 7 deletions(-)
 rename rules/{mastg-android-risky-encryption-algorithms.yaml => mastg-android-broken-encryption-algorithms.yaml} (100%)
 rename rules/{mastg-android-risky-encryption-modes.yaml => mastg-android-broken-encryption-modes.yaml} (100%)
 rename rules/{mastg-android-insecure-random-use.yml => mastg-android-random-apis-insufficient-entropy.yml} (74%)

diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/MASTG-DEMO-0007.md b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/MASTG-DEMO-0007.md
index fc73b0d99c3..0b8890bb1fe 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/MASTG-DEMO-0007.md
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/MASTG-DEMO-0007.md
@@ -14,7 +14,7 @@ test: MASTG-TEST-0204
 
 Let's run our @MASTG-TOOL-0110 rule against the sample code.
 
-{{ ../../../../rules/mastg-android-insecure-random-use.yml }}
+{{ ../../../../rules/mastg-android-random-apis-insufficient-entropy.yml }}
 
 {{ run.sh }}
 
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/output.txt b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/output.txt
index a2518413b5b..755a5729d15 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/output.txt
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/output.txt
@@ -5,8 +5,8 @@
 └─────────────────┘
                             
     MastgTest_reversed.java 
-       rules.mastg-android-insecure-random-use                                              
-          [MASVS-CRYPTO-1] The application makes use of an insecure random number generator.
+       rules.mastg-android-random-apis-insufficient-entropy                                              
+          [MASVS-CRYPTO-1] The application makes use of random number generators with insufficient entropy.
                                                                                             
            22┆ double random1 = new Random().nextDouble();
             ⋮┆----------------------------------------
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/run.sh b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/run.sh
index fca187d2092..3b8f8af698a 100755
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/run.sh
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/run.sh
@@ -1 +1 @@
-NO_COLOR=true semgrep -c ../../../../rules/mastg-android-insecure-random-use.yml ./MastgTest_reversed.java --text -o output.txt
\ No newline at end of file
+NO_COLOR=true semgrep -c ../../../../rules/mastg-android-random-apis-insufficient-entropy.yml ./MastgTest_reversed.java --text -o output.txt
\ No newline at end of file
diff --git a/rules/mastg-android-risky-encryption-algorithms.yaml b/rules/mastg-android-broken-encryption-algorithms.yaml
similarity index 100%
rename from rules/mastg-android-risky-encryption-algorithms.yaml
rename to rules/mastg-android-broken-encryption-algorithms.yaml
diff --git a/rules/mastg-android-risky-encryption-modes.yaml b/rules/mastg-android-broken-encryption-modes.yaml
similarity index 100%
rename from rules/mastg-android-risky-encryption-modes.yaml
rename to rules/mastg-android-broken-encryption-modes.yaml
diff --git a/rules/mastg-android-key-generation-with-insufficient-key-length.yml b/rules/mastg-android-key-generation-with-insufficient-key-length.yml
index 00207e9c622..ad92cd9bf39 100644
--- a/rules/mastg-android-key-generation-with-insufficient-key-length.yml
+++ b/rules/mastg-android-key-generation-with-insufficient-key-length.yml
@@ -1,5 +1,5 @@
 rules:
-  - id: mastg-android-insufficient-key-length
+  - id: mastg-android-key-generation-with-insufficient-key-length
     severity: WARNING
     languages:
       - java
diff --git a/rules/mastg-android-insecure-random-use.yml b/rules/mastg-android-random-apis-insufficient-entropy.yml
similarity index 74%
rename from rules/mastg-android-insecure-random-use.yml
rename to rules/mastg-android-random-apis-insufficient-entropy.yml
index daba6bf3892..90c8c9c1695 100644
--- a/rules/mastg-android-insecure-random-use.yml
+++ b/rules/mastg-android-random-apis-insufficient-entropy.yml
@@ -1,12 +1,12 @@
 rules:
-  - id: mastg-android-insecure-random-use
+  - id: mastg-android-random-apis-insufficient-entropy
     severity: WARNING
     languages:
       - java
     metadata:
       summary: This rule looks for common patterns including classes and methods.
       original_source: https://github.com/mindedsecurity/semgrep-rules-android-security/blob/main/rules/crypto/mstg-crypto-6.yaml
-    message: "[MASVS-CRYPTO-1] The application makes use of an insecure random number generator."
+    message: "[MASVS-CRYPTO-1] The application makes use of random number generators with insufficient entropy."
 
     pattern-either:
         - patterns:

From 1a622cdeb84d29824025a9c01734d946e573806f Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Mon, 14 Jul 2025 09:42:10 +0200
Subject: [PATCH 113/117] restore section Improper Key Derivation Functions

---
 Document/0x04g-Testing-Cryptography.md | 30 ++++----------------------
 1 file changed, 4 insertions(+), 26 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index 299ab800f1b..cd9e320780d 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -118,34 +118,12 @@ Secret keys must be stored in secure device storage whenever symmetric cryptogra
 
 ### Improper Key Derivation Functions
 
-When discussing key derivation functions (KDFs) in the context of mobile applications, we are usually referring to cryptographic key derivation rather than password storage. This chapter focuses primarily on KDF in the context of cryptographic key derivation, rather than password storage. For general advice on password storage, please refer to the [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html).
-KDFs derive bytes suitable for cryptographic operations from passwords or other data sources using a pseudorandom function (PRF).
+Cryptographic algorithms (such as symmetric encryption or some MACs) expect a secret input of a given size. For example, AES uses a key of exactly 16 bytes. A native implementation might use the user-supplied password directly as an input key. Using a user-supplied password as an input key has the following problems:
 
-Different KDFs are suitable for different tasks such as:
+- If the password is smaller than the key, the full key space isn't used. The remaining space is padded (spaces are sometimes used for padding).
+- A user-supplied password will realistically consist mostly of displayable and pronounceable characters. Therefore, only some of the possible 256 ASCII characters are used and entropy is decreased by approximately a factor of four.
 
-- Cryptographic key derivation:
-    - Together with a non-secret parameter to derive one or more keys from a common secret value. Also known as known as "key diversification"
-    - As components of multiparty key-agreement protocols (e.g: [KDF1](https://en.wikipedia.org/wiki/IEEE_P1363)).
-    - To derive keys from secret passwords or passphrases.
-    - To derive keys of different length from the ones provided (e.g: [PBKDF2HMAC](https://en.wikipedia.org/wiki/PBKDF2) or [HKDF](https://en.wikipedia.org/wiki/HKDF)).
-    - [Key stretching](https://en.wikipedia.org/wiki/Key_stretching) and [key strengthening](https://en.wikipedia.org/wiki/Key_derivation_function#Key_stretching_and_key_strengthening).
-
-- Password storage:
-    - In order to ensure attacker's can't use a stolen password even in the event of a data breach, passwords are stored as hashes computed through a computationally intensive KDF. The ideal password storage's KDF should be demanding on both computational and memory resources.
-
-Source: ([Wikipedia, 2025.02.21"](https://en.wikipedia.org/wiki/Key_derivation_function "Key derivation function"))
-
-When using a KDF for cryptographic operations always ensure to use a recommended and approved KDF properly according to the latest recommendations and the software provider's documentation. E.g Only using a key derivation functions that is constructed from hashes against which no non-trivial pre-image or length-extension attacks are known and where attacking the key derivation function directly is infeasible. Using user-supplied input together with HKDF will make it easy for password crackers to execute a preimage attack.
-
-Choose a KDF that use an adaptive hash function that can be configured to change the amount of computational effort needed to compute the hash, such as the number of iterations ("stretching") or the amount of memory required. Some hash functions perform salting automatically. These functions can significantly increase the overhead for a brute force attack compared to intentionally-fast functions. For example, rainbow table attacks can become infeasible due to the high computing overhead. Finally, since computing power gets faster and cheaper over time, the technique can be reconfigured to increase the workload without forcing an entire replacement of the algorithm in use.
-
-Some hash functions that have one or more of these desired properties include [scrypt](https://www.tarsnap.com/scrypt.html), and [PBKDF2](https://www.rfc-editor.org/rfc/rfc2898). While there is active debate about which of these is the most effective, they are all stronger than using salts with hash functions with very little computing overhead.
-
-Note that using these functions can have an impact on performance, so they require special consideration to avoid denial-of-service attacks. However, their configurability provides finer control over how much CPU and memory is used, so it could be adjusted to suit the environment's needs. In the case where CPU and memory performance is a challenge try adjusting desired bit-length of the derived key instead of increasing the iteration account (e.g using HMAC-SHA512 instead of HMAC-SHA256). This might make the KDF more susceptible by brute-force attacks, but should be acceptable as long as you keep yourself within recommended guidelines.
-
-Unfortunately, "brute-force" attacks are quite liable to succeed where users selects passwords and pins with none or with too little entropy than what is required for cryptographic keys. Therefore, ensure that passwords and pins aren't directly passed into a HKDF. The key that is input to a key-derivation function is called a key-derivation key (KDK). A KDK **shall** be a cryptographic key, but the KDK used as an input to a recommended key-derivation functions can, for example, be generated by an approved cryptographic random bit generator, e.g. by a deterministic random bit generator (see: [NIST 800-108, rev 1](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")) ([NIST, 2022](https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final "NIST: Recommendation for Key Derivation Using Pseudorandom Functions")).
-In cases where the input is user-controlled, use password hashing algorithm like Argon2, scrypt, bcrypt or PBKDF2 as a key derivation function to provide a sufficient level of computational effort.
-When using a password hashing algorithm as a KDF, also ensure to choose an appropriate iteration count that can provide sufficient computational efforts. Meaning that they make password or secret cracking attacks infeasible or expensive. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to implementation algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2"). Also see ["OWASP Password Storage Cheat Sheet"](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction "OWASP Cheat Sheet Series: Password Storage Cheat Sheet") for recommendation on iteration count when using key derivation functions using Argon2, scrypt, bcrypt or PBKDF2.
+Ensure that passwords aren't directly passed into an encryption function. Instead, the user-supplied password should be passed into a KDF to create a cryptographic key. Choose an appropriate iteration count when using password derivation functions. For example, [NIST recommends an iteration count of at least 10,000 for PBKDF2](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 "NIST Special Publication 800-63B") and [for critical keys where user-perceived performance is not critical at least 10,000,000](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf "NIST Special Publication 800-132"). For critical keys, it is recommended to consider implementation of algorithms recognized by [Password Hashing Competition (PHC)](https://password-hashing.net/ "PHC") like [Argon2](https://github.com/p-h-c/phc-winner-argon2 "Argon2").
 
 ### Improper Random Number Generation
 

From c8318a45b85491b2ae2636b46dc67e47e101a0d9 Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Mon, 14 Jul 2025 09:58:48 +0200
Subject: [PATCH 114/117] Enhance guidance on random number generation in
 mobile apps, emphasizing the importance of using Cryptographically Secure
 Pseudo-Random Number Generators (CSPRNGs) for security-critical values.

---
 Document/0x04g-Testing-Cryptography.md | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/Document/0x04g-Testing-Cryptography.md b/Document/0x04g-Testing-Cryptography.md
index cd9e320780d..713cab94017 100644
--- a/Document/0x04g-Testing-Cryptography.md
+++ b/Document/0x04g-Testing-Cryptography.md
@@ -127,16 +127,19 @@ Ensure that passwords aren't directly passed into an encryption function. Instea
 
 ### Improper Random Number Generation
 
-It is fundamentally impossible to produce truly random numbers on any deterministic device. Pseudo-random number generators (PRNG) compensate for this by producing a stream of pseudo-random numbers - a stream of numbers that appear as if they were randomly generated. The quality of the generated numbers varies with the type of algorithm used. Cryptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks (e.g. it is statistically infeasible to predict the next number produced).
+A common weakness in mobile apps is the improper use of random number generators. Regular Pseudo-Random Number Generators (PRNGs), while sufficient for general use, are not designed for cryptographic purposes. When used to generate keys, tokens, or other security-critical values, they can make systems vulnerable to prediction and attack.
 
-PRNGs can be vulnerable when developers use a regular PRNG for cryptographic purposes, instead of a cryptographically secure PRNG (["Cryptographically secure pseudorandom number generator", 2025.01.31](https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator "Wikipedia: Cryptographically secure pseudorandom number generator")). 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 meet this condition.
+The root issue is that deterministic devices cannot produce true randomness. PRNGs simulate randomness using algorithms, but without sufficient entropy and algorithmic strength, the output can be predictable. For example, UUIDs may appear random but do not provide enough entropy for secure use.
 
-Mobile SDKs offer standard implementations of PRNG algorithms that produce numbers with sufficient artificial randomness. We'll introduce the available APIs in the Android and iOS-specific sections.
+The correct approach is to use a [**Cryptographically Secure Pseudo-Random Number Generator (CSPRNG)**](https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator). CSPRNGs are designed to resist statistical analysis and prediction, making them suitable for generating non-guessable values. All security-sensitive values must be generated using a CSPRNG with at least 128 bits of entropy.
 
 ### Improper Hashing
 
-Make sure to choose a hash function that is built for the purpose you intend it for.
-When hashes are needed for integrity checks, choose an algorithm that is sufficiently collision resistant, such as the integrity algorithms SHA-256, SHA-384, SHA-512, BLAKE3, and the SHA-3 family. Choosing a risky or broken algorithm may compromise the integrity and authenticity of data at rest and in transit. Also keep in mind that hash functions used for integrity checks, like the SHA series, should not be used for key derivation together with predictable input or in password hashing.
+Using the wrong hash function for a given purpose can compromise both security and data integrity. Each hash function is designed with specific use cases in mind, and applying it incorrectly introduces risk.
+
+For integrity checks, choose a hash function that offers strong collision resistance. Algorithms such as SHA-256, SHA-384, SHA-512, BLAKE3, and the SHA-3 family are appropriate for verifying data integrity and authenticity. Avoid broken algorithms like MD5 or SHA-1, as they are vulnerable to collision attacks.
+
+Do not use general-purpose hash functions like SHA-2 or SHA-3 for password hashing or key derivation, especially with predictable input.
 
 ### Custom Implementations of Cryptography
 

From 1311ed818597eb81ae9984afd4b320d6f4632d3e Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Mon, 14 Jul 2025 10:01:41 +0200
Subject: [PATCH 115/117] fix lint issue

---
 weaknesses/MASVS-CRYPTO/MASWE-0023.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0023.md b/weaknesses/MASVS-CRYPTO/MASWE-0023.md
index a4510cd628a..24d09b72e36 100644
--- a/weaknesses/MASVS-CRYPTO/MASWE-0023.md
+++ b/weaknesses/MASVS-CRYPTO/MASWE-0023.md
@@ -40,7 +40,7 @@ However, simply using a padding scheme susceptible to padding oracle attacks doe
 
 ## Modes of Introduction
 
-- **Unauthenticated Padding for Symmetric Encryption**:  Using padding schemes like PKCS#7 without authenticating the ciphertext (e.g., with HMAC) allows padding oracle attacks in modes like AES-CBC.
+- **Unauthenticated Padding for Symmetric Encryption**: Using padding schemes like PKCS#7 without authenticating the ciphertext (e.g., with HMAC) allows padding oracle attacks in modes like AES-CBC.
 - **Risky Padding in Asymmetric Encryption**: Using schemes like PKCS#1 v1.5 for RSA encryption without strict, uniform handling of invalid ciphertext enables oracle attacks.
 - **Exposure of Cryptographic Errors**: Revealing detailed error messages or timing variations during decryption can leak information exploitable by attackers.
 

From f00ec8422ed221f067958c5c401bd1d435473457 Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Mon, 14 Jul 2025 12:02:08 +0200
Subject: [PATCH 116/117] update semgrep outputs

---
 .../MASVS-CRYPTO/MASTG-DEMO-0007/output.txt       | 13 +++++++------
 demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/run.sh |  2 +-
 .../MASVS-CRYPTO/MASTG-DEMO-0012/output.txt       | 15 ++++++++-------
 .../MASVS-CRYPTO/MASTG-DEMO-0022/output.txt       |  7 ++++---
 .../MASVS-CRYPTO/MASTG-DEMO-0023/output.txt       |  7 ++++---
 5 files changed, 24 insertions(+), 20 deletions(-)

diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/output.txt b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/output.txt
index 755a5729d15..a8193789baa 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/output.txt
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/output.txt
@@ -3,14 +3,15 @@
 ┌─────────────────┐
 │ 3 Code Findings │
 └─────────────────┘
-                            
-    MastgTest_reversed.java 
-       rules.mastg-android-random-apis-insufficient-entropy                                              
+                           
+    MastgTest_reversed.java
+    ❯❱ rules.mastg-android-random-apis-insufficient-entropy
           [MASVS-CRYPTO-1] The application makes use of random number generators with insufficient entropy.
-                                                                                            
+                                                                                                           
            22┆ double random1 = new Random().nextDouble();
             ⋮┆----------------------------------------
            23┆ double random2 = 1 + Math.random();
             ⋮┆----------------------------------------
-           27┆  ... random.nextInt("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789".length()))); ... 
-            [shortened a long line from output, adjust with --max-chars-per-line]
+           27┆ password.append("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789".charAt(ran
+               dom.nextInt("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789".length())));  
+
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/run.sh b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/run.sh
index 3b8f8af698a..cc1b16600fa 100755
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/run.sh
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0007/run.sh
@@ -1 +1 @@
-NO_COLOR=true semgrep -c ../../../../rules/mastg-android-random-apis-insufficient-entropy.yml ./MastgTest_reversed.java --text -o output.txt
\ No newline at end of file
+NO_COLOR=true semgrep -c ../../../../rules/mastg-android-random-apis-insufficient-entropy.yml ./MastgTest_reversed.java --text > output.txt
\ No newline at end of file
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/output.txt b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/output.txt
index d3311fb36db..b3406d4daa8 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/output.txt
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0012/output.txt
@@ -1,15 +1,16 @@
-
-
+                   
+                   
 ┌─────────────────┐
 │ 2 Code Findings │
 └─────────────────┘
-
+                           
     MastgTest_reversed.java
-    ❯❱ insufficient_key_size
-          Cryptographic implementations with insufficient key length are being used.
-
+    ❯❱ rules.mastg-android-key-generation-with-insufficient-key-length
+          [MASVS-CRYPTO] Make sure that the key size is according to security best practices
+                                                                                            
            27┆ KeyPairGenerator generator = KeyPairGenerator.getInstance("RSA");
            28┆ generator.initialize(1024, new SecureRandom());
             ⋮┆----------------------------------------
            31┆ KeyGenerator keyGen1 = KeyGenerator.getInstance("AES");
-           32┆ keyGen1.init(128);
\ No newline at end of file
+           32┆ keyGen1.init(128);
+
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/output.txt b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/output.txt
index 20d57ce451d..3c382a48949 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/output.txt
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0022/output.txt
@@ -5,9 +5,9 @@
 └─────────────────┘
                            
     MastgTest_reversed.java
-    ❯❱ rules.risky-encryption-algorithms
-          [MASVS-CRYPTO-1] Deprecated, risky or broken encryption algorithms found in use.
-                                                                   
+    ❯❱ rules.mastg-android-broken-encryption-algorithms
+          [MASVS-CRYPTO-1] Broken encryption algorithms found in use.
+                                                                     
            39┆ Cipher cipher = Cipher.getInstance("DES");
             ⋮┆----------------------------------------
            62┆ Cipher cipher = Cipher.getInstance("DESede");
@@ -15,3 +15,4 @@
            81┆ Cipher cipher = Cipher.getInstance("RC4");
             ⋮┆----------------------------------------
           100┆ Cipher cipher = Cipher.getInstance("Blowfish");
+
diff --git a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/output.txt b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/output.txt
index 82162e75a5f..7d7f222b867 100644
--- a/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/output.txt
+++ b/demos/android/MASVS-CRYPTO/MASTG-DEMO-0023/output.txt
@@ -5,9 +5,9 @@
 └─────────────────┘
                            
     MastgTest_reversed.java
-    ❯❱ rules.risky-encryption-modes
-          [MASVS-CRYPTO-1] Risky or broken encryption modes found in use.
-                                                              
+    ❯❱ rules.mastg-android-broken-encryption-modes
+          [MASVS-CRYPTO-1] Broken encryption modes found in use.
+                                                                
            36┆ Cipher cipher = Cipher.getInstance("AES");
             ⋮┆----------------------------------------
            55┆ Cipher cipher = Cipher.getInstance("AES/ECB/NoPadding");
@@ -19,3 +19,4 @@
           118┆ Cipher cipher = Cipher.getInstance("DES/ECB/PKCS5Padding");
             ⋮┆----------------------------------------
           141┆ Cipher cipher = Cipher.getInstance("DESede/ECB/PKCS5Padding");
+

From 4c00213ca01bf8002fc514453a31d3f347308c7c Mon Sep 17 00:00:00 2001
From: Carlos Holguera <perezholguera@gmail.com>
Date: Mon, 14 Jul 2025 12:02:12 +0200
Subject: [PATCH 117/117] Fix term in MASWE-0052

---
 weaknesses/MASVS-NETWORK/MASWE-0052.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/weaknesses/MASVS-NETWORK/MASWE-0052.md b/weaknesses/MASVS-NETWORK/MASWE-0052.md
index ea956e43832..78149fd7eeb 100644
--- a/weaknesses/MASVS-NETWORK/MASWE-0052.md
+++ b/weaknesses/MASVS-NETWORK/MASWE-0052.md
@@ -40,7 +40,7 @@ Apps that do not properly validate TLS certificates during secure communication
 - **Accepting Self-Signed Certificates**: Applications accept self-signed or untrusted certificates without proper validation against trusted Certificate Authorities (CAs).
 - **Ignoring Hostname Verification**: Failing to verify that the certificate's hostname matches the server's hostname allows attackers to present valid certificates for other domains.
 - **Using Insecure Custom Trust Managers**: Implementing custom certificate validation logic that is incomplete, incorrect, or insecure.
-- **Inadequate Error Handling**: Proceeding with connections even when certificate validation errors occur, without alerting the user or terminating the connection.
+- **Incorrect Error Handling**: Proceeding with connections even when certificate validation errors occur, without alerting the user or terminating the connection.
 - **Trusting All Certificates**: Configuring the application to trust all certificates by default, without any validation.
 
 ## Mitigations