| Yes , Hybrid is weaker because it contributes little/nothing[1] to cryptographic security and increases attack surface by adding another code base.
[1] The only case when Hybrid helps is when both CRQC is not a threat **and** PQ algorithms falls to a classic attack (like SIKE). Thus, deploying hybrid because you want to protect your date against “harvest now, decrypt later” Quantum attack is a non-starter. And that attack is the main reason people are hustling now, rather than wait for several more years. — Regards, Uri
Secure Resilient Systems and Technologies MIT Lincoln Laboratory
If you are fine with ML-KEM, you should be able to use it on its own. That's it. On Fri, Oct 10, 2025, 4: 17 PM Rob Sayre <sayrer@ gmail. com> wrote: Hi, Alright, but that's the issue. I hope we can stick to that point. "migrating
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside the Laboratory.
ZjQcmQRYFpfptBannerEnd
If you are fine with ML-KEM, you should be able to use it on its own. That's it. Hi,
Alright, but that's the issue. I hope we can stick to that point.
"migrating beyond hybrids and for users that need to be fully post-quantum."
Where does the need to be solely PQ arise? Is it weaker in some way to use a hybrid?
thanks, Rob
Hi,
That does not answer my question: why?
The hybrid draft has a rationale:
thanks, Rob The drafts and the profile currently do not make Recommendations or MTI's, they make the options available; ekr has now raised promoting one hybrid option as Recommended = Y. Not everyone can or should use the same options, we have a diversity of curves for example
Hi,
But why is that? See this thread from the IETF general list:
As pointed out in that thread, all of these drafts seem to conflict with the rationale in draft-ietf-tls-hybrid-design.
thanks, Rob
|
smime.p7s