On Wed, 6 Mar 2024 at 14:39, Ilari Liusvaara <[email protected]> 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 <[email protected]> > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
