Provide direct GMAC API

[BrianSipos]

Although the behavior of GMAC, defined in NIST SP 800-38D, can be produced using existing cryptography hazmat primitives, it would be convenient to have a GMAC interface alongside CMAC and HMAC ones that follow the same API patterns. For an initial implementation only AES-GMAC would need to be usable and tested, as that is the most common use of GMAC.

OpenSSL also has a dedicated GMAC API which might have better performance than re-using existing Python-side AESGCM interface for GMAC. I don't have any evidence that either would be a better option.

[alex]

What is the use case for directly using GMAC?

…

On Mon, Dec 16, 2024 at 9:15 AM Brian Sipos ***@***.***> wrote: Although the behavior of GMAC, defined in NIST SP 800-38D, can be produced using existing cryptography hazmat primitives, it would be convenient to have a GMAC interface alongside CMAC and HMAC ones that follow the same API patterns. For an initial implementation only AES-GMAC would need to be usable and tested, as that is the most common use of GMAC. OpenSSL also has a dedicated GMAC API which might have better performance than re-using existing Python-side AESGCM interface for GMAC. I don't have any evidence that either would be a better option. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[BrianSipos]

As a high-speed, high-efficiency MAC in an environment where AES-GCM is already used for AEAD. I can work around this using existing AESGCM API so this can be labeled as more of a wishlist item than a needed addition.