On Tue, 18 Jun 2024 at 21:02, Ilari Liusvaara <[email protected]> wrote:
> On Tue, Jun 18, 2024 at 07:08:46PM +0530, tirumal reddy wrote: > > On Tue, 18 Jun 2024 at 17:32, Ilari Liusvaara <[email protected]> > > wrote: > > > > > On Mon, Jun 17, 2024 at 07:44:04PM +0000, Mike Ounsworth wrote: > > > > > > I estimate that defining the needed algorithms for native KEM support > > > to both JOSE and COSE would take about a page of spec text (not > > > counting IANA considerations). > > > > > > > Integrating the PQ/T hybrid scheme (ECDH-ES+ML-KEM) into JWE introduces > the > > same complexities as HPKE that require modifications to the existing JOSE > > framework. > > 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 source of complexity in HPKE in JOSE is not fitting any existing Key > Managment Mode, and JOSE not being designed for new KMMs. > > Whereas native KEMs (including hybrid) are DKA or KAwKW, and thus can > reuse all the JWE/COSE machinery for those modes. And then it is further > possible to reuse KDF, which is substantial part of ECDH-ES machinery > in JWE/COSE. > > > > 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. It is the same complexity in both cases. > > > > As discussed previously, it is not essential to use the one-shot API > > in HPKE. It is easy to split the HPKE suite information differently > > for key encryption and direct algorithm to align with JWE. For > > example: > > > > 1. Direct: {alg: HPKE-Base-P256-SHA256, enc: A128GCM} (this could lead to > > mismatches in strength, and hash function, and poor interop) > > 2. Indirect: { alg: HPKE-Base-P256-SHA256-A128KW, enc: A128GCM } > > 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. > > 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). > > > 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. > which is ~500 byte penalty with PQC stuff. It is also incompatible with > Auth/AuthPSK stuff (but PQC stuff is incompatible with that anyway). > Agreed. -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]
