[jose] Re: draft-ietf-jose-hpke-encrypt-01

[Ilari Liusvaara <[e-mail]>]

On Mon, Jul 08, 2024 at 07:11:22PM -0700, Les Hazlewood wrote:
> >
> > Why is JWE HPKE Key Encryption necessary at all?  Since HPKE requires
> > asymmetric keys to be used, what is the use case for encrypting a
> > direct/shared symmetric key when the recipient must decrypt with their
> > private key anyway?
> >
> 
> Trying to answer my own question:
> 
> "alg": "HPKE-P256-SHA256",
> "enc": "A256GCM"
> 
> would mean a JWE content encryption key would be obtained by executing the
> KEM to derive a shared secret which is then made uniform by HKDF-SHA256.
> The output of the HKDF Expand function would be the content encryption key
> used to directly encrypt the payload using AES 256 GCM.
> This would imply that the HKDF's `Expand(prk, info, L)` function's `L`
> input length must be equal to the `enc` required key length (in this
> example, `256`).

Right. And doing that with HPKE requires secret export API (RFC 9180
section 6.2.).

 
> Whereas
> 
> "alg": "HPKE-P256-SHA256-A256GCM",
> "enc": "A128GCM"
> 
> would mean
>   a) an ephemeral AEAD secret key (the CEK) would be generated for the
> `enc` algorithm (e.g. AES 128 GCM)
>   b) this ephemeral AES 128-bit CEK would itself be encrypted using HPKE
> P256-SHA256-A256GCM
>   b) the ephemeral AES 128-bit CEK would be used to encrypt the recipient
> payload, and the CEK ciphertext would be included in the recipient header.
> 
> Then the recipient uses HPKE P256-SHA256-A256GCM to decrypt the CEK
> ciphertext, producing the CEK, which is then used to decrypt the payload.

Right.




-Ilari