On Thu, Jun 13, 2024 at 01:47:25PM +0530, tirumal reddy wrote: > On Wed, 12 Jun 2024 at 20:03, Ilari Liusvaara <[email protected]> > wrote: > > > The two modes do not even invoke the same algorithm operations in JOSE, > > so I don't think it is complicated to put the encrypted key into JWE > > Encrypted Key when performing direct HPKE. > > > > If traditional asymmetric algorithms are used (e.g., ECDH-ES), the public > key in "epk" is placed in the JWE protected header.
That is not correct. If there are multiple recipients, then "epk" is *required* to be unprotected. If using single recipient with JWE serialization, unprotected seems to be preferred (even if protecting is possible). The only case where "epk" needs to be integerity protected is when using compact serialization, and that is just because there are no unprotected headers. > Leveraging a single-shot API in HPKE is not mandatory, so incase of > direct HPKE, the encapsulated key can be placed in the "epk" within > the JWE protected header. It turns out it is much easier to place it in JWE Encrypted key than into headers. > Furthermore, the definition of the JWE Encrypted Key is to carry > the encrypted CEK. In the case of a post-quantum/traditional hybrid scheme, > the encapsulated key would include both the post-quantum KEM ciphertext and > the traditional encapsulated key. If the KEM is DHKem, PQ, Hybrid or something else is irrelevant. Take a look at what information the IANA registry about HPKE KEMs has: - Codepoint number - Name - Size of KEM output - Size of encapsulated key - Size of public key - Size of secret key - If Auth(PSK) mode is supported or not. - References Note that type of KEM is not listed. Because it is internal detail that is not important to anything but implementation of the KEM itself. > Why would you want to degrade that security property in the case of > HPKE by placing the encapsulated key in the JWE Encrypted Key for > HPKE and modify the definition of the JWE Encrypted Key? If there was any security reason for protecting the encapsulated key, then HPKE would have done that built-in. Maybe easiest way to see that there is no security reason to do so is to look at what assumptions does the HPKE security proof make of the KEM. It is of the kind where failures are either caused by really nasty issues that can't be easily worked around, or stuff that does not actually matter in practice. -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
