hyperchain/javasdk

DES Already broken 4 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`.

This is already unsafe today, with no quantum computer involved. A 56-bit key is brute-forced classically in hours.

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/cn/hyperchain/sdk/crypto/CipherUtil.java:51 SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("DES");
2. src/main/java/cn/hyperchain/sdk/crypto/CipherUtil.java:53 Cipher cipher = Cipher.getInstance("DES");
3. src/main/java/cn/hyperchain/sdk/crypto/CipherUtil.java:83 SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("DES");
4. src/main/java/cn/hyperchain/sdk/crypto/CipherUtil.java:85 Cipher cipher = Cipher.getInstance("DES");

java.cipher · CWE-327

3DES Already broken 2 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/cn/hyperchain/sdk/crypto/CipherUtil.java:140 Key key = new SecretKeySpec(keyBytes, "DESede");
2. src/main/java/cn/hyperchain/sdk/crypto/CipherUtil.java:159 Key key = new SecretKeySpec(keyBytes, "DESede");

java.keyspec · CWE-327

3DES Already broken 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`.

This is already unsafe today, with no quantum computer involved. Triple DES is withdrawn by NIST and limited by its 64-bit block, independent of quantum.

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/cn/hyperchain/sdk/crypto/CipherUtil.java:142 Cipher in = Cipher.getInstance("DESede/CBC/PKCS5Padding");
2. src/main/java/cn/hyperchain/sdk/crypto/CipherUtil.java:161 Cipher out = Cipher.getInstance("DESede/CBC/PKCS5Padding");

java.cipher · CWE-327

DES Already broken 2 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/cn/hyperchain/sdk/crypto/CipherUtil.java:50 DESKeySpec desKey = new DESKeySpec(password.getBytes(Utils.DEFAULT_CHARSET));
2. src/main/java/cn/hyperchain/sdk/crypto/CipherUtil.java:82 DESKeySpec desKey = new DESKeySpec(password.getBytes(Utils.DEFAULT_CHARSET));

java.keyspec · CWE-327

MD5 Already broken 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.

This is already unsafe today, with no quantum computer involved. Practical chosen-prefix collisions exist; MD5 has no remaining security as a digest.

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/cn/hyperchain/sdk/common/utils/FileExtra.java:60 MessageDigest fileMD5 = MessageDigest.getInstance("MD5");
2. src/main/java/cn/hyperchain/sdk/common/utils/FileExtra.java:61 MessageDigest blockMD5 = MessageDigest.getInstance("MD5");

java.messagedigest · CWE-328

SHA-1 Already broken 1 place 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.

This is already unsafe today, with no quantum computer involved. SHAttered and subsequent work produced practical collisions; NIST withdrew SHA-1 in 2030 guidance and it is already unacceptable for signatures.

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/cn/hyperchain/sdk/crypto/HashUtil.java:67 messageDigest = MessageDigest.getInstance("SHA-1");

java.messagedigest · CWE-328

ECDSA Quantum-vulnerable 57 places See details

Elliptic-curve cryptography through BouncyCastle

A BouncyCastle elliptic-curve class. `ECDHBasicAgreement` in particular is key establishment and carries harvest-now-decrypt-later exposure.

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. ML-DSA-65 for signatures, ML-KEM-768 for key establishment.

1. src/main/java/cn/hyperchain/sdk/account/Account.java:22 import org.bouncycastle.crypto.params.ECPrivateKeyParameters;
2. src/main/java/cn/hyperchain/sdk/account/Account.java:23 import org.bouncycastle.crypto.params.ECPublicKeyParameters;
3. src/main/java/cn/hyperchain/sdk/account/Account.java:114 ECPublicKeyParameters publicKeyParameters = new ECPublicKeyParameters(ecPoint, SM2Util.DOMAIN_PARAMS);
4. src/main/java/cn/hyperchain/sdk/account/Account.java:115 ECPrivateKeyParameters privateKeyParameters = new ECPrivateKeyParameters(new BigInteger(1, privateKey), SM2Util.DOMAIN_PARAMS);
5. src/main/java/cn/hyperchain/sdk/account/Account.java:121 ECPublicKeyParameters publicKeyParametersFromPrivateKey = new ECPublicKeyParameters(ecPointPublicKeyFromPrivateKey, privateKeyParameters.getParameters());
6. src/main/java/cn/hyperchain/sdk/account/R1Account.java:10 import org.bouncycastle.crypto.params.ECPublicKeyParameters;
7. src/main/java/cn/hyperchain/sdk/account/R1Account.java:64 return R1Util.verify(hash, realSig, (ECPublicKeyParameters)keyPair.getPublic());
8. src/main/java/cn/hyperchain/sdk/account/R1Account.java:79 return R1Util.verify(hash, realSig, (ECPublicKeyParameters)keyPair.getPublic());
9. src/main/java/cn/hyperchain/sdk/account/SMAccount.java:9 import org.bouncycastle.crypto.params.ECPublicKeyParameters;
10. src/main/java/cn/hyperchain/sdk/account/SMAccount.java:56 ECPublicKeyParameters ecPublicKeyParameters = (ECPublicKeyParameters) this.keyPair.getPublic();
11. src/main/java/cn/hyperchain/sdk/account/SMAccount.java:71 ECPublicKeyParameters ecPublicKeyParameters = (ECPublicKeyParameters) this.keyPair.getPublic();
12. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:23 import cn.hyperchain.sdk.crypto.jce.ECKeyPairGenerator;
13. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:32 import org.bouncycastle.asn1.x9.X9ECParameters;
14. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:34 import org.bouncycastle.crypto.agreement.ECDHBasicAgreement;
15. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:39 import org.bouncycastle.crypto.params.ECPrivateKeyParameters;
16. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:40 import org.bouncycastle.crypto.params.ECPublicKeyParameters;
17. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:43 import org.bouncycastle.crypto.signers.ECDSASigner;
18. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:118 X9ECParameters params = SECNamedCurves.getByName("secp256k1");
19. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:203 final KeyPairGenerator keyPairGen = ECKeyPairGenerator.getInstance(provider, secureRandom);
20. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:763 ECDSASigner signer = new ECDSASigner(new HMacDSAKCalculator(new SHA256Digest()));
21. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:764 ECPrivateKeyParameters privKeyParams = new ECPrivateKeyParameters(((BCECPrivateKey) privKey).getD(), CURVE);
22. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:908 final ECDHBasicAgreement agreement = new ECDHBasicAgreement();
23. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:909 agreement.init(new ECPrivateKeyParameters(((BCECPrivateKey) privKey).getD(), CURVE));
24. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:910 return agreement.calculateAgreement(new ECPublicKeyParameters(otherParty, CURVE));
25. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:988 ECDSASigner signer = new ECDSASigner();
26. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:989 ECPublicKeyParameters params = new ECPublicKeyParameters(CURVE.getCurve().decodePoint(pub), CURVE);
27. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:13 import org.bouncycastle.asn1.x9.X9ECParameters;
28. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:18 import org.bouncycastle.crypto.generators.ECKeyPairGenerator;
29. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:21 import org.bouncycastle.crypto.params.ECPrivateKeyParameters;
30. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:22 import org.bouncycastle.crypto.params.ECPublicKeyParameters;
31. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:24 import org.bouncycastle.crypto.signers.ECDSASigner;
32. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:45 X9ECParameters params = SECNamedCurves.getByName("secp256r1");
33. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:59 ECKeyPairGenerator keyGen = new ECKeyPairGenerator();
34. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:71 ECPrivateKeyParameters privateKeyParameters = (ECPrivateKeyParameters)keyPair.getPrivate();
35. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:74 ECPublicKeyParameters publicKeyParametersFromPrivateKey = new ECPublicKeyParameters(ecPointPublicKeyFromPrivateKey, privateKeyParameters.getParameters());
36. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:89 ECPrivateKeyParameters privateKeyParameters = new ECPrivateKeyParameters(new BigInteger(1, keyPair), CURVE);
37. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:103 ECDSASigner signer = new ECDSASigner(new HMacDSAKCalculator(new SHA256Digest()));
38. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:132 ECPrivateKeyParameters privateKeyParameters = new ECPrivateKeyParameters(new BigInteger(1, privKey), CURVE);
39. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:146 ECPublicKeyParameters params = new ECPublicKeyParameters(CURVE.getCurve().decodePoint(publicKey), CURVE);
40. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:158 public static boolean verify(byte[] sourceData, byte[] signature, ECPublicKeyParameters ecPublicKeyParameters) {
41. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:159 ECDSASigner signer = new ECDSASigner();
42. src/main/java/cn/hyperchain/sdk/crypto/jce/ECKeyPairGenerator.java:12 public final class ECKeyPairGenerator {
43. src/main/java/cn/hyperchain/sdk/crypto/jce/ECKeyPairGenerator.java:30 private ECKeyPairGenerator() {
44. src/main/java/cn/hyperchain/sdk/crypto/sm/sm2/SM2Util.java:6 import org.bouncycastle.crypto.generators.ECKeyPairGenerator;
45. src/main/java/cn/hyperchain/sdk/crypto/sm/sm2/SM2Util.java:9 import org.bouncycastle.crypto.params.ECPrivateKeyParameters;
46. src/main/java/cn/hyperchain/sdk/crypto/sm/sm2/SM2Util.java:11 import org.bouncycastle.crypto.params.ECPublicKeyParameters;
47. src/main/java/cn/hyperchain/sdk/crypto/sm/sm2/SM2Util.java:44 ECKeyPairGenerator keyGen = new ECKeyPairGenerator();
48. src/main/java/cn/hyperchain/sdk/crypto/sm/sm2/SM2Util.java:58 ECPrivateKeyParameters privateKeyParameters = new ECPrivateKeyParameters(new BigInteger(1, keyPair), SM2Util.DOMAIN_PARAMS);
49. src/main/java/cn/hyperchain/sdk/crypto/sm/sm2/SM2Util.java:80 ECPrivateKeyParameters privateKeyParameters = new ECPrivateKeyParameters(new BigInteger(1, privKey), SM2Util.DOMAIN_PARAMS);
50. src/main/java/cn/hyperchain/sdk/crypto/sm/sm2/SM2Util.java:123 ECPublicKeyParameters ecPublicKeyParameters = new ECPublicKeyParameters(ecPoint, DOMAIN_PARAMS);
51. src/main/java/cn/hyperchain/sdk/crypto/sm/sm2/SM2Util.java:135 public static boolean verify(byte[] sourceData, byte[] signature, ECPublicKeyParameters ecPublicKeyParameters) {
52. src/main/java/cn/hyperchain/sdk/service/impl/AccountServiceImpl.java:29 import org.bouncycastle.crypto.params.ECPrivateKeyParameters;
53. src/main/java/cn/hyperchain/sdk/service/impl/AccountServiceImpl.java:30 import org.bouncycastle.crypto.params.ECPublicKeyParameters;
54. src/main/java/cn/hyperchain/sdk/service/impl/AccountServiceImpl.java:77 ECPrivateKeyParameters ecPriv = (ECPrivateKeyParameters) keyPair.getPrivate();
55. src/main/java/cn/hyperchain/sdk/service/impl/AccountServiceImpl.java:78 ECPublicKeyParameters ecPub = (ECPublicKeyParameters) keyPair.getPublic();
56. src/main/java/cn/hyperchain/sdk/service/impl/AccountServiceImpl.java:88 ECPrivateKeyParameters ecPriv = (ECPrivateKeyParameters) keyPair.getPrivate();
57. src/main/java/cn/hyperchain/sdk/service/impl/AccountServiceImpl.java:89 ECPublicKeyParameters ecPub = (ECPublicKeyParameters) keyPair.getPublic();

java.bouncycastle.ec · CWE-327

Ed25519255-bitother/Ed25519 Quantum-vulnerable 5 places See details

Edwards-curve signatures through BouncyCastle

Ed25519 or Ed448 through BouncyCastle. Edwards curves are modern and well built, and Shor breaks them exactly as it breaks every other discrete-logarithm scheme.

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. ML-DSA-65 (FIPS 204).

1. src/main/java/cn/hyperchain/sdk/crypto/ed25519/ED25519Util.java:9 import org.bouncycastle.crypto.signers.Ed25519Signer;
2. src/main/java/cn/hyperchain/sdk/crypto/ed25519/ED25519Util.java:23 Ed25519Signer signer = new Ed25519Signer();
3. src/main/java/cn/hyperchain/sdk/crypto/ed25519/ED25519Util.java:53 Ed25519Signer signer = new Ed25519Signer();
4. src/main/java/cn/hyperchain/sdk/service/impl/AccountServiceImpl.java:28 import org.bouncycastle.crypto.generators.Ed25519KeyPairGenerator;
5. src/main/java/cn/hyperchain/sdk/service/impl/AccountServiceImpl.java:106 Ed25519KeyPairGenerator ed25519KeyPairGenerator = new Ed25519KeyPairGenerator();

java.bouncycastle.eddsa · CWE-327

ECDH Quantum-vulnerable Recorded traffic 4 places See details

Classical key pair generated through the JCA

`KeyPairGenerator.getInstance()` with a classical algorithm. The concrete family and, where an `initialize()` call is close enough to read, the key size are resolved from the source and reported on the finding.

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. Generate the classical key alongside an ML-KEM or ML-DSA key and carry both until relying parties accept the post-quantum one.

1. src/main/java/cn/hyperchain/sdk/crypto/jce/ECKeyPairGenerator.java:38 INSTANCE = KeyPairGenerator.getInstance(ALGORITHM);
2. src/main/java/cn/hyperchain/sdk/crypto/jce/ECKeyPairGenerator.java:54 final KeyPairGenerator gen = KeyPairGenerator.getInstance(ALGORITHM, provider);
3. src/main/java/cn/hyperchain/sdk/crypto/jce/ECKeyPairGenerator.java:66 final KeyPairGenerator gen = KeyPairGenerator.getInstance(ALGORITHM, provider);
4. src/main/java/cn/hyperchain/sdk/crypto/jce/ECKeyPairGenerator.java:78 final KeyPairGenerator gen = KeyPairGenerator.getInstance(ALGORITHM, provider);

java.keypairgenerator · CWE-327

ECDSA Quantum-vulnerable 4 places See details

Classical signature algorithm through the JCA

`Signature.getInstance()` with a classical algorithm. The digest and the key algorithm are split out of the JCA name, so `SHA1withRSA` reports both the broken digest and the quantum-vulnerable key.

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. ML-DSA-65 (FIPS 204). Where the verifier cannot be changed, sign twice and publish both signatures.

1. src/main/java/cn/hyperchain/sdk/crypto/cert/CertKeyPair.java:65 ecdsaSign = Signature.getInstance("SHA256withECDSA", new BouncyCastleProvider());
2. src/main/java/cn/hyperchain/sdk/crypto/jce/ECSignatureFactory.java:20 return Signature.getInstance(RAW_ALGORITHM);
3. src/main/java/cn/hyperchain/sdk/crypto/jce/ECSignatureFactory.java:28 return Signature.getInstance(RAW_ALGORITHM, provider);
4. src/main/java/cn/hyperchain/sdk/crypto/jce/ECSignatureFactory.java:36 return Signature.getInstance(RAW_ALGORITHM, provider);

java.signature · CWE-327

ECDH Quantum-vulnerable Recorded traffic 3 places See details

Classical key agreement through the JCA

`KeyAgreement.getInstance()` with ECDH, DH or XDH. Key agreement is the highest-priority class of finding: traffic recorded today is decrypted once the key exchange is broken.

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. ML-KEM-768 (FIPS 203), or a hybrid X25519+ML-KEM-768 construction that keeps the classical guarantee while adding the quantum one.

1. src/main/java/cn/hyperchain/sdk/crypto/jce/ECKeyAgreement.java:20 return KeyAgreement.getInstance(ALGORITHM);
2. src/main/java/cn/hyperchain/sdk/crypto/jce/ECKeyAgreement.java:28 return KeyAgreement.getInstance(ALGORITHM, provider);
3. src/main/java/cn/hyperchain/sdk/crypto/jce/ECKeyAgreement.java:36 return KeyAgreement.getInstance(ALGORITHM, provider);

java.keyagreement · CWE-327

ECDH Quantum-vulnerable Recorded traffic 3 places 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/cn/hyperchain/sdk/crypto/jce/ECKeyFactory.java:23 INSTANCE = KeyFactory.getInstance(ALGORITHM);
2. src/main/java/cn/hyperchain/sdk/crypto/jce/ECKeyFactory.java:36 return KeyFactory.getInstance(ALGORITHM, provider);
3. src/main/java/cn/hyperchain/sdk/crypto/jce/ECKeyFactory.java:44 return KeyFactory.getInstance(ALGORITHM, provider);

java.keyfactory · CWE-327

ECDH256-bitsecg/secp256k1 Quantum-vulnerable Recorded traffic 2 places See details

Named elliptic curve requested

`ECGenParameterSpec` names a curve explicitly. Every standardised prime curve is broken by Shor regardless of its size, so a larger curve is not a mitigation.

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. ML-DSA-65 for signatures, ML-KEM-768 for key establishment.

1. src/main/java/cn/hyperchain/sdk/crypto/jce/ECAlgorithmParameters.java:22 = new ECGenParameterSpec(CURVE_NAME);
2. src/main/java/cn/hyperchain/sdk/crypto/jce/ECKeyPairGenerator.java:25 = new ECGenParameterSpec(CURVE_NAME);

java.eccurve · CWE-327

ECDH256-bitsecg/secp256r1 Quantum-vulnerable Recorded traffic 1 place See details

Named elliptic curve requested

`ECGenParameterSpec` names a curve explicitly. Every standardised prime curve is broken by Shor regardless of its size, so a larger curve is not a mitigation.

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. ML-DSA-65 for signatures, ML-KEM-768 for key establishment.

1. src/main/java/cn/hyperchain/sdk/crypto/jce/ECKeyPairGenerator.java:28 = new ECGenParameterSpec(CURVE_NAMER1);

java.eccurve · CWE-327

ECDSA 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/cert.cer:1 test path -----BEGIN CERTIFICATE-----

pem.certificate

ECDSA Quantum-vulnerable 1 place See details

Public key file

A PEM public-key block. The algorithm is read from the SubjectPublicKeyInfo.

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. Inventory only; a public key is not itself a secret.

1. src/test/resources/certs/guomi/unique_guomi.pub:1 test path -----BEGIN PUBLIC KEY-----

pem.public-key

TLS Quantum-vulnerable Recorded traffic 1 place See details

TLS context created in code

`SSLContext.getInstance()`. The protocol version is reported; the key exchange it negotiates is classical in every TLS 1.2 and 1.3 cipher suite available today.

A quantum computer of sufficient size breaks this completely. It has to be replaced, not tuned. Every TLS cipher suite in general use negotiates a classical key exchange, so a recorded session is decryptable once that exchange falls.

What to do. Keep TLS 1.3, and track the hybrid key-exchange groups as they reach the JDK. TLS is where harvest-now-decrypt-later exposure is largest.

1. src/main/java/cn/hyperchain/sdk/common/utils/HttpsUtils.java:85 sslContext = SSLContext.getInstance("TLSv1.2");

java.sslcontext · CWE-757

AES Reduced margin 2 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/cn/hyperchain/sdk/crypto/CipherUtil.java:102 Key key = new SecretKeySpec(keyBytes, "AES");
2. src/main/java/cn/hyperchain/sdk/crypto/CipherUtil.java:121 Key key = new SecretKeySpec(keyBytes, "AES");

java.keyspec · CWE-327

AES Reduced margin 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 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/cn/hyperchain/sdk/crypto/CipherUtil.java:104 Cipher in = Cipher.getInstance("AES/CBC/PKCS5Padding");
2. src/main/java/cn/hyperchain/sdk/crypto/CipherUtil.java:123 Cipher out = Cipher.getInstance("AES/CBC/PKCS5Padding");

java.cipher · 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/cn/hyperchain/sdk/crypto/HashUtil.java:44 messageDigest = MessageDigest.getInstance("SHA-256");
2. src/main/java/cn/hyperchain/sdk/crypto/cert/CertKeyPair.java:65 ecdsaSign = Signature.getInstance("SHA256withECDSA", new BouncyCastleProvider());

java.messagedigest · CWE-328

SM4 Reduced margin 1 place 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/cn/hyperchain/sdk/crypto/sm/sm4/SM4Util.java:76 Key sm4Key = new SecretKeySpec(key, ALGORITHM_NAME);

java.keyspec · CWE-327

AES Reduced margin 4 places See details

Symmetric cipher through BouncyCastle

A BouncyCastle symmetric engine or mode. Symmetric encryption is not broken by a quantum computer, so these are inventoried rather than flagged - but a complete cryptographic inventory has to contain them, and the mode is where AES-256 or a 64-bit block shows up.

This is the kind of encryption that quantum computers do not break. It is listed so the inventory is complete.

What to do. Use a 256-bit key. No change of algorithm is required unless the engine is DES, RC4 or Blowfish.

1. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:36 import org.bouncycastle.crypto.engines.AESFastEngine;
2. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:37 import org.bouncycastle.crypto.modes.SICBlockCipher;
3. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:947 AESFastEngine engine = new AESFastEngine();
4. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:948 SICBlockCipher ctrEngine = new SICBlockCipher(engine);

java.bouncycastle.symmetric

SHA-256 Reduced margin 4 places See details

Digest through BouncyCastle

A BouncyCastle digest class. The digest name is read from the class, so `MD5Digest` and `SHA512Digest` are the same rule with opposite conclusions.

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 long-lived. MD5 and SHA-1 need replacing now.

1. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:35 import org.bouncycastle.crypto.digests.SHA256Digest;
2. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:763 ECDSASigner signer = new ECDSASigner(new HMacDSAKCalculator(new SHA256Digest()));
3. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:17 import org.bouncycastle.crypto.digests.SHA256Digest;
4. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:103 ECDSASigner signer = new ECDSASigner(new HMacDSAKCalculator(new SHA256Digest()));

java.bouncycastle.digest · CWE-328

SM3 Reduced margin 2 places See details

Digest through BouncyCastle

A BouncyCastle digest class. The digest name is read from the class, so `MD5Digest` and `SHA512Digest` are the same rule with opposite conclusions.

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. SHA-256 as the floor, SHA-384 where the digest protects something long-lived. MD5 and SHA-1 need replacing now.

1. src/main/java/cn/hyperchain/sdk/crypto/sm/sm3/SM3Util.java:3 import org.bouncycastle.crypto.digests.SM3Digest;
2. src/main/java/cn/hyperchain/sdk/crypto/sm/sm3/SM3Util.java:13 SM3Digest sm3Digest = new SM3Digest();

java.bouncycastle.digest · CWE-328

unknown Could not be determined 4 places 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/cn/hyperchain/sdk/common/utils/HttpsUtils.java:215 final KeyStore keystore = KeyStore.getInstance("JKS");
2. src/main/java/cn/hyperchain/sdk/crypto/cert/CertUtils.java:102 KeyStore ks = KeyStore.getInstance("PKCS12", "BC");
3. src/main/java/cn/hyperchain/sdk/crypto/cert/CertUtils.java:130 KeyStore ks = KeyStore.getInstance("PKCS12");
4. src/main/java/cn/hyperchain/sdk/crypto/cert/CertUtils.java:168 KeyStore ks = KeyStore.getInstance("PKCS12");

java.keystore

unknown Could not be determined 1 place See details

Key pair algorithm chosen at runtime

`KeyPairGenerator.getInstance(x)` where the argument is an identifier. The algorithm cannot be resolved without running the program, so this is reported as an unknown rather than assumed to be classical.

This code picks its encryption method while it runs, so a scan cannot tell which one it ends up using. Somebody has to check the configuration.

What to do. Trace the value to its configuration source and record the concrete algorithm in the cryptographic inventory by hand.

1. src/main/java/cn/hyperchain/sdk/crypto/sm/sm4/SM4Util.java:75 Cipher cipher = Cipher.getInstance(algorithmName, BouncyCastleProvider.PROVIDER_NAME);

java.keypairgenerator.variable · CWE-327

CSPRNG Quantum-safe 7 places 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/cn/hyperchain/sdk/crypto/CipherUtil.java:49 SecureRandom random = new SecureRandom();
2. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/ECKey.java:122 secureRandom = new SecureRandom();
3. src/main/java/cn/hyperchain/sdk/crypto/ecdsa/R1Util.java:49 secureRandom = new SecureRandom();
4. src/main/java/cn/hyperchain/sdk/crypto/ed25519/ED25519Util.java:24 CipherParameters param = new ParametersWithRandom(keyPair.getPrivate(), new SecureRandom());
5. src/main/java/cn/hyperchain/sdk/crypto/sm/sm2/SM2Util.java:42 SecureRandom random = new SecureRandom();
6. src/main/java/cn/hyperchain/sdk/crypto/sm/sm4/SM4Util.java:83 Random random = SecureRandom.getInstance("SHA1PRNG");
7. src/main/java/cn/hyperchain/sdk/service/impl/AccountServiceImpl.java:99 ecKey = new ECKey(new SecureRandom());

java.rng