Re: [jose] [COSE] Fwd: New Version Notification for draft-reddy-cose-jose-pqc-kem-00.txt

On Wed, 6 Mar 2024 at 14:39, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Wed, Mar 06, 2024 at 01:11:26PM +0530, tirumal reddy wrote:
> > Hi Illari,
> >
> > On Tue, 5 Mar 2024 at 20:53, Ilari Liusvaara <ilariliusvaara@welho.com>
> > wrote:
> >
> > > The way KEMs operate is extremely similar to how ECDH-ES works. So the
> > > way to add KEMs is to copy ECDH-ES (fully specified if needed) and make
> > > small modifications required for it to work.
> > >
> >
> > I think you are proposing the following changes:
> >
> > 1) Direct key Agreement: The alg parameter will carry the full specified
> PQ
> > KEM with KDF and AEAD (e.g., PQ-MLKEM768-SHA3-384-AES256). No need to
> > define "PQ-Direct" in this mode.
>
> Direct Key Agreement does not use AEAD for anything. If using a KEM, it
> just combines KEM and KDF (the existing ECDH-ES implcitly uses SHA-256).
>
> Moreover, there is no need for PQ, and usually with SHA-3, one uses
> SHAKE256 instead of >256-bit SHA-3. There is only ever going to be one
> variant, so might as well leave that out from the name.
>

SHA-3 is internally used by ML-KEM but I don't see any problem using
SHAKE256 with the three parameter sets of ML-KEM.

>
> So something like "MLKEM768". "enc" parameter will retain its meaning
> specified in JWE.
>
> The way it works will be extremely close to how ECDH-ES works.
>

Got it, but it will allow any AES key size to be used with any parameter
set of ML-KEM.

>
>
> > 2) Key Agreement with Key Wrapping: alg parameter will carry the full
> > specified PQ KEM with KDF and AEAD key wrap (e.g.,
> > PQ-MLKEM768-SHA3-384-AES256KW). The "enc" parameter will be used as usual
> > to carry AEAD to encrypt the content.
>
> Again, per above plus some conventions, it would be "MLKEM768+A256KW".
>
> And the way it works is extremely close to ECDH-ES+A256KW.
>

Yes, works for me (except for the above concern).

>
>
> > > The two main modifications compared to ECDH-ES are:
> > >
> > > 1) The shared secret is generated by encapsulation/decapsulation
> instead
> > >    of ECDH operation.
> > > 2) New header parameter for KEM ciphertext, as it is octet string and
> > >    not a key.
> > >
> >
> > Yes, it is possible to introduce a new header parameter to carry the
> > KEM ciphertext.
>
> In COSE, one can reuse the -4 from COSE-HPKE draft as it has all the
> correct properties. However, JOSE needs a new parameter.
>

-4 is used to carry an encapsulated key, which is a serialized ephemeral
key of the sender. What is the need to overload this parameter to carry an
encapsulated key in HPKE and ciphertext in PQ KEM ?

-Tiru

>
>
> -Ilari
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>