Data point: what a PQ signature and host-key migration would touch in sshd, from a static scan of 2.19.0

Not a bug report: a data point and a question, because MINA SSHD is one of the few Java projects that has actually shipped post-quantum key exchange, which makes it the best place to check a prediction.

I maintain a static auditor that estimates what a post-quantum migration would touch in a Java codebase and how expensive each site is (https://github.com/Arpan0995/pqc-migration-readiness, Apache-2.0). sshd 2.13.1 is one of the four pinned public codebases I use as case studies; I re-ran the current release for this post.

What the scan says for sshd-2.19.0 (1,413 files, 337 findings, 6 modules):

| # | Step | Sites | Where | Effort |
|---:|---|---:|---|---|
| 1 | Set up a PQC provider and an agility seam | n/a | n/a | ~3–5 days |
| 2 | Decouple concrete key types from APIs | 243 | `sshd-common`, `sshd-core`, `sshd-openpgp`, `sshd-putty`, `sshd-contrib` | ~13–26 weeks |
| 3 | Test and roll out | n/a | n/a | ~6–26 weeks |

That is a planning heuristic of 5 to 12 months for one engineer, and it is almost entirely one thing: 243 places where code is written against `RSAPublicKey`, `DSAPublicKey`, `ECPublicKey` and their private-key counterparts instead of `PublicKey` and `PrivateKey`. Most are in `sshd-common`: `config/keys` (the key utilities and the OpenSSH and PEM loaders), `util/buffer` (key encoding into the wire buffers) and `signature`. The rest sit in the PuTTY and OpenPGP key-format modules.

The scan finds no key-establishment work at all, and that is a known blind spot rather than a result: the KEX classes obtain their `KeyAgreement` and `KeyPairGenerator` instances through `SecurityUtils`, so the algorithm name never appears at the JCA call site the scanner looks at.

Two things about the key-exchange half you have already done, measured from the git history, since they are the closest thing I have to real migration-effort data:

- `sntrup761x25519-sha512@openssh.com` in 2.13.0: 16 files, +466/-42, plus a follow-up fix in 2.13.2 (GH-525).
- ML-KEM key exchange on Bouncy Castle (GH-606) in 2.15.0: 17 files, +531/-49.
- JDK built-in ML-KEM on Java 24+ (GH-803) in 3.0.0-M2: 28 files, +614/-136, and `mlkem768x25519-sha256` became the preferred KEX.

So the confidentiality half cost on the order of 15 to 30 files per step, all inside the `kex` package of `sshd-core`. The scan's claim is that the authentication half, PQ host keys and user keys with ML-DSA-style signatures once SSH has standard algorithm names for them, is a different kind of job. Instead of one new KEX class, it propagates through every reader, writer, buffer codec and signature factory that assumes an RSA, DSA or EC key type.

The question for people who know the code: does that match your expectation? If PQ host-key algorithms arrive, would you expect the work to concentrate in the key-format and signature layers of `sshd-common` the way the scan says, or is there an abstraction in place that would keep it closer to the 20-file size of the KEX additions? Either answer is useful, and "the scan is counting X, which is not really a problem" is the most useful of all.

The full 2.13.1 reports are in the repository under `case-studies/mina-sshd`. I can post the 2.19.0 report here if that helps.

Start by reading the `sshd-common` `config/keys`, `util/buffer`, and `signature` areas, then compare them with the `sshd-core` `kex` package and `SecurityUtils`. The issue provides scan reports and historical changes, but no implementation target or completion criterion; a useful outcome would be a maintainer assessment of whether the reported migration scope matches the existing abstractions.

Written by the indexing model from the issue text.