Comment by tomgag
1 day ago
Yes, totally agreed, but the problem is that most people tend to simplify this as "let's just bother with PQ encryption, forget about signatures". I know experts can handle the nuance, but execs and most industry folks can't. Or, at least, this is the trend that I have personally observed countless times, maybe I was just unlucky with my data points, but I have seen this in "technical" settings as well (case in point: GnuPG prioritized inclusion of PQ hybrid encryption, to the point of rushing the standard against OpenPGP, the well-known "GnuPG schism", but I'm not aware of concrete plans for PQ signature adoptions there).
I agree. If we're going the rally the industry to do the work, it should be the whole work in one shot. Any given project/infrastructure that implements both encryption and signing should adopt ML-DSA/SLH-DSA at the same time as ML-KEM, or at least in immediate succession.
My concern is that PQC is having a bit of a Y2K moment, and undercapitalizing on that sense of urgency may risk letting PQ signatures drag on for ages like IPv6. "We need $X engineering budget for PQC" is easy to understand, but "we need $X for PQ encryption now and $Y for PQ signing at some undefined future time" is murkier and may require getting into the weeds on cryptographic concepts and speculative CRQC timelines with non-expert stakeholders.
> signing should adopt ML-DSA/SLH-DSA at the same time as ML-KEM
I know you mean well, but this proposal maximizes the downsides of PQ signatures.
Both ML-DSA and SLH-DSA have enormous keys. SLH-DSA is also very slow, while ML-DSA is relatively fast: https://blog.cloudflare.com/another-look-at-pq-signatures/
One of the biggest challenges with the signatures currently standardized is the signature + public key sizes. Demanding we hybridize both just maximizes the pain, and there's no real incentive for this.
As I wrote in https://soatok.blog/2026/04/13/hybrid-constructions-the-post..., the justification for composite/hybrid signatures just isn't there.
Use ML-DSA-44. Don't combine it with other crap. It's good enough.
For KEMs, X-Wing (mlkem768x25519) is great, but ML-KEM-768 and ML-KEM-1024 are also fine on their own. Hybrids are the path of least resistance here, so I prefer them, but have no concerns over ML-KEM's security.
I wasn't implying that the two should be hybridized. I think both are great options to have in our toolkit. For example, in Cyph I chose ML-DSA for end user signing keys + certificates and SLH-DSA for code signing.
2 replies →