Peergos/Peergos

MD5 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. 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/webdav/modeshape/webdav/WebDavServletBean.java:58 MD5_HELPER = MessageDigest.getInstance("MD5");

java.messagedigest · CWE-328

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:253

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:170 SSLContext sslContext = SSLContext.getInstance("TLS");

java.sslcontext · CWE-757

SHA-256 Reduced margin 6 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/crypto/hash/ScryptJava.java:111 MessageDigest chunkHash = MessageDigest.getInstance("SHA-256");
2. src/peergos/server/crypto/hash/ScryptJava.java:119 chunkHash = MessageDigest.getInstance("SHA-256");
3. src/peergos/server/storage/RAMStorage.java:226 MessageDigest md = MessageDigest.getInstance("SHA-256");
4. src/peergos/server/sync/PeergosSyncFS.java:215 MessageDigest chunkHash = MessageDigest.getInstance("SHA-256");
5. src/peergos/server/sync/PeergosSyncFS.java:224 chunkHash = MessageDigest.getInstance("SHA-256");
6. src/peergos/server/tests/TransactionsStoreTests.java:36 test path MessageDigest md = MessageDigest.getInstance("SHA-256");

java.messagedigest · CWE-328

unknown Could not be determined 4 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/RamUserTests.java:348 test path Random random = new Random(666);
2. src/peergos/server/tests/RamUserTests.java:395 test path Random random = new Random(666);
3. src/peergos/server/tests/RamUserTests.java:434 test path Random random = new Random(666);
4. src/peergos/server/tests/RamUserTests.java:474 test path Random random = new Random(666);

java.random.insecure · CWE-338

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:317 KeyStore ks = KeyStore.getInstance("PKCS12");

java.keystore

CSPRNG Quantum-safe 6 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/hash/lambdaworks/crypto/SCryptUtil.java:45 SecureRandom.getInstance("SHA1PRNG").nextBytes(salt);
3. src/peergos/server/login/JdbcAccount.java:48 private final SecureRandom rnd = new SecureRandom();
4. src/peergos/server/storage/FileBlockCache.java:30 private final SecureRandom rnd = new SecureRandom();
5. src/peergos/server/tests/StandaloneWebauthnDemo.java:27 test path SecureRandom rnd = new SecureRandom();
6. src/peergos/server/util/Passwords.java:10 SecureRandom rnd = new SecureRandom();

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:14 import peergos.server.crypto.hash.lambdaworks.crypto.SCrypt;
2. src/peergos/server/crypto/hash/ScryptJava.java:39 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 1 place 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/lambdaworks/crypto/SCrypt.java:86 Mac mac = Mac.getInstance("HmacSHA256");

java.mac