Crypto-View

apache/httpcomponents-client

Cryptographic posture

192 cryptographic locations: 39 already broken, 60 quantum-vulnerable, 24 reduced-margin, 58 undetermined, 11 quantum-safe

6 establish keys, so traffic protected by them and recorded today becomes readable once the algorithm falls. 1216 files analysed.

Quantum-vulnerable 60 Already broken 39 Reduced margin 24 Could not be determined 58 Quantum-safe 11
To address73
Key establishment6
Inventory only0
Total findings192
What was analysed
Branch master
Commit be07c77297576b08bc01bb93789eca6f5f9bf850 Use Brotli4jLoader.isAvailable() instead of relying on class presence.
Committed 2026-08-22 06:45 UTC
Scanned 2026-09-11 06:53 UTC 1 hour ago
Coverage 1216 files, 1170 java

Earlier scans of this repository

13 scans · compare any two
0 to 100 locations Already broken 31 → 39 (up 8) Quantum-vulnerable 44 → 60 (up 16) Reduced margin 12 → 24 (up 12) Could not be determined 48 → 58 (up 10) Quantum-safe 4 → 11 (up 7) The filled point is the scan you are reading.
Scanned Commit To address Key establishment
1 hour ago this scan be07c7729757 master 73 6
10 hours ago be07c7729757 master 73 5 Compare
10 hours ago be07c7729757 master 67 2 Compare
1 day ago ffe4a05f4faf 58 2 Compare
1 day ago be07c7729757 master 67 2 Compare
1 day ago be07c7729757 master 67 2 Compare
1 day ago be07c7729757 master 67 2 Compare
1 day ago be07c7729757 master 67 2 Compare
1 day ago be07c7729757 master 61 2 Compare
3 days ago be07c7729757 master 61 4 Compare
3 days ago be07c7729757 master 61 57 Compare
11 days ago be07c7729757 master 61 57 Compare
11 days ago ffe4a05f4faf 54 44 Compare

Every repository in this history is re-scanned weekly.

List of cryptographic assets

MD5 Already broken 10 places See details

HTTP Digest authentication

An HTTP Digest authentication implementation. RFC 7616 Digest is built on MD5 in its widely deployed form. This is not a quantum question: it is weak today and depends entirely on the TLS underneath it. HTTP Basic is deliberately not matched - it is base64 and contains no cryptography to inventory.

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. Move to a token-based scheme. Where Digest must remain, use the SHA-256 variant.

  1. httpclient5/src/main/java/org/apache/hc/client5/http/impl/async/H2AsyncClientBuilder.java:948 .register(StandardAuthScheme.DIGEST, DigestSchemeFactory.INSTANCE)
  2. httpclient5/src/main/java/org/apache/hc/client5/http/impl/async/HttpAsyncClientBuilder.java:1239 .register(StandardAuthScheme.DIGEST, DigestSchemeFactory.INSTANCE)
  3. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/DigestScheme.java:90 public class DigestScheme implements AuthScheme, Serializable {
  4. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/DigestSchemeFactory.java:46 public class DigestSchemeFactory implements AuthSchemeFactory {
  5. httpclient5/src/main/java/org/apache/hc/client5/http/impl/classic/HttpClientBuilder.java:1077 .register(StandardAuthScheme.DIGEST, DigestSchemeFactory.INSTANCE)
  6. httpclient5/src/main/java/org/apache/hc/client5/http/impl/classic/ProxyClient.java:117 .register(StandardAuthScheme.DIGEST, DigestSchemeFactory.INSTANCE)
  7. httpclient5/src/test/java/org/apache/hc/client5/http/examples/ClientPreemptiveDigestAuthentication.java:74 test path if (authScheme instanceof DigestScheme) {
  8. httpclient5/src/test/java/org/apache/hc/client5/http/impl/TestAuthenticationStrategy.java:103 test path .register(StandardAuthScheme.DIGEST, DigestSchemeFactory.INSTANCE).build();
  9. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestAuthenticationHandler.java:98 test path .register(StandardAuthScheme.DIGEST, DigestSchemeFactory.INSTANCE)
  10. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestDigestScheme.java:84 test path final AuthScheme authscheme = new DigestScheme();
java.httpauth · CWE-328
NTLM Already broken 9 places See details

NTLM authentication

An NTLM implementation. NTLM derives its credentials from MD4 and is broken by relay and offline cracking today; Microsoft has been deprecating it since 2024.

This is already unsafe today, with no quantum computer involved. NTLM authenticates with MD4-derived hashes and is broken by relay and cracking attacks today. Quantum computing is beside the point.

What to do. Kerberos, or a modern token-based scheme. This is a present-day defect, not a future one.

  1. httpclient5-fluent/src/main/java/org/apache/hc/client5/http/fluent/Executor.java:255 return auth(host, new org.apache.hc.client5.http.auth.NTCredentials(username, password, workstation, domain));
  2. httpclient5/src/main/java/org/apache/hc/client5/http/auth/NTCredentials.java:55 public class NTCredentials implements Credentials, Serializable {
  3. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngine.java:39 public interface NTLMEngine {
  4. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:55 final class NTLMEngineImpl implements NTLMEngine {
  5. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMScheme.java:60 public final class NTLMScheme implements AuthScheme {
  6. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMSchemeFactory.java:59 return new NTLMScheme();
  7. httpclient5/src/test/java/org/apache/hc/client5/http/auth/TestCredentials.java:61 test path final NTCredentials creds1 = new NTCredentials(
  8. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestNTLMEngineImpl.java:80 test path final NTLMEngineImpl.MD4 md4;
  9. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestNTLMScheme.java:46 test path final AuthScheme authScheme = new NTLMScheme();
java.ntlm · CWE-327
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.

java.cipher · CWE-327
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. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:1828 return MessageDigest.getInstance("MD5");
  2. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestDigestScheme.java:587 test path final HttpEntityDigester digester = new HttpEntityDigester(MessageDigest.getInstance("MD5"));
  3. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestDigestScheme.java:768 test path final MessageDigest md = MessageDigest.getInstance("MD5");
  4. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestDigestScheme.java:812 test path final MessageDigest md = MessageDigest.getInstance("MD5");
java.messagedigest · CWE-328
RC4 Already broken 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. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:605 rc4.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(key, "RC4"));
  2. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:847 cipher.init( Cipher.ENCRYPT_MODE, new SecretKeySpec( sealingKey, "RC4" ) );
  3. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/NTLMEngineImpl.java:851 cipher.init( Cipher.DECRYPT_MODE, new SecretKeySpec( sealingKey, "RC4" ) );
java.keyspec · CWE-327
RC4 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. RC4 keystream biases break it classically; it is prohibited in TLS by RFC 7465.

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.

java.cipher · CWE-327
SHA-1 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. 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.

java.messagedigest · CWE-328
3DES Already broken 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.

config.cipher-suite · CWE-757
DES Already broken 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.

java.keyspec · CWE-327
NULL Already broken 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.

config.cipher-suite · CWE-757
RC4 Already broken 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.

config.cipher-suite · CWE-757
RSAES-PKCS1v15 Already broken Recorded traffic 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.

config.cipher-suite · CWE-757
ECDH 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.

config.cipher-suite · CWE-757
RSA2048-bit Quantum-vulnerable 2 places 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. httpclient5-testing/src/test/resources/docker/server-cert.pem:62 test path -----BEGIN CERTIFICATE-----
  2. test-CA/ca-cert.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.

pem.private-key · CWE-321, CWE-327
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. httpclient5-testing/src/test/resources/docker/httpd/httpd-ssl.conf:70 test path SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4:!3DES
config.tls-ciphers · CWE-757
TLS Quantum-vulnerable Recorded traffic 1 place See details

TLS versions pinned in configuration

An `ssl_protocols` or `SSLProtocol` directive. SSLv3, TLS 1.0 and TLS 1.1 are withdrawn.

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. TLS 1.2 as the floor, TLS 1.3 preferred.

config.tls-protocols · CWE-757
SHA-256 Reduced margin 9 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.

java.messagedigest · CWE-328
Kerberos Reduced margin 5 places See details

Kerberos or SPNEGO authentication

`javax.security.auth.kerberos` or a GSS-API call. Kerberos itself is symmetric and survives Shor; its PKINIT certificate flow is public-key and does not. The encryption types configured for the realm decide whether it is also a present-day concern.

A quantum computer weakens this but does not break it. Increasing the key or digest size restores the margin. Kerberos is symmetric at its core, so Shor does not break it. The surrounding PKINIT certificate flow is public-key and does fall.

What to do. Restrict the realm to AES encryption types, and treat PKINIT certificates as part of the public-key migration.

java.kerberos
PBKDF2 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. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/ScramScheme.java:716 final PBEKeySpec spec = new PBEKeySpec(password, salt, iterations, dkLen * 8);
  2. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestScramScheme.java:125 test path final PBEKeySpec spec = new PBEKeySpec(password, salt, iter, dkLen * 8);
java.keyspec · CWE-327
SHA-256 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. 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. For RSA encryption, move to ML-KEM-768 and keep RSA-OAEP only as the classical half of a hybrid during transition.

  1. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/ScramScheme.java:717 return SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256").generateSecret(spec).getEncoded();
  2. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestScramScheme.java:126 test path return SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256").generateSecret(spec).getEncoded();
java.cipher · CWE-327
PBKDF2 Reduced margin 2 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. httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/ScramScheme.java:717 return SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256").generateSecret(spec).getEncoded();
  2. httpclient5/src/test/java/org/apache/hc/client5/http/impl/auth/TestScramScheme.java:126 test path return SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256").generateSecret(spec).getEncoded();
java.kdf
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.

java.random.insecure · CWE-338
unknown Could not be determined 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. test-CA/ca-key.pem:1 test path -----BEGIN ENCRYPTED PRIVATE KEY-----
pem.private-key · CWE-321, 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.

java.rng
HMAC Quantum-safe 2 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.

java.mac
HMAC Quantum-safe 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.

java.keyspec · CWE-327

Cryptographic assets

Algorithm Assessment What it means Occurrences
unknown Could not be determined The algorithm could not be established from the source - chosen at runtime, or decided somewhere this scan does not reach. 58
TLS Quantum-vulnerable Every TLS cipher suite in general use negotiates a classical key exchange, so a recorded session is decryptable once that exchange falls. 55
MD5 Already broken Practical chosen-prefix collisions exist; MD5 has no remaining security as a digest. 14
SHA-256 Reduced 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. 11
NTLM Already broken NTLM authenticates with MD4-derived hashes and is broken by relay and cracking attacks today. Quantum computing is beside the point. 9
Kerberos Reduced margin Kerberos is symmetric at its core, so Shor does not break it. The surrounding PKINIT certificate flow is public-key and does fall. 9
CSPRNG Quantum-safe A cryptographically secure random number generator provided by the platform. Not weakened by a quantum computer. 7
RC4 Already broken RC4 keystream biases break it classically; it is prohibited in TLS by RFC 7465. 6
DES Already broken A 56-bit key is brute-forced classically in hours. 5
HMAC Quantum-safe A keyed MAC is not affected by Shor and only marginally by Grover. 4
PBKDF2 Reduced margin Not broken by a quantum computer, but weak against modern GPU cracking at low iteration counts, which is a present-day concern. 4
RSA Quantum-vulnerable Broken by Shor's algorithm on a cryptographically relevant quantum computer. 3
ECDH Quantum-vulnerable Broken by Shor's algorithm on a cryptographically relevant quantum computer. 2
SHA-1 Already broken SHAttered and subsequent work produced practical collisions; NIST withdrew SHA-1 in 2030 guidance and it is already unacceptable for signatures. 2
3DES Already broken Triple DES is withdrawn by NIST and limited by its 64-bit block, independent of quantum. 1
NULL Already broken A NULL cipher provides no confidentiality at all: the session is authenticated and then sent in the clear. No quantum computer is needed to read it. 1
RSAES-PKCS1v15 Already broken PKCS#1 v1.5 encryption padding is vulnerable to Bleichenbacher oracles today, and the underlying RSA is broken by Shor. 1

Imported cryptographic libraries

Library Files
javax.net.ssl the TLS client and server 53
org.ietf.jgss GSS-API, usually Kerberos or SPNEGO 4
java.security the JCA 44