Dear All, to me, it seems conceptually useful if the libraries that implement ML-KEM respect the Fujisaki-Okamoto transform and also give access to the underlying IND-CPA secure K-PKE. I would love to hear the opinions of the community about this.
Let me explain: ML-KEM (Kyber) uses the FO transform to turn an IND-CPA secure PKE (K-PKE) scheme into an IND-CCA2 secure KEM (ML-KEM). Conceptually, it is well-known (https://eprint.iacr.org/2012/211.pdf) that via an IND-CCA2 secure KEM, we can build efficient key exchange protocols that feature perfect forward secrecy (PFS), a notion where long-term key corruptions do not immediately reveal the session keys of past sessions. (PFS has been a major selling point in moving from RSA-based key exchange to DH-based key exchange in TLS 1.2). To achieve any reasonable form of PFS we have to use fresh KEM/PKE material per session (ephemeral key exchange). Previous approaches send an ephemeral public KEM key pk’ from Alice to Bob, while Bob sends back an encapsulated key KEM k’ to Alice. Besides that, we can use an IND-CCA2 secure KEM for long-term key authentication where Alice encapsulates a key k1 to Bob’s public key pkB and Bob encapsulates a key k2 to Alice's pkA. The overall key would then be computed as a function of all the keys: k=KDF(k1,k2,k’). In practice, we can make use of the strong properties of the full-fledged ML-KEM for long-term authentication. However, as observed earlier, the ephemeral key exchange does not have to provide IND-CCA2 security. In fact, IND-CPA security seems sufficient. It is here where we could potentially save computational resources when designing security protocols since we do not need the full ML-KEM version. Taking this even further (https://eprint.iacr.org/2018/928.pdf) we may not even blindly apply the FO transformation (or rather a variant) to the PKE but more “to the entire protocol”. This can save even more hashing operations that are considered costly in the lattice setting. As before, the proof only requires the scheme to be IND-CPA secure. These two applications seem to indicate conceptually re-usable templates on how to use IND-CPA secure KEM/PKE in security protocols. So they might find applications in all sorts of variants of key exchange and security protocols in general. Both of them seem to indicate that there might be a benefit of making libraries that implement ML-KEM and also offer a nice interface to the underlying PKE scheme as well since this scheme might be used in other contexts. So my questions to the implementors are basically: Are (general-purpose) libraries offering nice interfaces to K-PKE to make it usable out of context? If not, what are your reasons? Although from a provable security standpoint using K-PKE might seem ok, are there considerations/objections specifically from the secure implementations people on this? I am trying to figure this out to understand whether the community will have a pervasively available PQ-secure IND-CPA scheme soon (as well) that is more efficient than ML-KEM. Let me stress that the draft of the standard specifically says “K-PKE is only a component. The public-key encryption scheme K-PKE described in Section 5 shall not be used as a stand-alone cryptographic scheme.” The above applications will not use it as a stand/alone component. All the best, Sven
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
