Peergos/Peergos

RSAES-PKCS1v15 Already broken Recorded traffic 5 places See details

TLS cipher suite named in source

A cipher suite written into the code rather than into a configuration file - `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`, or the OpenSSL spelling `ECDHE-RSA-AES128-GCM-SHA256`. The key exchange is reported, and the bulk cipher separately when it is one of the broken ones.

This code names the exact cryptography its TLS connections may use. Because the list is in the program rather than in a settings file, changing it needs a new release - which is the thing that makes a migration slow.

What to do. A hardcoded suite list ships with the binary and cannot be changed without a release, so move it to configuration first. The key exchange changes when the TLS library offers a hybrid group, not before.

1. src/peergos/server/UserService.java:48 "TLS_RSA_WITH_NULL_SHA256," +
2. src/peergos/server/UserService.java:49 "TLS_RSA_WITH_AES_128_GCM_SHA256," +
3. src/peergos/server/UserService.java:50 "TLS_RSA_WITH_AES_128_CBC_SHA256, " +
4. src/peergos/server/UserService.java:51 "TLS_RSA_WITH_AES_256_GCM_SHA384, " +
5. src/peergos/server/UserService.java:52 "TLS_RSA_WITH_AES_256_CBC_SHA256, " +

config.cipher-suite · CWE-757

MD5 Already broken 4 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/peergos/server/storage/S3BucketSync.java:103 MessageDigest md = MessageDigest.getInstance("MD5");
2. src/peergos/server/tests/ThumbnailCacheSeederTests.java:37 test path byte[] d = MessageDigest.getInstance("MD5").digest(s.getBytes(StandardCharsets.UTF_8));
3. src/peergos/server/webdav/ThumbnailCacheSeeder.java:154 byte[] digest = MessageDigest.getInstance("MD5").digest(s.getBytes(StandardCharsets.UTF_8));
4. src/peergos/server/webdav/modeshape/webdav/WebDavServletBean.java:58 MD5_HELPER = MessageDigest.getInstance("MD5");

java.messagedigest · CWE-328

ECDH Quantum-vulnerable Recorded traffic 15 places See details

TLS cipher suite named in source

A cipher suite written into the code rather than into a configuration file - `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`, or the OpenSSL spelling `ECDHE-RSA-AES128-GCM-SHA256`. The key exchange is reported, and the bulk cipher separately when it is one of the broken ones.

This code names the exact cryptography its TLS connections may use. Because the list is in the program rather than in a settings file, changing it needs a new release - which is the thing that makes a migration slow.

What to do. A hardcoded suite list ships with the binary and cannot be changed without a release, so move it to configuration first. The key exchange changes when the TLS library offers a hybrid group, not before.

1. README.md:264 ssl_ciphers TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:!TLS_AES_128_GCM_SHA256;
2. src/peergos/server/UserService.java:53 "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, " +
3. src/peergos/server/UserService.java:54 "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, " +
4. src/peergos/server/UserService.java:55 "TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, " +
5. src/peergos/server/UserService.java:56 "TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384," +
6. src/peergos/server/UserService.java:57 "TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384," +
7. src/peergos/server/UserService.java:58 "TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, " +
8. src/peergos/server/UserService.java:59 "TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384," +
9. src/peergos/server/UserService.java:60 "TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384," +
10. src/peergos/server/UserService.java:61 "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256," +
11. src/peergos/server/UserService.java:62 "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384," +
12. src/peergos/server/UserService.java:63 "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256," +
13. src/peergos/server/UserService.java:64 "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,"
14. src/peergos/server/UserService.java:210 "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
15. src/peergos/server/UserService.java:211 "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",

config.cipher-suite · CWE-757

DH Quantum-vulnerable Recorded traffic 2 places See details

TLS cipher suite named in source

A cipher suite written into the code rather than into a configuration file - `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`, or the OpenSSL spelling `ECDHE-RSA-AES128-GCM-SHA256`. The key exchange is reported, and the bulk cipher separately when it is one of the broken ones.

This code names the exact cryptography its TLS connections may use. Because the list is in the program rather than in a settings file, changing it needs a new release - which is the thing that makes a migration slow.

What to do. A hardcoded suite list ships with the binary and cannot be changed without a release, so move it to configuration first. The key exchange changes when the TLS library offers a hybrid group, not before.

1. src/peergos/server/UserService.java:212 "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256",
2. src/peergos/server/UserService.java:213 "TLS_DHE_RSA_WITH_AES_256_GCM_SHA384"

config.cipher-suite · CWE-757

ECDSA Quantum-vulnerable 2 places See details

COSE algorithm identifier

A COSE algorithm named as an identifier or as its IANA registry number - `COSEAlgorithmIdentifier.ES256`, or `alg: -7` in a WebAuthn `pubKeyCredParams`. The names match JOSE's; the numbers are the registry's.

This is the list of signature algorithms a security key or a passkey is allowed to use. Every one available today is broken by a quantum computer, so the value of writing it down now is knowing where to look later.

What to do. No post-quantum COSE algorithm is registered for WebAuthn yet. Record the exposure and keep the list short, so there is less to change when one is.

1. src/peergos/server/login/Webauthn.java:98 new EC2COSEKey(null, COSEAlgorithmIdentifier.ES256, null, Curve.SECP256R1, x, y, null));
2. src/peergos/server/tests/StandaloneWebauthnDemo.java:72 test path " pubKeyCredParams: [ {type: \"public-key\", alg: -8}, {type: \"public-key\", alg: -7}, {type: \"public-key\", alg: -257}]\n" +

cose.algorithm

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

COSE algorithm identifier

A COSE algorithm named as an identifier or as its IANA registry number - `COSEAlgorithmIdentifier.ES256`, or `alg: -7` in a WebAuthn `pubKeyCredParams`. The names match JOSE's; the numbers are the registry's.

This is the list of signature algorithms a security key or a passkey is allowed to use. Every one available today is broken by a quantum computer, so the value of writing it down now is knowing where to look later.

What to do. No post-quantum COSE algorithm is registered for WebAuthn yet. Record the exposure and keep the list short, so there is less to change when one is.

1. src/peergos/server/login/Webauthn.java:104 new EdDSACOSEKey(null, COSEAlgorithmIdentifier.EdDSA, null, Curve.ED25519, Arrays.copyOfRange(rawD, 1017, 1017 + 32), null));
2. src/peergos/server/tests/StandaloneWebauthnDemo.java:72 test path " pubKeyCredParams: [ {type: \"public-key\", alg: -8}, {type: \"public-key\", alg: -7}, {type: \"public-key\", alg: -257}]\n" +

cose.algorithm

Ed25519255-bitother/Ed25519 Quantum-vulnerable 2 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/peergos/server/tests/NitrokeyWebauthn.java:67 test path this.keys = KeyPairGenerator.getInstance("Ed25519").generateKeyPair();
2. src/peergos/server/tests/NitrokeyWebauthn.java:76 test path Signature sig = Signature.getInstance("Ed25519");

jose.algorithm · CWE-327

Ed25519255-bitother/Ed25519 Quantum-vulnerable 1 place 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/peergos/server/tests/NitrokeyWebauthn.java:67 test path this.keys = KeyPairGenerator.getInstance("Ed25519").generateKeyPair();

java.keypairgenerator · CWE-327

Ed25519255-bitother/Ed25519 Quantum-vulnerable 1 place 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/peergos/server/tests/NitrokeyWebauthn.java:76 test path Signature sig = Signature.getInstance("Ed25519");

java.signature · CWE-327

RSASSA-PKCS1v15 Quantum-vulnerable 1 place See details

COSE algorithm identifier

A COSE algorithm named as an identifier or as its IANA registry number - `COSEAlgorithmIdentifier.ES256`, or `alg: -7` in a WebAuthn `pubKeyCredParams`. The names match JOSE's; the numbers are the registry's.

This is the list of signature algorithms a security key or a passkey is allowed to use. Every one available today is broken by a quantum computer, so the value of writing it down now is knowing where to look later.

What to do. No post-quantum COSE algorithm is registered for WebAuthn yet. Record the exposure and keep the list short, so there is less to change when one is.

1. src/peergos/server/tests/StandaloneWebauthnDemo.java:72 test path " pubKeyCredParams: [ {type: \"public-key\", alg: -8}, {type: \"public-key\", alg: -7}, {type: \"public-key\", alg: -257}]\n" +

cose.algorithm

TLS Quantum-vulnerable Recorded traffic 1 place See details

TLS cipher suites pinned in configuration

An `ssl_ciphers`, `SSLCipherSuite` or `ssl-default-bind-ciphers` directive. Every suite available today uses a classical key exchange; a suite naming RC4, DES, 3DES, EXPORT or NULL is broken now.

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. Remove anything below TLS 1.2. The key exchange changes when the server software offers a hybrid group, not before.

1. README.md:263

config.tls-ciphers · CWE-757

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/peergos/server/UserService.java:194 SSLContext sslContext = SSLContext.getInstance("TLS");

java.sslcontext · CWE-757

SHA-256 Reduced margin 18 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/peergos/server/cfapi/CloudFilesMount.java:733 java.security.MessageDigest md = java.security.MessageDigest.getInstance("SHA-256");
2. src/peergos/server/crypto/hash/ScryptJava.java:91 Mac mac = Mac.getInstance(algorithm);
3. src/peergos/server/crypto/hash/ScryptJava.java:116 MessageDigest chunkHash = MessageDigest.getInstance("SHA-256");
4. src/peergos/server/crypto/hash/ScryptJava.java:124 chunkHash = MessageDigest.getInstance("SHA-256");
5. src/peergos/server/crypto/hash/lambdaworks/crypto/SCrypt.java:86 Mac mac = Mac.getInstance("HmacSHA256");
6. src/peergos/server/storage/LocalS3Handler.java:421 Mac mac = Mac.getInstance("HmacSHA256");
7. src/peergos/server/storage/LocalS3Handler.java:429 return MessageDigest.getInstance("SHA-256").digest(data);
8. src/peergos/server/storage/RAMStorage.java:272 MessageDigest md = MessageDigest.getInstance("SHA-256");
9. src/peergos/server/sync/PeergosSyncFS.java:294 MessageDigest chunkHash = MessageDigest.getInstance("SHA-256");
10. src/peergos/server/sync/PeergosSyncFS.java:303 chunkHash = MessageDigest.getInstance("SHA-256");
11. src/peergos/server/tests/NitrokeyWebauthn.java:150 test path return MessageDigest.getInstance("SHA-256").digest(in);
12. src/peergos/server/tests/TransactionsStoreTests.java:44 test path MessageDigest md = MessageDigest.getInstance("SHA-256");
13. src/peergos/server/tests/VersionedWriteOnlyStorage.java:250 test path MessageDigest md = MessageDigest.getInstance("SHA-256");
14. src/peergos/server/tests/WriteOnlyStorage.java:221 test path MessageDigest md = MessageDigest.getInstance("SHA-256");
15. src/peergos/server/webauthn/LinuxSecurityKey.java:49 return MessageDigest.getInstance("SHA-256").digest(data);
16. src/peergos/server/webdav/caldav/AppDataStore.java:480 MessageDigest digest = MessageDigest.getInstance("SHA-256");
17. src/peergos/shared/crypto/hash/Hash.java:15 MessageDigest md = MessageDigest.getInstance(HASH);
18. src/peergos/shared/crypto/hash/Hash.java:29 MessageDigest md = MessageDigest.getInstance(HASH);

java.messagedigest · CWE-328

AES Reduced margin 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 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/peergos/server/tests/fips203/FIPS203Tests.java:144 test path Cipher cipher = Cipher.getInstance(CIPHER_ALGORITHM);
2. src/peergos/server/tests/fips203/FIPS203Tests.java:165 test path Cipher decipher = Cipher.getInstance(CIPHER_ALGORITHM);

java.cipher · CWE-327

AES Reduced margin 1 place 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/peergos/server/tests/fips203/FIPS203Tests.java:25 test path private static final String CIPHER_ALGORITHM = "AES/GCM/NoPadding";

java.transformation · CWE-327

AES 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/peergos/server/tests/fips203/FIPS203Tests.java:137 test path SecretKey secretKey = new SecretKeySpec(sharedSecretKey, "AES");

java.keyspec · CWE-327

SHA3-256 Reduced margin 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.

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 that must remain verifiable for decades.

1. src/peergos/server/crypto/asymmetric/mlkem/fips203/hash/MLKEMHash.java:42 sha3Hash256 = MessageDigest.getInstance("SHA3-256");

java.messagedigest · CWE-328

unknown Could not be determined 10 places See details

Non-cryptographic randomness near key material

`new Random()` or `Math.random()` in a file that also imports `java.security`, `javax.crypto` or BouncyCastle. `java.util.Random` is a linear congruential generator and its output is predictable from a handful of samples. The import check is what keeps this from firing on every retry jitter and test fixture in the tree.

Part of this code uses a predictable source of random numbers. If any key comes from it, that key can be guessed today, with no quantum computer needed.

What to do. `java.security.SecureRandom`. This is a classical defect, not a quantum one, and it is worth fixing first.

1. src/peergos/server/tests/BackupCodesTest.java:42 test path new Random(42).nextBytes(credentialId);
2. src/peergos/server/tests/RamUserTests.java:456 test path new Random(7).nextBytes(content);
3. src/peergos/server/tests/RamUserTests.java:850 test path Random random = new Random(666);
4. src/peergos/server/tests/RamUserTests.java:897 test path Random random = new Random(666);
5. src/peergos/server/tests/RamUserTests.java:937 test path new Random(42).nextBytes(fileData);
6. src/peergos/server/tests/RamUserTests.java:972 test path Random random = new Random(666);
7. src/peergos/server/tests/RamUserTests.java:1012 test path Random random = new Random(666);
8. src/peergos/server/tests/RamUserTests.java:1334 test path new Random(42).nextBytes(big);
9. src/peergos/server/tests/RamUserTests.java:1436 test path new Random(7).nextBytes(noisy);
10. src/peergos/server/tests/RamUserTests.java:1462 test path new Random(42).nextBytes(secretData);

java.random.insecure · CWE-338

NULL Could not be determined 1 place See details

TLS cipher suite named in source

A cipher suite written into the code rather than into a configuration file - `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`, or the OpenSSL spelling `ECDHE-RSA-AES128-GCM-SHA256`. The key exchange is reported, and the bulk cipher separately when it is one of the broken ones.

This code names the exact cryptography its TLS connections may use. Because the list is in the program rather than in a settings file, changing it needs a new release - which is the thing that makes a migration slow.

What to do. A hardcoded suite list ships with the binary and cannot be changed without a release, so move it to configuration first. The key exchange changes when the TLS library offers a hybrid group, not before.

1. src/peergos/server/UserService.java:48 "TLS_RSA_WITH_NULL_SHA256," +

config.cipher-suite · CWE-757

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/peergos/server/UserService.java:371 KeyStore ks = KeyStore.getInstance("PKCS12");

java.keystore

ML-KEM-768 Quantum-safe 26 places See details

Post-quantum algorithm through BouncyCastle

A `org.bouncycastle.pqc` class. This is migration work already in progress and is recorded so the inventory shows what has been done, not only what is outstanding.

This is already a quantum-safe algorithm. It is listed so the report shows the work that has been completed.

What to do. None. Confirm the parameter set matches the required NIST category.

1. src/peergos/server/crypto/asymmetric/mlkem/JavaMlkem.java:10 import peergos.server.crypto.asymmetric.mlkem.fips203.key.mlkem.MLKEMDecapsulationKey;
2. src/peergos/server/crypto/asymmetric/mlkem/fips203/MimicloneFIPS203.java:5 import peergos.server.crypto.asymmetric.mlkem.fips203.decaps.mlkem.MLKEMDecapsulator;
3. src/peergos/server/crypto/asymmetric/mlkem/fips203/codec/MLKEMCodec.java:11 public class MLKEMCodec implements Codec {
4. src/peergos/server/crypto/asymmetric/mlkem/fips203/decaps/mlkem/MLKEMDecapsulator.java:10 import peergos.server.crypto.asymmetric.mlkem.fips203.hash.MLKEMHash;
5. src/peergos/server/crypto/asymmetric/mlkem/fips203/decaps/provider/MLKEMDecapsulatorProvider.java:5 import peergos.server.crypto.asymmetric.mlkem.fips203.decaps.mlkem.MLKEMDecapsulator;
6. src/peergos/server/crypto/asymmetric/mlkem/fips203/decrypt/kpke/KPKEDecryptor.java:5 import peergos.server.crypto.asymmetric.mlkem.fips203.codec.MLKEMCodec;
7. src/peergos/server/crypto/asymmetric/mlkem/fips203/encaps/mlkem/MLKEMEncapsulation.java:5 import peergos.server.crypto.asymmetric.mlkem.fips203.key.mlkem.MLKEMSharedSecretKey;
8. src/peergos/server/crypto/asymmetric/mlkem/fips203/encaps/mlkem/MLKEMEncapsulator.java:9 import peergos.server.crypto.asymmetric.mlkem.fips203.hash.MLKEMHash;
9. src/peergos/server/crypto/asymmetric/mlkem/fips203/encaps/provider/MLKEMEncapsulationProvider.java:6 public class MLKEMEncapsulationProvider implements KEMSpi.EncapsulatorSpi {
10. src/peergos/server/crypto/asymmetric/mlkem/fips203/encrypt/kpke/KPKEEncryptor.java:5 import peergos.server.crypto.asymmetric.mlkem.fips203.codec.MLKEMCodec;
11. src/peergos/server/crypto/asymmetric/mlkem/fips203/hash/MLKEMHash.java:13 public class MLKEMHash implements Hash {
12. src/peergos/server/crypto/asymmetric/mlkem/fips203/key/gen/mlkem/MLKEMKeyPairGenerator.java:5 import peergos.server.crypto.asymmetric.mlkem.fips203.codec.MLKEMCodec;
13. src/peergos/server/crypto/asymmetric/mlkem/fips203/key/gen/provider/MLKEMKeyGenerationProvider.java:9 public class MLKEMKeyGenerationProvider extends KeyPairGeneratorSpi {
14. src/peergos/server/crypto/asymmetric/mlkem/fips203/key/mlkem/MLKEMDecapsulationKey.java:7 public class MLKEMDecapsulationKey implements DecapsulationKey {
15. src/peergos/server/crypto/asymmetric/mlkem/fips203/key/mlkem/MLKEMEncapsulationKey.java:7 public class MLKEMEncapsulationKey implements EncapsulationKey {
16. src/peergos/server/crypto/asymmetric/mlkem/fips203/key/mlkem/MLKEMKeyPair.java:9 public class MLKEMKeyPair implements KeyPair {
17. src/peergos/server/crypto/asymmetric/mlkem/fips203/key/mlkem/MLKEMSharedSecretKey.java:7 public class MLKEMSharedSecretKey implements SharedSecretKey {
18. src/peergos/server/crypto/asymmetric/mlkem/fips203/message/MLKEMCipherText.java:3 public class MLKEMCipherText implements CipherText {
19. src/peergos/server/crypto/asymmetric/mlkem/fips203/provider/MLKEMProvider.java:4 import peergos.server.crypto.asymmetric.mlkem.fips203.decaps.provider.MLKEMDecapsulatorProvider;
20. src/peergos/server/crypto/asymmetric/mlkem/fips203/provider/MimicloneSecurityProvider.java:5 import peergos.server.crypto.asymmetric.mlkem.fips203.key.gen.provider.MLKEMKeyGenerationProvider;
21. src/peergos/server/crypto/asymmetric/mlkem/fips203/sample/MLKEMSampler.java:14 test path public class MLKEMSampler implements Sampler {
22. src/peergos/server/crypto/asymmetric/mlkem/fips203/transform/MLKEMTransformer.java:11 public class MLKEMTransformer implements Transformer {
23. src/peergos/server/tests/MLKEMTests.java:13 test path import peergos.server.crypto.asymmetric.mlkem.fips203.message.MLKEMCipherText;
24. src/peergos/server/tests/fips203/decaps/mlkem/MLKEMDecapsulatorTests.java:8 test path import peergos.server.crypto.asymmetric.mlkem.fips203.decaps.mlkem.MLKEMDecapsulator;
25. src/peergos/server/tests/fips203/encaps/mlkem/MLKEMEncapsulatorTests.java:8 test path import peergos.server.crypto.asymmetric.mlkem.fips203.encaps.mlkem.MLKEMEncapsulator;
26. src/peergos/server/tests/fips203/key/gen/mlkem/MLKEMKeyGeneratorTests.java:11 test path import peergos.server.crypto.asymmetric.mlkem.fips203.key.gen.mlkem.MLKEMKeyPairGenerator;

java.bouncycastle.pqc

CSPRNG Quantum-safe 13 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/peergos/server/crypto/TweetNaCl.java:1261 return new SecureRandom();
2. src/peergos/server/crypto/asymmetric/mlkem/MlkemSecureRandom.java:32 return new SecureRandom();
3. src/peergos/server/crypto/hash/lambdaworks/crypto/SCryptUtil.java:45 SecureRandom.getInstance("SHA1PRNG").nextBytes(salt);
4. src/peergos/server/login/JdbcAccount.java:75 private final SecureRandom rnd = new SecureRandom();
5. src/peergos/server/net/MountConfigHandler.java:373 new SecureRandom().nextBytes(bytes);
6. src/peergos/server/storage/FileBlockCache.java:32 private final SecureRandom rnd = new SecureRandom();
7. src/peergos/server/storage/FileContentAddressedStorage.java:47 private final SecureRandom rnd = new SecureRandom();
8. src/peergos/server/tests/BackupCodesTest.java:15 test path SecureRandom rnd = new SecureRandom();
9. src/peergos/server/tests/NitrokeyWebauthn.java:71 test path new SecureRandom().nextBytes(credentialId);
10. src/peergos/server/tests/StandaloneWebauthnDemo.java:27 test path SecureRandom rnd = new SecureRandom();
11. src/peergos/server/tests/fips203/FIPS203Tests.java:141 test path SecureRandom.getInstance(SECURE_RANDOM_ALGORITHM).nextBytes(iv);
12. src/peergos/server/util/Passwords.java:10 SecureRandom rnd = new SecureRandom();
13. src/peergos/server/webauthn/CtapHid.java:93 new SecureRandom().nextBytes(nonce);

java.rng

scrypt Quantum-safe 5 places See details

Password hashing or key derivation

A `SecretKeyFactory` for PBKDF2, or a BouncyCastle password KDF. Not a quantum exposure, and part of a complete inventory.

This is how passwords are stored. Quantum computers do not meaningfully weaken it.

What to do. PBKDF2 needs a high iteration count. Argon2 through BouncyCastle is stronger.

1. src/peergos/server/crypto/hash/ScryptJava.java:18 import peergos.server.crypto.hash.lambdaworks.crypto.SCrypt;
2. src/peergos/server/crypto/hash/ScryptJava.java:46 byte[] scryptHash = SCrypt.scrypt(hash, salt, memoryCost, cpuCost, parallelism, nOutputBytes);
3. src/peergos/server/crypto/hash/lambdaworks/crypto/SCrypt.java:23 public class SCrypt {
4. src/peergos/server/crypto/hash/lambdaworks/crypto/SCryptUtil.java:47 byte[] derived = SCrypt.scrypt(passwd.getBytes("UTF-8"), salt, N, r, p, 32);
5. src/peergos/server/crypto/hash/lambdaworks/crypto/SCryptUtil.java:88 byte[] derived1 = SCrypt.scrypt(passwd.getBytes("UTF-8"), salt, N, r, p, 32);

java.kdf

HMAC Quantum-safe From a constant 3 places See details

Message authentication code through the JCA

`Mac.getInstance()`. HMAC is not broken by Shor and is only marginally affected by Grover; it is inventoried, not flagged, unless the underlying digest is broken.

This is a fingerprint used to prove a message was not altered. Quantum computers do not break it.

What to do. No action beyond avoiding HmacMD5 and HmacSHA1.

1. src/peergos/server/crypto/hash/ScryptJava.java:91 Mac mac = Mac.getInstance(algorithm);
2. src/peergos/server/crypto/hash/lambdaworks/crypto/SCrypt.java:86 Mac mac = Mac.getInstance("HmacSHA256");
3. src/peergos/server/storage/LocalS3Handler.java:421 Mac mac = Mac.getInstance("HmacSHA256");

java.mac

HMAC Quantum-safe From a constant 3 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/peergos/server/crypto/hash/ScryptJava.java:92 SecretKey secretKey = new SecretKeySpec(secretKeyBytes, algorithm);
2. src/peergos/server/crypto/hash/lambdaworks/crypto/SCrypt.java:87 mac.init(new SecretKeySpec(passwd, "HmacSHA256"));
3. src/peergos/server/storage/LocalS3Handler.java:422 mac.init(new SecretKeySpec(key, "HmacSHA256"));

java.keyspec · CWE-327

SHA3-512 Quantum-safe 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.

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

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

1. src/peergos/server/crypto/asymmetric/mlkem/fips203/hash/MLKEMHash.java:49 sha3Hash512 = MessageDigest.getInstance("SHA3-512");

java.messagedigest · CWE-328