Do we have a survey of hybrid patents? To be clear, for security reasons I recommend a straightforward policy of always using hybrids (https://blog.cr.yp.to/20240102-hybrid.html). NIST reportedly bought out some hybrid patents; I'm not aware of hybrid patents that predate the clear prior art; and in any case it has been obvious for many years to try hashing any selection of the available inputs that both sides see, such as ciphertexts, public keys, session keys, and/or context labels. But I worry that a profusion of hybrid mechanisms could have someone getting into trouble with a non-bought-out patent on some specific hybrid mechanism, because of an unfortunate choice of details matching what the patent happens to cover. A patent survey would reduce concerns here.
Bas Westerbaan writes: > SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 || pk_X25519 > ) 1. I'd include the post-quantum ciphertext (or a hash of it). Rationale: This makes the construction more generic, and simplifies security review. There's negligible performance cost compared to the cost of communicating the ciphertext in the first place. (For quantification of costs of communication etc., see https://cr.yp.to/papers.html#pppqefs.) 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). Rationale: less chance of confusion regarding which key to include; better fit with some existing uses of X25519; might marginally simplify security review; even smaller performance cost than including the post-quantum ciphertext. 3. There are papers that recommend also including at least a 32-byte prefix of the post-quantum pk: (1) https://eprint.iacr.org/2021/708 recommends including some sort of user identifier and claims that it isn't "robust" to have ciphertexts that might be decryptable by multiple users; (2) https://eprint.iacr.org/2021/1351 recommends including a pk prefix for a different reason, namely to ensure that certain types of cryptanalytic attacks have to commit to the key they're attacking, which might make multi-key attacks harder. These arguments are weak, but the counterarguments that I see are also weak. On balance, I'd think that it's best to just include the pk (or a hash of the pk) in the hybrid-hash input, so people won't have to worry about the possibility of protocols where omitting it causes issues. There's a layering question regarding who's responsible for this hash. https://classic.mceliece.org/mceliece-security-20221023.pdf says the following: "Classic McEliece follows the principle that any generic transformation aiming at a goal beyond IND-CCA2 is out of scope for a KEM specification. This is not saying that further hashing should be avoided; it is saying that cryptographic systems should be appropriately modularized." I think the hybrid construction is a good place to put this hash. If there are many different hybrid constructions then factoring out another layer might be useful for reviewers, but I'd rather settle on a minimal number of hybrid constructions. 4. I'd put ss_X25519 before the post-quantum session key. This has a two-part rationale. First, there's a rule of thumb saying to start with the input that's least predictable for the attacker. This provides a principled way to settle the order even in situations where there's no reason to think that the order matters. Second, available evidence such as https://kyberslash.cr.yp.to indicates that the post-quantum session key is more likely to be predictable than the X25519 shared secret. It's of course reasonable to argue that this situation will be reversed eventually by a combination of quantum computing and any required upgrades to the post-quantum KEMs, the same way that it's reasonable to argue that hybrids will eventually be unnecessary, but hybrid designs should disregard those arguments. ---D. J. Bernstein _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
