On Fri, 14 Jun 2024 at 17:06, Ilari Liusvaara <[email protected]> wrote:
> On Fri, Jun 14, 2024 at 01:22:32PM +0530, tirumal reddy wrote: > > On Thu, 13 Jun 2024 at 21:02, Ilari Liusvaara <[email protected]> > > wrote: > > > > > > c) Direct HPKE: Two options under discussion a) place encapsulated > key in > > > > "ek" b) place encapsulated key in "JWE Encrypted Key". > > > > > > It turns out to depend on how "enc:dir" is defined which of these is > > > possible. > > > > > > > It can be defined as follows: > > Direct use of a fully specified encryption suite in the alg parameter > that > > specifies the KEM for key agreement, the KDF for generating the final > > shared secret, and the AEAD for encrypting the payload. > > I mean specifying how encryption and decryption is done in that mode, > similar to JWE sections 5.1 and 5.2. > Got it, Thanks. > > > > > The definition of "enc:dir" has to be significantly more complex to > make > > > it even possible to use headers in compact serialization. > > > > > > Can you elaborate why it would have to be much more complex to use new > > headers in compact serialization ? > > The "enc:dir" would have to be defined to invoke two different new > algorithm operations, the first to set up the headers and the > second to perform actual encryption. Yes, the additional task is to set up the "ek" header. > > As opposed to invoking just one new algorithm operation that does > the whole algorithm-specific part of encryption. > > > > > > > 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. > > > > > > "enc:dir" has to redefine JWE Encrypted key anyway. Because there is no > > > "Content Encryption Key" (which has very specific meaning in JOSE). > > > > > > Dealing with JWE Encrypted Key in "enc:dir" is simple, dealing with > > > headers in "enc:dir" is not. > > > > > > > If the encapsulated key is conveyed in "ek", JWE Encrypted key will be an > > empty octect sequence and no need to redefine it. > > All JWE modes explicitly define what goes into JWE Encrypted Key. > Okay, we will update the draft. > > > > > HPKE does not bind encapsulation key to shared secret. > > > > > > > No, the encapsulated key is passed as KEM context in ExtractAndExpand > > function to derive the final shared secret (see Encap function in > RFC9180). > > Any KEM that is not DHKem redefines that function. > Yes. > And it can do it in a way that does not bind encapsulated key to shared > secret (modulo what IND-CCA requires). > ML-KEM binds the hash of the public key to the shared secret. -Tiru > > > > -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]
