+1 to that. Plus, if you really want to save space with algorithm identifiers then remove them from the messages and put them on the keys instead.
https://neilmadden.blog/2018/09/30/key-driven-cryptographic-agility/ <https://neilmadden.blog/2018/09/30/key-driven-cryptographic-agility/> https://www.nccgroup.com/uk/research-blog/real-world-cryptography-conference-2021-a-virtual-experience/#In-Band-Key-Negotiation-Trusting-the-Attacker <https://www.nccgroup.com/uk/research-blog/real-world-cryptography-conference-2021-a-virtual-experience/#In-Band-Key-Negotiation-Trusting-the-Attacker> — Neil > On 12 Dec 2024, at 14:44, Matt Chanda <[email protected]> > wrote: > > Hello! > > Similar to Simo, I'm a hard no on the short names. I prefer the longer names > because I value clarity and readability over saving a few bytes. Although it > can be looked up, it is abstracted too much from the underlying algorithm. > > Regards, > -matt > > >> On Dec 12, 2024, at 8:00 AM, Orie Steele <[email protected]> wrote: >> >> Here are the same name changes, proposed in COSE HPKE: >> >> https://github.com/cose-wg/HPKE/pull/60 >> <https://github.com/cose-wg/HPKE/pull/60> >> >> OS >> >> On Thu, Dec 12, 2024 at 7:26 AM Michael Jones <[email protected] >> <mailto:[email protected]>> wrote: >> https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/pull/12 >> <https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/pull/12> >> creates short algorithm identifiers, per the JOSE naming conventions >> <https://www.rfc-editor.org/rfc/rfc7518.html#section-1>. It uses the names >> proposed by Orie. >> >> >> >> -- Mike >> >> >> >> -----Original Message----- >> From: Simo Sorce <[email protected] <mailto:[email protected]>> >> Sent: Wednesday, December 11, 2024 1:21 PM >> To: Orie Steele <[email protected]> >> Cc: tirumal reddy <[email protected] <mailto:[email protected]>>; Michael >> Jones <[email protected] <mailto:[email protected]>>; >> [email protected] <mailto:[email protected]> >> Subject: Re: [jose] Re: JOSE HPKE algorithm identifiers >> >> >> >> On Tue, 2024-12-10 at 10:16 -0600, Orie Steele wrote: >> >> > Hey Simo, >> >> > >> >> > Can you say which format you prefer for proposed HPKE algorithms? >> >> > It is not clear which shortened proposal you are objecting to here. >> >> > >> >> >> >> I think HPKE-P256-SHA256-A128GCM is relatively clear. >> >> Otoh HPKE-P2-S2-A1 is difficult to read and will require a lookup table to >> know what A1 or S2 or P2 actually are ... >> >> >> >> If size really is an issue we should go full abstract and use a label like >> Addd (where ddd is digits, probably corresponding to the code COSE uses) >> and not even try to have meaningful text labels. >> >> >> >> > OS >> >> > >> >> > On Tue, Dec 10, 2024 at 9:44 AM Simo Sorce <[email protected] >> > <mailto:[email protected]>> wrote: >> >> > >> >> > > This would be a net regression, >> >> > > these areas are complicated enough that we do not need to add >> >> > > confusion to save a couple of bytes. >> >> > > >> >> > > On Fri, 2024-12-06 at 12:06 +0530, tirumal reddy wrote: >> >> > > > We can consider the short-form HPKE-P2-S2-A1. >> >> > > > >> >> > > > -Tiru >> >> > > > >> >> > > > On Fri, 6 Dec 2024 at 01:45, Michael Jones >> >> > > > <[email protected] <mailto:[email protected]>> >> >> > > > wrote: >> >> > > > >> >> > > > > Please see the discussion in the issue >> >> > > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >> > > > > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%252> >> > > > > Fgithub.com%2Fietf-wg-jose%2Fdraft-ietf-jose-hpke-encrypt%2Fissu >> >> > > > > es%2F8&data=05%7C02%7C%7C6fde9dccbc8b4bd1e81308dd1a29c4b5%7C84df >> >> > > > > 9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638695488902911696%7CUnkn >> >> > > > > own%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl >> >> > > > > AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdat >> >> > > > > a=3pM%2Fw54gezD7hOfgzApDinZkFe8s4%2ByOyD3TYTdPw%2F8%3D&reserved= >> >> > > > > 0 >> >> > > (*Algorithm >> >> > > > > identifiers like HPKE-P256-SHA256-A128GCM are overly verbose*) >> >> > > > > and add your thoughts there. >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> > > > > Thanks! >> >> > > > > >> >> > > > > >> >> > > > > -- Mike >> >> > > > > >> >> > > > > >> >> > > > > _______________________________________________ >> >> > > > > jose mailing list -- [email protected] <mailto:[email protected]> To >> > > > > unsubscribe send an email >> >> > > > > to [email protected] <mailto:[email protected]> >> > > > > >> >> > > > _______________________________________________ >> >> > > > jose mailing list -- [email protected] <mailto:[email protected]> To >> > > > unsubscribe send an email to >> >> > > > [email protected] <mailto:[email protected]> >> > > >> >> > > -- >> >> > > Simo Sorce >> >> > > Distinguished Engineer >> >> > > RHEL Crypto Team >> >> > > Red Hat, Inc >> >> > > >> >> > > _______________________________________________ >> >> > > jose mailing list -- [email protected] <mailto:[email protected]> >> > > To unsubscribe send an email to [email protected] >> > > <mailto:[email protected]> >> > > >> >> > >> >> > >> >> >> >> -- >> >> Simo Sorce >> >> Distinguished Engineer >> >> RHEL Crypto Team >> >> Red Hat, Inc >> >> >> >> >> >> -- >> >> ORIE STEELE >> Chief Technology Officer >> www.transmute.industries <http://www.transmute.industries/> >> <https://transmute.industries/> >> _______________________________________________ >> jose mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> > _______________________________________________ > 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]
