Mastercard/client-encryption-java

RSA-10241024-bit Already broken 1 place See details

X.509 certificate

A PEM certificate. The subject public-key algorithm and key size are read from the SubjectPublicKeyInfo structure, and the not-after date is reported so certificates that outlive the migration window are visible.

This is a digital identity document. Its expiry date matters: one valid for many years locks in today's algorithms for that long.

What to do. Shorten certificate lifetimes so re-issuing with a post-quantum key is routine.

1. src/test/resources/certificates/test_certificate-1024.pem:1 test path -----BEGIN CERTIFICATE-----

pem.certificate

RSA-1024512-bit Already broken 1 place See details

X.509 certificate

A PEM certificate. The subject public-key algorithm and key size are read from the SubjectPublicKeyInfo structure, and the not-after date is reported so certificates that outlive the migration window are visible.

This is a digital identity document. Its expiry date matters: one valid for many years locks in today's algorithms for that long.

What to do. Shorten certificate lifetimes so re-issuing with a post-quantum key is routine.

1. src/test/resources/certificates/test_certificate-512.pem:1 test path -----BEGIN CERTIFICATE-----

pem.certificate

RSA-10241024-bit Already broken Recorded traffic 1 place See details

Private key committed to the repository

A PEM private-key block. The header names the algorithm where the format is the legacy one; for PKCS#8 the algorithm OID is read out of the DER. A private key in version control is a present-day incident before it is a quantum question.

A secret key is stored in this repository's files. Anyone who can read the repository can use it. This needs attention today, regardless of quantum computers.

What to do. Revoke and rotate the key, then keep key material out of the repository. Record the algorithm in the inventory.

1. src/test/resources/keys/pkcs8/test_key_pkcs8-1024.pem:1 test path -----BEGIN PRIVATE KEY-----

pem.private-key · CWE-321, CWE-327

RSA-1024512-bit Already broken Recorded traffic 1 place See details

Private key committed to the repository

A PEM private-key block. The header names the algorithm where the format is the legacy one; for PKCS#8 the algorithm OID is read out of the DER. A private key in version control is a present-day incident before it is a quantum question.

A secret key is stored in this repository's files. Anyone who can read the repository can use it. This needs attention today, regardless of quantum computers.

What to do. Revoke and rotate the key, then keep key material out of the repository. Record the algorithm in the inventory.

1. src/test/resources/keys/pkcs8/test_key_pkcs8-512.pem:1 test path -----BEGIN PRIVATE KEY-----

pem.private-key · CWE-321, CWE-327

RSA Quantum-vulnerable Recorded traffic 4 places See details

Private key committed to the repository

A PEM private-key block. The header names the algorithm where the format is the legacy one; for PKCS#8 the algorithm OID is read out of the DER. A private key in version control is a present-day incident before it is a quantum question.

A secret key is stored in this repository's files. Anyone who can read the repository can use it. This needs attention today, regardless of quantum computers.

What to do. Revoke and rotate the key, then keep key material out of the repository. Record the algorithm in the inventory.

1. src/test/resources/keys/pkcs1/test_key_pkcs1-1024.pem:1 test path -----BEGIN RSA PRIVATE KEY-----
2. src/test/resources/keys/pkcs1/test_key_pkcs1-2048.pem:1 test path -----BEGIN RSA PRIVATE KEY-----
3. src/test/resources/keys/pkcs1/test_key_pkcs1-4096.pem:1 test path -----BEGIN RSA PRIVATE KEY-----
4. src/test/resources/keys/pkcs1/test_key_pkcs1-512.pem:1 test path -----BEGIN RSA PRIVATE KEY-----

pem.private-key · CWE-321, CWE-327

RSA-OAEP Quantum-vulnerable Recorded traffic 4 places See details

JOSE algorithm declared in configuration

An `alg` value in JSON or YAML. `none` is reported as a critical defect; HS* is an HMAC and is not quantum-vulnerable; RS*, PS*, ES* and EdDSA are.

A quantum computer of sufficient size breaks this completely. It has to be replaced, not tuned. Broken by Shor's algorithm on a cryptographically relevant quantum computer.

What to do. No standardised post-quantum JOSE algorithm exists yet. Keep token lifetimes short.

1. src/main/java/com/mastercard/developer/encryption/JweEncryption.java:20 private static final String ALGORITHM = "RSA-OAEP-256";
2. src/main/java/com/mastercard/developer/encryption/JweEncryption.java:90 JweHeader myHeader = new JweHeader(ALGORITHM, ENCRYPTION, config.encryptionKeyFingerprint, CONTENT_TYPE);
3. src/test/java/com/mastercard/developer/encryption/jwe/JweHeaderTest.java:12 test path JweHeader header = new JweHeader("RSA-OAEP-256", "A256GCM", "123", "application/json");
4. src/test/java/com/mastercard/developer/encryption/jwe/JweHeaderTest.java:20 test path assertEquals("RSA-OAEP-256", header.getAlg());

jose.algorithm · CWE-327

RSA-OAEP Quantum-vulnerable Recorded traffic From a constant 2 places See details

Classical public-key cipher through the JCA

`Cipher.getInstance()` with a transformation whose algorithm component is a public-key or legacy symmetric cipher. The transformation string is parsed into algorithm, mode and padding, so `RSA/ECB/PKCS1Padding` is separated from `RSA/ECB/OAEPWithSHA-256AndMGF1Padding`.

A quantum computer of sufficient size breaks this completely. It has to be replaced, not tuned. Broken by Shor's algorithm on a cryptographically relevant quantum computer.

What to do. For RSA encryption, move to ML-KEM-768 and keep RSA-OAEP only as the classical half of a hybrid during transition.

1. src/main/java/com/mastercard/developer/encryption/rsa/RSA.java:27 Cipher cipher = Cipher.getInstance(asymmetricCipher);
2. src/main/java/com/mastercard/developer/encryption/rsa/RSA.java:42 Cipher cipher = Cipher.getInstance(asymmetricCipher);

java.cipher · CWE-327

RSA Quantum-vulnerable Recorded traffic 1 place See details

Classical key material handled through the JCA

`KeyFactory.getInstance()` for a classical algorithm. This indicates the code parses or produces keys of that family, which is a migration surface even where it does no cryptography itself.

A quantum computer of sufficient size breaks this completely. It has to be replaced, not tuned. Broken by Shor's algorithm on a cryptographically relevant quantum computer.

What to do. Include this code path in the inventory: it has to accept post-quantum key encodings before the keys themselves can change.

1. src/main/java/com/mastercard/developer/utils/EncryptionUtils.java:99 KeyFactory keyFactory = KeyFactory.getInstance("RSA");

java.keyfactory · CWE-327

RSA2048-bit Quantum-vulnerable 1 place See details

X.509 certificate

A PEM certificate. The subject public-key algorithm and key size are read from the SubjectPublicKeyInfo structure, and the not-after date is reported so certificates that outlive the migration window are visible.

This is a digital identity document. Its expiry date matters: one valid for many years locks in today's algorithms for that long.

What to do. Shorten certificate lifetimes so re-issuing with a post-quantum key is routine.

1. src/test/resources/certificates/test_certificate-2048.pem:1 test path -----BEGIN CERTIFICATE-----

pem.certificate

RSA4096-bit Quantum-vulnerable 1 place See details

X.509 certificate

A PEM certificate. The subject public-key algorithm and key size are read from the SubjectPublicKeyInfo structure, and the not-after date is reported so certificates that outlive the migration window are visible.

This is a digital identity document. Its expiry date matters: one valid for many years locks in today's algorithms for that long.

What to do. Shorten certificate lifetimes so re-issuing with a post-quantum key is routine.

1. src/test/resources/certificates/test_certificate-4096.pem:1 test path -----BEGIN CERTIFICATE-----

pem.certificate

RSA2048-bit Quantum-vulnerable Recorded traffic 1 place See details

Private key committed to the repository

A PEM private-key block. The header names the algorithm where the format is the legacy one; for PKCS#8 the algorithm OID is read out of the DER. A private key in version control is a present-day incident before it is a quantum question.

A secret key is stored in this repository's files. Anyone who can read the repository can use it. This needs attention today, regardless of quantum computers.

What to do. Revoke and rotate the key, then keep key material out of the repository. Record the algorithm in the inventory.

1. src/test/resources/keys/pkcs8/test_key_pkcs8-2048.pem:1 test path -----BEGIN PRIVATE KEY-----

pem.private-key · CWE-321, CWE-327

RSA4096-bit Quantum-vulnerable Recorded traffic 1 place See details

Private key committed to the repository

A PEM private-key block. The header names the algorithm where the format is the legacy one; for PKCS#8 the algorithm OID is read out of the DER. A private key in version control is a present-day incident before it is a quantum question.

A secret key is stored in this repository's files. Anyone who can read the repository can use it. This needs attention today, regardless of quantum computers.

What to do. Revoke and rotate the key, then keep key material out of the repository. Record the algorithm in the inventory.

1. src/test/resources/keys/pkcs8/test_key_pkcs8-4096.pem:1 test path -----BEGIN PRIVATE KEY-----

pem.private-key · CWE-321, CWE-327

SHA-256 Reduced margin 20 places See details

Algorithm named in a setting

A setting whose name says it holds an algorithm, given a literal that names one: `withOaepPaddingDigestAlgorithm("SHA-512")`, `signatureAlgorithm = "SHA256withRSA"`, `"digestAlgorithm": "SHA-256"`. The algorithm never reaches a `getInstance()` in this file - it is carried to one somewhere else, often through configuration - so a scan that only reads the factories cannot see it at all.

Something here is configured to use a named algorithm. The code that uses it may be somewhere else entirely, but this is the line that decides which algorithm it is.

What to do. Find what consumes the setting. The migration belongs to that operation; this line is where the choice is actually written down, and usually where it is easiest to change.

1. README.md:404 .withOaepPaddingDigestAlgorithm("SHA-256")
2. README.md:626 .withOaepPaddingDigestAlgorithm("SHA-256")
3. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionWithDefaultJsonEngineTest.java:110 test path .withOaepPaddingDigestAlgorithm("SHA-256")
4. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionWithDefaultJsonEngineTest.java:148 test path .withOaepPaddingDigestAlgorithm("SHA-256")
5. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionWithDefaultJsonEngineTest.java:166 test path .withOaepPaddingDigestAlgorithm("SHA-256")
6. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionWithDefaultJsonEngineTest.java:197 test path .withOaepPaddingDigestAlgorithm("SHA-256")
7. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionWithDefaultJsonEngineTest.java:223 test path .withOaepPaddingDigestAlgorithm("SHA-256")
8. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionWithDefaultJsonEngineTest.java:247 test path .withOaepPaddingDigestAlgorithm("SHA-256")
9. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionWithDefaultJsonEngineTest.java:317 test path .withOaepPaddingDigestAlgorithm("SHA-256")
10. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionWithDefaultJsonEngineTest.java:447 test path .withOaepPaddingDigestAlgorithm("SHA-256")
11. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionWithDefaultJsonEngineTest.java:473 test path .withOaepPaddingDigestAlgorithm("SHA-256")
12. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionWithDefaultJsonEngineTest.java:497 test path .withOaepPaddingDigestAlgorithm("SHA-256")
13. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionWithDefaultJsonEngineTest.java:521 test path .withOaepPaddingDigestAlgorithm("SHA-256")
14. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionWithDefaultJsonEngineTest.java:546 test path .withOaepPaddingDigestAlgorithm("SHA-256")
15. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionWithDefaultJsonEngineTest.java:567 test path .withOaepPaddingDigestAlgorithm("SHA-256")
16. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionWithDefaultJsonEngineTest.java:615 test path .withOaepPaddingDigestAlgorithm("SHA-256")
17. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionWithDefaultJsonEngineTest.java:642 test path .withOaepPaddingDigestAlgorithm("SHA-256")
18. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionWithDefaultJsonEngineTest.java:1178 test path .withOaepPaddingDigestAlgorithm("SHA-256")
19. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionWithDefaultJsonEngineTest.java:1312 test path .withOaepPaddingDigestAlgorithm("SHA-256")
20. src/test/java/com/mastercard/developer/test/TestUtils.java:37 test path .withOaepPaddingDigestAlgorithm("SHA-256")

config.algorithm-setting · CWE-327

AES Reduced margin 4 places See details

Key material constructed for a named algorithm

`new SecretKeySpec(bytes, "AES")` and the other key-spec constructors name the algorithm as an argument rather than through `getInstance()`. Code that wraps raw bytes into a key this way often never calls `getInstance()` at all, so the algorithm is invisible to a scan that only looks at the factories.

This wraps raw bytes into a key for a named algorithm. It is part of the same migration as whatever uses that key.

What to do. Wherever this key is used, the same migration applies as to the call that consumes it. Trace it to the operation and treat the two together.

1. src/main/java/com/mastercard/developer/encryption/aes/AESCBC.java:23 SecretKeySpec aesKey = new SecretKeySpec(secretKey.getEncoded(), 16, 16, "AES");
2. src/main/java/com/mastercard/developer/encryption/aes/AESEncryption.java:32 return new SecretKeySpec(cekMaterial, "AES");
3. src/main/java/com/mastercard/developer/encryption/jwe/JweObject.java:74 SecretKeySpec aesKey = new SecretKeySpec(cek.getEncoded(), "AES");
4. src/test/java/com/mastercard/developer/encryption/rsa/RSATest.java:24 test path SecretKey originalKey = new SecretKeySpec(originalKeyBytes, 0, originalKeyBytes.length, SYMMETRIC_KEY_TYPE);

java.keyspec · CWE-327

AES Reduced margin From a constant 3 places See details

Classical public-key cipher through the JCA

`Cipher.getInstance()` with a transformation whose algorithm component is a public-key or legacy symmetric cipher. The transformation string is parsed into algorithm, mode and padding, so `RSA/ECB/PKCS1Padding` is separated from `RSA/ECB/OAEPWithSHA-256AndMGF1Padding`.

A quantum computer weakens this but does not break it. Increasing the key or digest size restores the margin. Grover's algorithm halves the effective strength; the parameter, not the design, is the problem. The key size was not visible at this call site, so the weaker case is assumed.

What to do. For RSA encryption, move to ML-KEM-768 and keep RSA-OAEP only as the classical half of a hybrid during transition.

1. src/main/java/com/mastercard/developer/encryption/FieldLevelEncryptionParams.java:112 KeyGenerator generator = KeyGenerator.getInstance(SYMMETRIC_KEY_TYPE);
2. src/main/java/com/mastercard/developer/encryption/aes/AESCBC.java:31 Cipher cipher = Cipher.getInstance(CYPHER);
3. src/main/java/com/mastercard/developer/encryption/aes/AESGCM.java:29 Cipher cipher = Cipher.getInstance(CYPHER);

java.cipher · CWE-327

AES Reduced margin 2 places See details

Cipher transformation named away from the call

A JCA transformation string - `algorithm/mode/padding` - written somewhere other than a `getInstance()` argument, which is how a codebase that centralises its cryptography passes the choice to a helper. The string is unambiguous wherever it appears: nothing but a transformation is spelled that way.

This names an encryption method as text, and passes it to code elsewhere that does the work. It is the same choice, made in a different place.

What to do. The same migration applies as to the call that consumes it. Move the constant and the call together, so the inventory keeps naming the algorithm after the change.

1. src/main/java/com/mastercard/developer/encryption/aes/AESCBC.java:18 private static final String CYPHER = "AES/CBC/PKCS5Padding";
2. src/main/java/com/mastercard/developer/encryption/aes/AESGCM.java:19 private static final String CYPHER = "AES/GCM/NoPadding";

java.transformation · CWE-327

SHA-256 Reduced margin 2 places See details

Hash algorithm through the JCA

`MessageDigest.getInstance()`. MD5 and SHA-1 are reported as already broken; SHA-256 is reported as a reduced margin rather than a defect.

A quantum computer weakens this but does not break it. Increasing the key or digest size restores the margin. Pre-image resistance falls to about 128 bits of quantum work. Adequate for most uses; SHA-384 restores the full margin where a signature must last decades.

What to do. SHA-256 as the floor, SHA-384 where the digest protects something that must remain verifiable for decades.

1. src/main/java/com/mastercard/developer/encryption/EncryptionConfigBuilder.java:51 MessageDigest messageDigest = MessageDigest.getInstance("SHA-256");
2. src/test/java/com/mastercard/developer/utils/EncodingUtilsTest.java:25 test path String hex = EncodingUtils.hexEncode(MessageDigest.getInstance("SHA-256").digest("WIDDIES".getBytes()));

java.messagedigest · CWE-328

SHA-256 Reduced margin Renamed import 2 places See details

Mask-generation digest named for RSA padding

`MGF1ParameterSpec.SHA256` names the digest inside RSA-OAEP and RSA-PSS padding. It is a separate choice from the digest the signature or the cipher uses, it is frequently left at SHA-1 by default, and a static import of it - `import static java.security.spec.MGF1ParameterSpec.SHA512` - is the only place the choice appears in the file that makes it.

This picks the hash used inside RSA padding. It matters because the default is often SHA-1, which is broken today without any quantum computer.

What to do. The mask-generation digest travels with the RSA key it pads. When that key moves to ML-KEM or ML-DSA the padding goes with it; until then, SHA-256 or better.

1. src/main/java/com/mastercard/developer/encryption/FieldLevelEncryptionConfigBuilder.java:8 import static java.security.spec.MGF1ParameterSpec.SHA256;
2. src/main/java/com/mastercard/developer/encryption/FieldLevelEncryptionConfigBuilder.java:242 if (!SHA256.getDigestAlgorithm().equals(oaepPaddingDigestAlgorithm)

java.mgf1 · CWE-327

AES-128 Reduced margin 3 places See details

JOSE algorithm declared in configuration

An `alg` value in JSON or YAML. `none` is reported as a critical defect; HS* is an HMAC and is not quantum-vulnerable; RS*, PS*, ES* and EdDSA are.

A quantum computer weakens this but does not break it. Increasing the key or digest size restores the margin. Grover's algorithm halves the effective strength; the parameter, not the design, is the problem.

What to do. No standardised post-quantum JOSE algorithm exists yet. Keep token lifetimes short.

1. src/main/java/com/mastercard/developer/encryption/jwe/JweObject.java:31 private static final String A128CBC_HS256 = "A128CBC-HS256";
2. src/main/java/com/mastercard/developer/encryption/jwe/JweObject.java:32 private static final List<String> AES_GCM_ENCRYPTION_METHODS = Arrays.asList("A128GCM", "A192GCM", "A256GCM");
3. src/main/java/com/mastercard/developer/encryption/jwe/JweObject.java:51 } else if (encryptionMethod.equals(A128CBC_HS256)) {

jose.algorithm · CWE-327

AES-192 Reduced margin 1 place See details

JOSE algorithm declared in configuration

An `alg` value in JSON or YAML. `none` is reported as a critical defect; HS* is an HMAC and is not quantum-vulnerable; RS*, PS*, ES* and EdDSA are.

A quantum computer weakens this but does not break it. Increasing the key or digest size restores the margin. Grover's algorithm halves the effective strength; the parameter, not the design, is the problem.

What to do. No standardised post-quantum JOSE algorithm exists yet. Keep token lifetimes short.

1. src/main/java/com/mastercard/developer/encryption/jwe/JweObject.java:32 private static final List<String> AES_GCM_ENCRYPTION_METHODS = Arrays.asList("A128GCM", "A192GCM", "A256GCM");

jose.algorithm · CWE-327

unknown Could not be determined 1 place See details

Key store holding classical key material

`KeyStore.getInstance("JKS"|"PKCS12"|"BCFKS")`. The store format itself is not the issue; it is the inventory point where the classical private keys of this application live.

This is the application's key cupboard. It is worth knowing what is in it before planning any replacement.

What to do. Record which keys this store holds. A key store is where a migration either happens or silently does not.

1. src/main/java/com/mastercard/developer/utils/EncryptionUtils.java:90 KeyStore pkcs12KeyStore = KeyStore.getInstance("PKCS12");

java.keystore

SHA-512 Quantum-safe 13 places See details

Algorithm named in a setting

A setting whose name says it holds an algorithm, given a literal that names one: `withOaepPaddingDigestAlgorithm("SHA-512")`, `signatureAlgorithm = "SHA256withRSA"`, `"digestAlgorithm": "SHA-256"`. The algorithm never reaches a `getInstance()` in this file - it is carried to one somewhere else, often through configuration - so a scan that only reads the factories cannot see it at all.

Something here is configured to use a named algorithm. The code that uses it may be somewhere else entirely, but this is the line that decides which algorithm it is.

What to do. Find what consumes the setting. The migration belongs to that operation; this line is where the choice is actually written down, and usually where it is easiest to change.

1. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionConfigBuilderTest.java:32 test path .withOaepPaddingDigestAlgorithm("SHA-512")
2. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionConfigBuilderTest.java:79 test path .withOaepPaddingDigestAlgorithm("SHA-512")
3. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionConfigBuilderTest.java:127 test path .withOaepPaddingDigestAlgorithm("SHA-512")
4. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionConfigBuilderTest.java:157 test path .withOaepPaddingDigestAlgorithm("SHA-512")
5. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionConfigBuilderTest.java:195 test path .withOaepPaddingDigestAlgorithm("SHA-512")
6. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionConfigBuilderTest.java:234 test path .withOaepPaddingDigestAlgorithm("SHA-512")
7. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionConfigBuilderTest.java:268 test path .withOaepPaddingDigestAlgorithm("SHA-512")
8. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionConfigBuilderTest.java:302 test path .withOaepPaddingDigestAlgorithm("SHA-512")
9. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionConfigBuilderTest.java:314 test path .withOaepPaddingDigestAlgorithm("SHA-512")
10. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionConfigBuilderTest.java:326 test path .withOaepPaddingDigestAlgorithm("SHA-512")
11. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionConfigBuilderTest.java:338 test path .withOaepPaddingDigestAlgorithm("SHA-512")
12. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionConfigBuilderTest.java:350 test path .withOaepPaddingDigestAlgorithm("SHA-512")
13. src/test/java/com/mastercard/developer/encryption/FieldLevelEncryptionConfigBuilderTest.java:364 test path .withOaepPaddingDigestAlgorithm("SHA-512")

config.algorithm-setting · CWE-327

AES-256 Quantum-safe 5 places See details

JOSE algorithm declared in configuration

An `alg` value in JSON or YAML. `none` is reported as a critical defect; HS* is an HMAC and is not quantum-vulnerable; RS*, PS*, ES* and EdDSA are.

No known quantum attack changes how strong this is. No known quantum algorithm changes the security margin.

What to do. No standardised post-quantum JOSE algorithm exists yet. Keep token lifetimes short.

1. src/main/java/com/mastercard/developer/encryption/JweEncryption.java:21 private static final String ENCRYPTION = "A256GCM";
2. src/main/java/com/mastercard/developer/encryption/JweEncryption.java:90 JweHeader myHeader = new JweHeader(ALGORITHM, ENCRYPTION, config.encryptionKeyFingerprint, CONTENT_TYPE);
3. src/main/java/com/mastercard/developer/encryption/jwe/JweObject.java:32 private static final List<String> AES_GCM_ENCRYPTION_METHODS = Arrays.asList("A128GCM", "A192GCM", "A256GCM");
4. src/test/java/com/mastercard/developer/encryption/jwe/JweHeaderTest.java:12 test path JweHeader header = new JweHeader("RSA-OAEP-256", "A256GCM", "123", "application/json");
5. src/test/java/com/mastercard/developer/encryption/jwe/JweHeaderTest.java:19 test path assertEquals("A256GCM", header.getEnc());

jose.algorithm · CWE-327

SHA-512 Quantum-safe Renamed import 2 places See details

Mask-generation digest named for RSA padding

`MGF1ParameterSpec.SHA256` names the digest inside RSA-OAEP and RSA-PSS padding. It is a separate choice from the digest the signature or the cipher uses, it is frequently left at SHA-1 by default, and a static import of it - `import static java.security.spec.MGF1ParameterSpec.SHA512` - is the only place the choice appears in the file that makes it.

This picks the hash used inside RSA padding. It matters because the default is often SHA-1, which is broken today without any quantum computer.

What to do. The mask-generation digest travels with the RSA key it pads. When that key moves to ML-KEM or ML-DSA the padding goes with it; until then, SHA-256 or better.

1. src/main/java/com/mastercard/developer/encryption/FieldLevelEncryptionConfigBuilder.java:9 import static java.security.spec.MGF1ParameterSpec.SHA512;
2. src/main/java/com/mastercard/developer/encryption/FieldLevelEncryptionConfigBuilder.java:243 && !SHA512.getDigestAlgorithm().equals(oaepPaddingDigestAlgorithm)) {

java.mgf1 · CWE-327

CSPRNG Quantum-safe 1 place See details

Random number generation

`SecureRandom`. A platform CSPRNG is not a quantum exposure; it is recorded because an inventory that omits the randomness source is incomplete. `SHA1PRNG` is named explicitly where it appears, since it is a legacy algorithm even though its output is adequate.

This is where the software gets its random numbers. Quantum computers do not weaken it.

What to do. No action. Prefer the platform default over naming an algorithm.

1. src/main/java/com/mastercard/developer/encryption/aes/AESEncryption.java:29 SecureRandom random = new SecureRandom();

java.rng