Bas Westerbaan writes: > At the moment the choice of hybrid is left to the application/protocol. > This has led to many different proposals for hybrids, which wastes a lot of > engineering, standardisation and security review time. I think it's better > if hybridisation is done at the level of cryptographic primitive.
I agree that it's desirable to have KEMs that are internally using double encryption and that can be reviewed independently of the target application---not relying on details of TLS 1.3, for example. For the same reasons (reducing security-review time, simplifying standardization, etc.), it's desirable to minimize the number of different double-encryption mechanisms. So I'd think that the default path forward would be to pick a single combiner such as hybridss = H(ssECDH,ssKEM,H(hybridct),H(hybridpk),context) where H is SHA3-256, hybridpk is (receiverpkECDH,receiverpkKEM), and hybridct is (senderpkECDH,senderctKEM). If there's instead a mechanism where the security analysis makes reference to the Kyber details, then that's more effort to review, and people plugging in KEMs other than Kyber (for good reasons: worrying about the Kyber patent claim from http://tinyurl.com/5cu2j5hf, trusting McEliece more, etc.) will need a different mechanism, so we end up with more mechanisms than necessary. What's the advantage justifying this? I saw the "hashing the typically large PQ ciphertexts" comment, but the dollar-cost calculations from https://cr.yp.to/papers.html#pppqefs imply that several thousand cycles to hash 1KB cost roughly 2^-38 dollars, whereas sending or receiving 1KB costs roughly 2^-30 dollars. Is there evidence of applications where the hashing cost is an issue? ---D. J. Bernstein _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
