Hi Ilari, If you talk about "nasty combinatorial explosion" then you need to explain how "nasty" it is, i.e. what the potential number of combinations we could have. In practice, none of these algorithm combinations have been bad in the past since most people are interested only in a small number of combination rather than anything that is theoretically possible (see TLS ciphersuites).
The comparison with TLS is also a bit misleading because TLS has different constraints than COSE. First, TLS is a peer-to-peer protocol and the environment HPKE was incorporated into was also very different. Ciao Hannes -----Original Message----- From: COSE <[email protected]> On Behalf Of Ilari Liusvaara Sent: Thursday, November 17, 2022 10:48 PM To: cose <[email protected]> Subject: Re: [COSE] AEAD algorithm ID for HPKE On Thu, Nov 17, 2022 at 02:49:47PM -0600, Orie Steele wrote: > Interested in unpacking The COSE_Key has new *kty HPKE*, and its JWK cousin. > > Comments inline: > > On Thu, Nov 17, 2022 at 2:02 PM Ilari Liusvaara > <[email protected]> > wrote: > > > On Thu, Nov 17, 2022 at 10:05:28AM -0600, Orie Steele wrote: > > > Illari answered a related question here: > > > https://mailarchive.ietf.org/arch/msg/cose/eIxt4u8ox8N35-ZbDk_vsFD > > > 9PP4/ > > > > > > I have similar questions on how HPKE, PQC KEMs, and COSE Key work > > together > > > in practice. > > > > Here is how I think it will work: > > > > - The COSE_Key has new kty HPKE, containing the algorithm used > > (expressed using HPKE KEM identifier), public key blob (bstr), > > possibly some hints and for private keys, private key blob (bstr). > > - When encrypting, the COSE-HPKE just passes the HPKE code the KEM > > identifier and the public key blob from the key (along with other > > stuff like the plaintext to encrypt). HPKE code knows what to do > > with those. > > > > > I would have assumed a slightly different interface, that pulled the > parameterization from the key representations, for example: > > // encrypt > const sender = HPKE.JOSE.sender.createSenderContext({ > publicKeyJwk: *kty*, ..., x, *alg: Kem.KemKyber1024HkdfSha256 - > Kdf.HkdfSha256 - Aead.Aes128Gcm* } > }) > const ct = await sender.seal(new TextEncoder().encode("hello > world!")); > > // decrypt > const recipient = HPKE.JOSE.recipient.createRecipientContext({ > privateKeyJwk: *kty*, ..., x, d, *alg: Kem.KemKyber1024HkdfSha256 - > Kdf.HkdfSha256 - Aead.Aes128Gcm* }, > enc: sender.enc, > }) > const pt = await recipient.open(ct); This would result in a nasty combinatorial explosion and a lot of extra work on the COSE WG, of the kind COSE WG is ill-equipped to do. > I understand HPKE design focuses on moving the parameterization > outside of the key representations, and to enable the same public or > private key to be used in many different ways. > > I think that's fine for folks who want that, but when designing APIs I > prefer to set this in stone at the time of key generation, and not > invite implementers to use the same key material with many different > parametrization of algorithms. HPKE is designed to be able to soundly use the same key material with multiple algorithms. > As I understand it, HPKE can support both design philosophies, but as > we start to register new kty, or alg values, we will be driving > consolidation towards one side or the other when HPKE is used in JOSE > or COSE. I am saying that one of those philosophies WILL lead to a mess. As for other users of HPKE, TLS ECH went with using key format similar to what I outlined (but with custom encoding). TLS did use ciphersuite approach for TLS 1.0 to 1.2. It was a giant mess with ultimately hunreds of entries. They switched away when they realized that using traditional ciphersuites for TLS 1.3 would have been totally unmanageable. As for "matching strengths", I understand that as purely avoiding doing unnecressary work in one part that is negated by other part. Hence, don't use 128-bit Chacha, because it is not faster than 256-bit Chacha. Furthermore, comparing strengths of different parts is complicated by different subtreshold scalings. E.g., 192-level ECDH (quadric scaling) is good bit stronger than 192-level symmetric cipher (linear scaling). > - When decrypting, the COSE-HPKE just passes the HPKE code the KEM > > identifier and the private key blob from the key (along with other > > stuff like encapsulated key and the ciphertext to decrypt. HPKE code > > knows what to do with those. > > > > If the KEM is PQC or not is not something COSE-HPKE code needs to > > concern itself with. Currently HPKE does not have any PQC KEMs, but > > that could change at any time. > > > > As for PQC outside HPKE in COSE, that is obviously more complicated > > matter, that turns out to need at least some new alg values, along > > with new (sub)types for the keys. Those things work in way similar > > to ECDH-ES, however reusing the ECDH-ES codepoints is not possible > > due to ECDH-ES requiring ephemeral key, which just does not exist for PQC. > > > > Yes, agreed, but I think the developer experience should still be > considered. Developer experience is secondary to cryptographic soundness. And creating a spec that is a complete mess is not conductive to good developer experience. My design philosophy is to try to make simplest correct implementation as simple as possible, and simplest working implementation as close to correct as possible ("get it right, or it won't work at all"). Hence things like overloading codepoints. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
