On Thu, 13 Jun 2024 at 17:57, Ilari Liusvaara <[email protected]> wrote:
> 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. > Yes, I am only referring to compact serialization where there is a problem. Summarizing the discussion so far a) indirect HPKE: no issue b) Direct HPKE: no issue with JWE serialization but the document has to be updated to use {"enc:dir", "alg: HPKE-....-A128GCM"} and the IANA registry will have to be updated for "dir" that it can also be used with "Direct use of a fully specified encryption suite". c) Direct HPKE: Two options under discussion a) place encapsulated key in "ek" b) place encapsulated key in "JWE Encrypted Key". > > > > 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. > What is the problem if the encapsulated key is placed in another header which can be integrity protected ? > > > > 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. > Yes, it is an internal detail but the JWE Encrypted Key definition would have to be updated. > > > > 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. I looked into the Encap function in HPKE, which already binds the encapsulation key to the shared secret, so I don't see a security problem. -Tiru > 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] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
