> > 2. I think it's good that both of the X25519 public keys are included > > where some hybrid constructions would include just one (labeled as > > ciphertext). > And it is required for the IND-CCA robustness: without it, it's not.
Well, that depends on _which_ X25519 key is included in the hash. If the recipient's KEM public key is an X25519 public key, and the sender's KEM ciphertext is an X25519 public key, and the KEM session key is the X25519 shared secret, then the KEM obviously isn't IND-CCA2: it has what https://www.shoup.net/iso/ calls "benign malleability". The normal way to upgrade from benign malleability to IND-CCA2 is to also hash the ciphertext---i.e., the sender's X25519 public key---into the session key. If the goal is maximum streamlining for IND-CCA2 then one shouldn't include the _recipient's_ X25519 public key in the hash, so why exactly does X-Wing include it? I don't think the goal here should be maximum streamlining for IND-CCA2. The point of hybrids is to do a bit more work to reduce the damage from screwups; I think the scope of screwups under consideration should go beyond mathematical breaks and also include implementation issues. In particular, what happens if protocol designers confuse the two X25519 public keys here, and hash the _recipient's_ public key instead of the _sender's_ public key? The upgrade to IND-CCA2 doesn't work. Hopefully the protocol is okay with benign malleability, but there has been so much emphasis on IND-CCA2 that it's hard to blame a protocol designer for assuming that KEMs have that property. So, as I said, I'm happy with a combiner hashing both of the X25519 public keys (along with the shared secret, obviously). But the same perspective also makes me ask what happens when people replace Kyber with a different post-quantum KEM. The combiner H = SHA3-256, hybridpk = (receiverpkECDH,receiverpkKEM), hybridct = (senderpkECDH,senderctKEM), hybridss = H(ssECDH,ssKEM,H(hybridct),H(hybridpk),context) is then safer than X-Wing. Even for people using Kyber, this KEM makes security review easier than X-Wing does. This combiner also satisfies requests (see my first message for references) to include KEM public keys (or at least prefixes of those) in the hash for other reasons. I don't see how the cost of hashing hybridct can be an issue next to the cost of communicating it. Same for hybridpk (and obviously the hash can be saved whenever the public key is saved). I worry about complicating KEM analyses since they're already complicated and error-prone in the first place---we've seen many breaks of KEM proposals---but this combiner is a separate module, and the IND-CCA2 property that it's requesting from the input KEM is what we're asking a KEM to do anyway. I think that the potential review benefit of _omitting_ hybridct and/or hybridpk will be outweighed by the review complication of ending up with more combiners than necessary. ---D. J. Bernstein _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
