> On 16 Dec 2024, at 16:45, Simo Sorce <[email protected]> wrote: > > Agreeing with Neil, > I do not think AES-GMAC should ever be offered bare, in fact even FIPS > effectively prohibits its use outside of AES-GCM. > > The speed of the MAC algorithm is generally not critical for JOSE > environments which do not perform streaming operations anyway.
Exactly. It’s been a while since I measured it, but from memory GHASH only tends to be significantly faster once you get over about 2-4KB. (Counterpoint: AES-GCM-SIV was developed for high-volume short messages, so I could be way off base here). If I really wanted speed for lots of short messages, I’d be tempted to look at the 128-bit variant of SipHash, which is a PRF too. > > KMAC is also probably redundant given HMAC works just fine, however > KMAC at least is not a sharp razor blade in developers hands so it > should not be as actively harmful as GMAC. > > As an implementer I will definitely *not* make GMAC available, so I > would definitely prefer if these two are proposed in separate > documents, so they can be independently evaluated and accepted/rejected > independently. +1 (although I no longer maintain a JOSE library) Not to mention that you could achieve it now by just using AES-GCM JWE and putting all your content in the headers and leaving the body blank. That avoids having to introduce nonces into the MAC interface. — Neil _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
