Hi, Daniel, Thanks for all of these as the background info about SIKE and more.
Yes, I do agree with you on that SIKE is a special/rare case. It does not imply that a similar case will happen for standardized PQ algorithms. My feeling is, cryptographers may support more to use hybrid. 1. https://mailarchive.ietf.org/arch/msg/tls/hrHO5ZppEy8EgP3w1V8kdM9GxaI/ 2. Recommendation from the Authors of Dilithium /MLDSA: "Use Dilithium in a so-called hybrid mode in combination with an established "pre-quantum" signature scheme." https://pq-crystals.org/dilithium/ Also, some users may prefer conservative migration. So, it will be great if both specifications can go through adoption and get published soon. It will be customers’ choices to either or even both of them. Cheers, Guilin From: Daniel Apon <[email protected]> Sent: Tuesday, 5 May 2026 12:32 pm To: Wang Guilin <[email protected]> Cc: Jacob Appelbaum <[email protected]>; Salz, Rich <[email protected]>; TLS List <[email protected]> Subject: Re: [TLS] Re: Working Group Last Call for Use of ML-DSA in TLS 1.3 P.S. By contrast, the Yao Class has attempted similar "gotcha results" against lattice-based cryptography, and failed repeatedly. i) https://eprint.iacr.org/2024/555.pdf ii) https://arxiv.org/pdf/2509.12341v7 On Tue, May 5, 2026 at 12:18 AM Daniel Apon <[email protected]<mailto:[email protected]>> wrote: In particular -- just for emphasis on the process working as intended: NIST publicly awarded Craig Costello from Microsoft Research (one of the key co-authors of SIKE) the (only) Best Talk Award from the NIST PQC Conferences, for putting money on the line for attacks against SIKE. It was incredibly important at the time to highlight additional focused cryptanalysis on isogeny-based cryptography (and SIKE in particular), which had gone relatively unexplored throughout the process up to that point. See https://csrc.nist.gov/events/2021/third-pqc-standardization-conference Best Talk Award The Case for SIKE: A Decade of the Supersingular Isogeny Problem On Tue, May 5, 2026 at 12:13 AM Daniel Apon <[email protected]<mailto:[email protected]>> wrote: Hi Guilin, You wrote: "I guess here stresses on improving security strength via using larger parameters or key sizes, but hybrid approach concerns more about the consequence in case the only pure PQ algorithm is fundamentally flawed (as what happened to SIKE) or some breakthrough cryptanalysis surpasses the security margin. Below is the link for our recent discussions in TLS WG mailing list on the almost same topic. https://mailarchive.ietf.org/arch/msg/tls/5GiyxhMA7rhvR73tKrnRd8ZeOK8/"; Yes, it is clear what the hybrid approach is. I also support both pure-PQC and hybrid approaches; they should be available, in standard, to anyone. But as I mentioned before on this WG mailing list, this lesson "from SIKE" -- so easily stated -- that PQC algorithms may be fundamentally flawed, is incredibly technically imprecise. SIKE's mathematics had a significantly higher barrier-to-entry for the corpus of PQC researchers to understand it, properly analyze it, and speak about it broadly. At the end of NIST PQC Round 3, SIKE was adjudicated by NIST as having not received sufficient study, which is why it was moved into a 4th Round (as a unique object). Lo and behold-- with some additional study and focus, there was a break. This was a success of the process itself; not a weakness of PQC algorithms. This is a distinct and opposite case from the study of the concrete security of noisy linear codes (both lattice-based and code-based). While 3 code-based schemes were moved on past the 3rd round (HQC, BIKE, and Classic McEliece), these schemes had outstanding issues between them that hadn't resolved yet (BIKE's decryption failure analysis, Classic McEliece's syzygy security and high practical cost of large PKs, and HQC's larger costs vs BIKE). These issues were significantly more mature and specialized than the technical situation with SIKE. By contrast to SIKE (which was eventually broken outright within a quick sequence of works), many orders of magnitude of technical research works have gone into the study of cryptanalysis of noise linear systems. It's just not a good parallel to draw. On Mon, May 4, 2026 at 11:56 PM Wang Guilin <[email protected]<mailto:[email protected]>> wrote: For me, as stated previously, I support the use of ML-DSA and also composite ML-DSA in TLS 1.3. (For the latter case, yes, the number of composites may need to be reduced from 13 to a few, as several other experts mentioned. ) I do not understand the underlying logic about “defines A is not the place for an A compared-to B comparison”. As both A and B are two apparent approaches to solve the same problem, the authors, the readers and the future implementers all know this. How can we just ignore this issue in a specification as if B were not existing? Yes, comprehensive comparison with (rough) consensus seems very hard to achieve, but some middle ground or neutral wordings are also helpful for the readers. In the simplest (also the worst?) case, at least the specification can say and refer to approach B, I think. >Two hard problems at X-bit security, broken independently, should take 2*2^X = >2^{X+1} work. > One hard problem at 2X-bit security should take 2^{2X} work. I guess here stresses on improving security strength via using larger parameters or key sizes, but hybrid approach concerns more about the consequence in case the only pure PQ algorithm is fundamentally flawed (as what happened to SIKE) or some breakthrough cryptanalysis surpasses the security margin. Below is the link for our recent discussions in TLS WG mailing list on the almost same topic. https://mailarchive.ietf.org/arch/msg/tls/5GiyxhMA7rhvR73tKrnRd8ZeOK8/ Cheers, Guilin From: Daniel Apon <[email protected]<mailto:[email protected]>> Sent: Tuesday, 5 May 2026 9:47 am To: Jacob Appelbaum <[email protected]<mailto:[email protected]>> Cc: Salz, Rich <[email protected]<mailto:[email protected]>>; TLS List <[email protected]<mailto:[email protected]>> Subject: [TLS] Re: Working Group Last Call for Use of ML-DSA in TLS 1.3 Hi Jacob, You wrote: "When better is defined as "two hard problems are more secure than one maybe hard problem"" This is neither standard nor textbook in complexity theory. Two hard problems at X-bit security, broken independently, should take 2*2^X = 2^{X+1} work. One hard problem at 2X-bit security should take 2^{2X} work. If you want to increase security, you should increase parameter sizes. Or, you should have chimed in on the security of the hard problem a decade ago when it was being discussed internationally. ========== In response to: "a document that defines A is not the place for an A compared-to B comparison" You wrote: " Where should it go if not there?" My answer is here. Resolve that here, in this conversation. Not in a long-lived document. ========== I believe I agree with Rich and Uri in this conversation. Moreover, I do not think both a "Why hybrids?" and a "Why not hybrids?" section being added addressing any of my concerns; in fact, I believe it only makes shoving worse -- by shoving controversy and various arguable opinions into a standard. The standard should stand on its own standard legstands. --Daniel On Mon, May 4, 2026 at 9:52 AM Jacob Appelbaum <[email protected]<mailto:[email protected]>> wrote: Hi Rich, On 5/4/26 15:00, Salz, Rich wrote: > * I had sincerely proposed what I believe is a good middle ground to > move on. WG is free to trash my proposal. > > Okay then. Your proposal is not a middle ground. What are the sides from your perspective and what would be a middle ground if not this? > It says that hybrids are better. When better is defined as "two hard problems are more secure than one maybe hard problem" or "one new failure cannot result in a practical break of the protocol" then it follows that hybrids are better. If we're not talking about "better" in the context of security but byte overhead or energy efficiency, then we'd need some other definitions for the word better, I suppose. > > I still maintain that a document that defines A is not the place for > an A compared-to B comparison. Where should it go if not there? If it should go somewhere else, would a reference to that other place also be wrong? > From the mailing list traffic, several other long-timers agree with that. > This reads as an appeal to authority over a reasonable analysis that is related to Usama's formal proof. I do not find it compelling and it appears as dismissive to Usama's efforts. What's the constructive counter proposal other than writing as if hybrids don't exist or that PQC without a hybrid construction isn't a novel risk? Long-timers can be wrong and given the Dual_EC history and various related drafts, they might even be wrong twice for the concerns raised by Usama and others. Kind regards, Jacob Appelbaum _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
