Inline: On Thu, Jun 20, 2024 at 9:03 AM tirumal reddy <[email protected]> wrote:
> On Wed, 19 Jun 2024 at 20:59, Ilari Liusvaara <[email protected]> > wrote: > >> On Wed, Jun 19, 2024 at 05:00:09PM +0530, tirumal reddy wrote: >> > On Tue, 18 Jun 2024 at 21:02, Ilari Liusvaara <[email protected] >> > >> > wrote: >> > >> > > Hybrid KEMs do not introduce the same complexities as HPKE: >> > > >> > >> > HPKE has the advantage of integrated key management to handle the >> > combination of the shared secrets to derive the final secret, utilizing >> a >> > KDF at the required strength, and ensuring the appropriate security >> levels >> > to combine traditional and post-quantum cryptography (PQC). >> > What makes leveraging HPKE complex compared to native Hybrid KEM >> support in >> > JWE? >> >> The thing that makes HPKE complicated to integrate is that it also >> performs symmetric encryption. >> > > This complication can be avoided by defining {alg: > "HPKE-Base-P256-SHA256", enc: "A128"}. > Yes, and this is why we are coordinating with COSE, because we want to align on this sort of thing. > > >> >> JOSE (and COSE) already has KDF in order to handle ECDH-ES. And proper >> hybrid KEM (e.g., X-Wing) already handles combining traditional and >> post-quantum cryptography. >> > > Yes, and X-Wing also defines Hybrid PQ/T HPKE interfaces. > > >> >> >> > > > In both cases, a new parameter would have to be defined to carry >> > > > the KEM ciphertext. >> > > >> > > New parameter is trivial to add. >> > >> > >> > The new parameter will not be integrity protected but in the case of JWE >> > compact serialization it must be integrity protected. >> >> There is no need to integerity protect the encapsulated key unless using >> some bad KEMs with PSK. >> > > No, compact serialization requires JWE protected headers and the new > parameter has to be within the protected header. > encapsulated keys do not need to be secured as aead aad, afaik. But then we need to explain that we are changing JWE to allow an encapsulated key to be transported as an "encrypted key", and how that works in JSON and compact serialization. There is more than one way to solve the "where to put encapsulated keys" problem safely I think, but they come with different trade offs. New header parameters, or changing the definition of encrypted key, or both. It seems ok to know that you need process parameters differently based on the algorithm that is chosen. > > >> >> And also, if there was some requirement for integerity protecting it, >> then the whole thing would be broken, because it can not be protected >> with multiple recipients. >> > > I meant integrity protected only in case of compact serialization and no > integrity protection with multiple recipients. > Yes, and that's consistent with what I said above... Because of how JWE was built, we are required to keep relating compact and JSON serializations. > > >> >> >> > > I had designs like this a while back. I think HPKE-Base-P256-SHA256 >> can >> > > be regarded as Direct Key Agreement. Which would make >> > > HPKE-Base-P256-SHA256-A128KW Key Agreement with Key Wrapping. >> > > >> > >> > Yes. >> >> Idea that is bit odd but should technically work would be to use >> Direct Key Agremeent and Key Encryption. >> > > I think you mean a) Direct Key Agreement b) Key Agreement with Key > Wrapping. > Just to clarify the current source of this confusion. Both JOSE and COSE drafts use "HPKE-Base-P256-SHA256-A128GCM" for the case where you are logically doing this: alg: HPKE-Base-P256-SHA256-A128KW, enc: A128GCM ( 2 layer / indirect ) alg: HPKE-Base-P256-SHA256, enc: A128GCM (1 layer / "integrated" ) The hope is that by coordinating between JOSE and COSE, we pick algorithms that align, and we use them in headers and keys in a consistent way. So far, both groups have been saying "HPKE-Base-P256-SHA256-A128GCM" works for both cases.... which seems to have confused people in both working groups. The reason for this comes from HPKE: """ All the algorithms also take an info parameter that can be used to influence the generation of keys (e.g., to fold in identity information) and an aad parameter that provides additional authenticated data to the AEAD algorithm in use. """ https://datatracker.ietf.org/doc/html/rfc9180#section-5 ^ This sentence is what implies "alg" values like "HPKE-Base-P256-SHA256-A128GCM" instead of "HPKE-Base-P256-SHA256" (since this one has no AEAD, and therefore no aad parameter). > >> As constructing Key Encryption from HPKE is easier than constructing >> Key Agreement with Key Wrap out of HPKE. >> >> Yes, it is not symmetric, but there are going to be all sorts of >> differences anyway. >> >> >> > > This design is compatible with oneshot API (all designs using existing >> > > modes are). >> > > >> > >> > The design is not compatible with oneshot API in case of compact >> > serialization, it creates a cyclic dependency (encapsulated key will >> have >> > to be integrity protected). >> >> ECDH-ES also uses headers in key agreement step, and works just fine >> with compact serialization. >> >> Key agreement operation occurs before committing protected headers, >> which occurs before bulk encryption. >> > > Yes, that means the oneshot API won't work (but that is anyway not a > requirement to mandate the use of it). > Agreed that the oneshot API is not required, but it's possible that moving encapsulated keys out of protected headers can have an impact here. IIRC, epk is not required to be integrity protected, and it follows that encapsulated keys are also not required to be integrity protected. > -Tiru > > >> >> >> > > One small issue with this is that enc gets base64-url encoded twice, >> > > >> > >> > The overhead of base64url encoded twice is only applicable to compact >> > serialization, it is the same problem with Hybrid KEM or Pure PQ KEM >> (e.g., >> > ML-KEM) where the KEM ciphertext will have to be base64url encoded >> twice. >> >> Yes, native KEMs also double-encode, unless doing weird stuff with >> encoding. >> >> >> >> >> -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] > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
