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"}. > > 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. > > 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. > > > > > 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. > > 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). -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]
