On Thu, Jul 06, 2023 at 06:44:18PM +0000, lgl island-resort.com wrote: > > > On Jul 6, 2023, at 8:59 AM, Ilari Liusvaara <[email protected]> > > wrote: > > > > On Thu, Jul 06, 2023 at 03:35:44PM +0000, lgl island-resort.com wrote: > >> IMO the objective is to define as few as we can. “what if… “ and > >> “what about…” will lead us astray. > > > > I think that any amount is either too few or too much. > > Yes, we’re gonna need to compromise.
While I do not think using ciphersuites is a good idea, here is what it would take: One would need some sort of sub-registry for algorithms that just contains the identifier values. This is because otherwise the next specification would have to re-specify the details, which is not acceptable. If the details are not specified the same way, the complexity will absolutely explode. Then the same for keys. For the same reasons as above. And there already is such KEM (ID 48). One would still need to define a new header parameter. Using "eph" will not work. What I think the policy should be: 1) For every KEM supported by HPKE, there should be at least one ciphersuite. 2) If any component is from omnibus national standard (e.g., ShangMi or GOST), then all components should be from the same standard. 3) If possible, the KDF chosen for ciphersuite should be the same as or at least as similar as possible to one used by the KEM. Otherwise it should match the security level. 4) All AEAD families with suitable security level should be supported. The variant chosen should be the lowest that at least matches the KEM, capped at 256 bits. Any post-quantum KEM is floored at 192 bits. Applying this policy to the present HPKE registry, one obtains the following ciphersuites: 1) 16-1-1 (128 bit KEM -> AES128) 2) 16-1-3 (Chacha is always 256) 3) 17-2-2 (192 bit KEM -> AES256) 4) 17-2-3 (Chacha is always 256) 5) 18-3-2 (260 bit KEM -> AES256) 6) 18-3-3 (Chacha is always 256) 7) 32-1-1 (128 bit KEM -> AES128) 8) 32-1-3 (Chacha is always 256) 9) 33-3-2 (224 bit KEM -> AES256) 10) 33-3-3 (Chacha is always 256) 11) 48-1-2 (Post-quantum, so at least 192 -> AES256) 12) 48-1-3 (Chacha is always 256) If HPKE adds compact NIST curves, then add analogs of the first six ciphersuites from the list. If HPKE adds AEGIS, then add analogs of every AES ciphersuite from the list, with AES128 -> AEGIS128L, AES256 -> AEGIS256. If HPKE adds ShangMi then ciphersuite CurveSM2-SM3-SM4, which is the only one using that KEM/KDF/AEAD. If some AEAD with only 128 bit version appeared, then add analogs of entries with AES128. If you think there will be only a few ciphersuites, either you have expansive definition of "few", or you will be very dissapointed... Dozen already, likely several in the future. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
