I can’t say I agree with this argument. If we have a combiner with a proof that “if either of the primitives we have meet security property A, then the output of the combiner meets security property B”, and we have proofs that both our primitives meet security property A”, then doesn’t that mean that our system has a proof that it meets security property B? Wouldn’t that proof still apply even if one of our primitives fails due to some cryptanalytic attack?
Wouldn’t that also mean that if we have several primitives that all have proofs of security property A, we could mix-and-match as convenient, and that we don’t need to generate N^2 proofs to handle each of the combinations? [Note: I’m not arguing that we should have this level of flexibility; only that we could] As an analogy, consider the current TLS 1.3 situation. There are multiple key agreements allowable (DH and ECDH), multiple ways to do authentication (PSK and certificate), multiple signature types (RSA and ECDSA), multiple data protection algorithms (GCM, ChaCha20). For some reason, they don’t feel the need to prove each specific combination separately, but instead show that the various primitives meet some security assumptions, and go from there… From: CFRG <cfrg-boun...@irtf.org> On Behalf Of Orie Steele Sent: Thursday, January 11, 2024 2:58 PM To: Sophie Schmieg <sschmieg=40google....@dmarc.ietf.org> Cc: Salz, Rich <rsalz=40akamai....@dmarc.ietf.org>; Karolin Varner <k...@cupdev.net>; Peter C <Peter.C=40ncsc.gov...@dmarc.ietf.org>; IRTF CFRG <c...@irtf.org>; Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org>; <tls@ietf.org> <tls@ietf.org>; Kampanakis, Panos <kpanos=40amazon....@dmarc.ietf.org> Subject: Re: [CFRG] [TLS] X-Wing: the go-to PQ/T hybrid KEM? Hybrids by their very nature are the explosion. If there will only ever be X-Wing, I think it's fine to not make it generic (since we admit that it is a special case, not an instance of a generic). However, if B-Wing (brainpool + kyber) and P-Wing (p curve + kyber) also end up getting made, we never stopped the explosion, and we made it harder to evaluate the security properties, and we delayed the rollout against harvest and decrypt... for the cases where X-Wing could not fit. Yes, we will need proofs for all those other hybrids, sounds like that will keep people busy for a while... It feels like promising false hope to say that making X-Wing not generic will stop all that other work from happening... If anything, making X-Wing generic will reduce the cost of doing the work, that seems inevitable at this point. I do think it's important for this to not end up as "crabs in a bucket", where each candidate holds the others back, and then they all get cooked together. If arguing over generic's causes that, I suggest we not make generics a requirement. OS On Thu, Jan 11, 2024 at 1:35 PM Sophie Schmieg <sschmieg=40google....@dmarc.ietf.org<mailto:40google....@dmarc.ietf.org>> wrote: I very much appreciate having a concrete hybrid scheme that is intentionally not generic. This avoids the explosion of ciphertext suites that would otherwise occur, and allows for better compatibility of libraries. Fixing the key sizes to ML-KEM 768 and X25519 is aligned with our preferred choices as well, and further increases interoperability. On Thu, Jan 11, 2024 at 9:31 AM Salz, Rich <rsalz=40akamai....@dmarc.ietf.org<mailto:40akamai....@dmarc.ietf.org>> wrote: I'm going to echo Bas to highlight that X-Wing is not generic to any IND-CCA KEM, it is a particular primitive construction based on the internal construction of ML-KEM in particular: I don’t think it’s our place to try to shoe-horn everything into one construct. Particularly when we are in the experimentation phase of things. If people want to have ML-KEM as a material in their composites, it sounds like they might want to learn from X-Wing, but not try to chop them to fit into that one keyhole, as it were. _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls -- Sophie Schmieg | Information Security Engineer | ISE Crypto | sschm...@google.com<mailto:sschm...@google.com> _______________________________________________ CFRG mailing list c...@irtf.org<mailto:c...@irtf.org> https://mailman.irtf.org/mailman/listinfo/cfrg -- ORIE STEELE Chief Technology Officer www.transmute.industries<http://www.transmute.industries> [https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
