Add support for CMAC

[kmfukuda]

Follow-up to #806.

Implements #802 by adding the OpenSSL::MAC and OpenSSL::MAC::CMAC classes.

The classes are defined if compiled against OpenSSL 3.

[rhenium]

Thanks for working on this series.

The base class OpenSSL::MAC doesn't seem to be useful on its own currently. The EVP_MAC API seems quite generic, so I wonder if we can expose the OSSL_PARAM construction part and the EVP_MAC_init() call as a method under OpenSSL::MAC that accepts arbitrary (parameter, value) pairs. That way, OpenSSL::MAC::CMAC (or other MACs supported by EVP_MAC) could be implemented entirely in lib/openssl/mac.rb without requiring a specialized extension method.

Regarding the method naming, is there particular reason for choosing #{,hex,base64}mac instead of #*digest? Since OpenSSL::HMAC already uses #*digest, I think copying it would have less friction, though I agree it might not have been the best choice originally.

The #*mac naming seems redundant, especially when used with the shorthand methods like OpenSSL::MAC::CMAC.mac(ciph, key, data). Another idea would be to use #final taken from the C API, which is what OpenSSL::Cipher does. That said I'm not sure what name I'd give to the variant that returns the hexadecimal string.

Also, we need docs.

[rhenium]

I believe LibreSSL and AWS-LC will eventually implement the EVP_MAC API too. Please use an extconf.rb check instead of relying on the version number.

[rhenium]

Please sort them in alphabetical order.

[rhenium]

Technically, #initialize and #initialize_copy can be called twice, and in that case EVP_MAC_CTX already stored in RTYPEDDATA_DATA(self) will leak. It should be prevented.

I suggest taking a look at ossl_pkey*.c which deals with this issue by raising an exception.

[rhenium]

I think people would expect #inspect to show the class name or the algorithm rather than the calculated MAC.

[rhenium]

Comparing MACs generated by different algorithms or parameters would be pointless, but this doesn't prevent it and it's probably not possible unless we store parameters or sensitive keys ourselves, which would be a bad idea.

Honestly, I'm not sure if this should be provided by this library.