[Feature request] Add PQC-safe (Shor/Grover) reporting

[vdbaan]

Please check this repo whether this is a known feature request

I have checked the existing issues and feature requests and could not find an existing request for quantum security assessment reporting (Shor/Grover impact) in testssl.sh.

Describe your feature request (if it's a technical feature)

Add an informational "post-quantum readiness" assessment section that reports the theoretical impact of quantum algorithms on the cryptographic primitives used in a TLS connection.

The goal would not be to report a current vulnerability, but to provide visibility into how negotiated TLS parameters are expected to be affected by future cryptographically relevant quantum computers.

The report could distinguish between:

• Shor's algorithm impact

  • RSA key exchange/signatures
  • ECDSA certificates
  • ECDH/ECDHE key exchange (for example X25519, P-256)

• Grover's algorithm impact

  • Symmetric encryption algorithms (AES-128/AES-256)
  • Hash functions used in TLS (SHA-256/SHA-384)

Example output:

**Quantum readiness**
Key exchange: X25519
Shor impact: vulnerable to sufficiently powerful quantum computers

Certificate: ECDSA P-256
Shor impact: vulnerable to sufficiently powerful quantum computers

Cipher: AES-128-GCM
Grover estimate: ~64-bit security level

Hash: SHA-256
Grover preimage estimate: ~128-bit security level

If your feature request otherwise is related to a usage problem, please describe it

Organizations are beginning to inventory cryptographic dependencies for post-quantum migration. Current TLS scanning tools can identify algorithms and key sizes, but they generally do not provide an assessment of how those algorithms map to known quantum threats.

A user scanning a TLS endpoint today may not know whether the deployed configuration relies on primitives that will require migration in the future.

Describe the solution you'd like

Add a non-invasive informational report section that:

• analyses the negotiated TLS algorithms and certificate/key exchange mechanisms;
• maps cryptographic primitives to known quantum algorithm impacts;
• clearly labels results as theoretical/future risk rather than present-day exploitability;
• avoids presenting quantum estimates as traditional vulnerability findings;
• optionally allows disabling the report if users do not want quantum-related information.

The output should make clear that:

• Shor's algorithm threatens public-key cryptography (RSA/ECC);
• Grover's algorithm reduces the effective security level of symmetric cryptography;
• current publicly available quantum computers cannot practically break modern TLS deployments.

Which version of testssl.sh are you referring to?

3.3dev

[drwetter]

Hi Steven,

forward looking: good point . Anyone volunteering?

Cheers, Dirk

[dcooper16]

I like the idea of highlighting post-quantum readiness issues. However, I would not mention anything about symmetric encryption or hash algorithms. As https://words.filippo.io/128-bits/ explains, it is generally now believed that Grover's algorithm does not effectively halve the security level of symmetric algorithms, and that 128-bit symmetric key algorithms and 256-bit hash algorithms should remain secure.

I think the output should distinguish between key exchange and authentication, since the key exchange is vulnerable to harvest-now-decrypt-later, but authentication is not. So, the need to adopt PQC for key exchange is likely more urgent than for authentication. Configuring for post-quantum authentication would also likely be more difficult, since it would require issuing certificates with PQC public keys that are signed using PQC algorithms.

[drwetter]

Sounds good to me! If you can spare a bit of your time I'd appreciate it a lot--as always ;-)

…

-------- Ursprüngliche Nachricht -------- Von: David Cooper ***@***.***> Gesendet: 11. August 2026 01:47:18 MESZ An: "testssl/testssl.sh" ***@***.***> CC: Dirk Wetter ***@***.***>, Comment ***@***.***> Betreff: Re: [testssl/testssl.sh] [Feature request] Add PQC-safe (Shor/Grover) reporting (Issue #3116) dcooper16 left a comment (testssl/testssl.sh#3116) I like the idea of highlighting post-quantum readiness issues. However, I would not mention anything about symmetric encryption or hash algorithms. As https://words.filippo.io/128-bits/ explains, it is generally now believed that Grover's algorithm does not effectively halve the security level of symmetric algorithms, and that 128-bit symmetric key algorithms and 256-bit hash algorithms should remain secure. I think the output should distinguish between key exchange and authentication, since the key exchange is vulnerable to harvest-now-decrypt-later, but authentication is not. So, the need to adopt PQC for key exchange is likely more urgent than for authentication. Configuring for post-quantum authentication would also likely be more difficult, since it would require issuing certificates with PQC public keys that are signed using PQC algorithms.

-- Reply to this email directly or view it on GitHub: #3116 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[AAH20]

I can volunteer to implement this for 3.3dev.

I agree with the distinction @dcooper16 made: the first version should prioritize public-key key exchange because of harvest-now-decrypt-later exposure, report authentication separately, and avoid presenting modern symmetric encryption or hashes as needing migration merely because of Grover's algorithm.

Proposed first PR

Keep the assessment informational and separate from the existing grade calculation.

Key exchange

Report one of:

• hybrid-pqc: a standardized hybrid group such as X25519MLKEM768 is supported;
• classical-only: only RSA/(EC)DH-style public-key establishment is observed;
• legacy-pqc-draft: a pre-standard group such as X25519Kyber768Draft00 is observed without a standardized hybrid group;
• unknown: the available evidence is insufficient or a group is not recognized.

The result would state whether captured traffic using the observed key-establishment posture is potentially relevant to harvest-now-decrypt-later collection. It would not claim that a classical endpoint is presently breakable or that advertising a hybrid group proves correct deployment.

Authentication

Report certificate public-key and signature posture independently from key exchange:

• classical authentication;
• post-quantum authentication, when testssl.sh can identify it reliably;
• unknown or mixed chains.

This section would explain that authentication migration has a different urgency and operational path from protecting recorded session traffic.

Outputs

• concise terminal output with the evidence used for classification;
• stable JSON/CSV/HTML result identifiers for key exchange and authentication posture;
• no security-grade cap or vulnerability severity in the initial PR;
• explicit standardized-versus-draft algorithm naming;
• unknown values remain unknown rather than being inferred as safe.

Tests and documentation

• standardized X25519MLKEM768, legacy Kyber draft, classical-only, mixed, and unknown-group cases;
• a case where the server advertises a hybrid group but the selected client path remains classical;
• output parity tests for terminal, JSON, CSV, and HTML where supported by the existing harness;
• regression coverage for existing FS_KEMs output and client simulation;
• documentation of threat semantics, limitations, and machine-readable fields in doc/testssl.1.md.

Two compatibility questions

1. Should this be a dedicated option that is also included in the full scan, or an informational section enabled by default?
2. Would you prefer new stable IDs such as PQC_KEX and PQC_AUTH, or an extension of the existing FS_KEMs result family?

Once those are settled, I can post a short file-level plan and start with failing output/classification tests before the implementation.

Disclosure: I maintain a related open-source PQC implementation and work through A2Z SOC, which provides scoped PQC exposure and migration-readiness assessments. The proposed testssl.sh code, tests, documentation, and output would remain vendor-neutral and contain no service promotion.