Repository navigation
Show classical strength for every detected algorithm, from one cited model (ENH-001) #17
Description
Problem
Detected algorithms are shown without their classical strength, except on the TLS report and its PDF. There, each
suite gets one of four words (Strong, Acceptable, Weak, Insecure) from a heuristic that is uncited, untested, and
kept in two copies: web/static/js/views/report.js and internal/reportpdf/matrix.go.
| Surface | Today |
|---|---|
tls scan --details, --json |
every suite, no strength |
| Inventory → Algorithms, Keys | only a post-quantum column: 3DES, RC4, DES, MD5 and SHA-1 read "? not classified" |
| SSH report | ciphers, MACs, key exchange and host keys judged only against the baseline |
| Key-exchange groups, certificate keys | no bits (ffdhe2048, RSA-2048: 112; secp256r1, X25519: 128) |
| API, CSV | raw registry fields only |
| CBOM | classicalSecurityLevel never set |
Proposal
- One cited model in Go:
SecurityBitsper catalogue entry, from NIST SP 800-57 Part 1 Rev. 5 Table 2 (and Table 3 for hashes);- a cited "broken" status where no number applies (DES, RC4, MD5, SHA-1 collisions, export).
- Suite strength is its weakest part: cipher, key exchange, certificate key, MAC/hash. It maps to the four words
by a cited table (RFC 9325 §4.1 and §4.2), and each suite carries its reason. - The same value on every surface:
- report and PDF (the JS and Go copies are deleted);
- CLI;
- SSH report;
- groups and keys;
- an Inventory "Classical strength" column;
- API and CSV;
- CBOM
classicalSecurityLevel.
Acceptance
AC-1 to AC-6 in the spec. Among them:
- every catalogue entry has a cited strength;
- DES-56 is Insecure;
- the page, the PDF and the CLI agree;
- no legacy algorithm reads "not classified".
Owner decision
OD-1: should an RSA-2048 certificate make its suites Acceptable (weakest part, 112 bits) rather than Strong?
Activity