Cleaning up usage of CMAC_xxx

[Matt Caswell]

On 12/06/2020 00:27, Hal Murray wrote:
> 
> levitte at openssl.org said:
>> In 1.1.1 and earlier, there is a different idea, using EVP_PKEY routines to
>> "sign" with a MAC.  We have a EVP_PKEY to EVP_MAC bridge in 3.0.0 to bridge
>> the gap. 
> 
> Thanks, but...
> 
> The EVP_PKEY seems to assume a public/private key environment.  The man page 
> for EVP_PKEY_new() says:

Nonetheless, what Richard says is correct. You can still do MAC
operations using EVP_PKEY. Its a horrible hack, and that's why we
introduced the EVP_MAC interface instead.

There's is some content on the Wiki about how to do HMAC using the "old"
EVP_PKEY approach. The same thing should also apply to CMAC:

https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying#HMAC

You can create an EVP_PKEY with an HMAC key using the function
EVP_PKEY_new_raw_private_key() and a CMAC key using the function
EVP_PKEY_new_CMAC_key():

https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_new_CMAC_key.html

However, EVP_MAC is the way of the future and should be the preferred
approach for anything running in 3.0 or above.

> I'm willing to have totally separate implementations for 3.0.0 and 1.x.x if 
> that's the cleanest way to go.

If you can afford the additional complexity, then I think it is worth it
- but its not strictly necessary (the old EVP_PKEY method does still
work in 3.0).

> I'm slightly concerned that the params API will be slow.  It's moving string 
> lookups into the mainline.  I don't have any numbers yet.

We don't expect it to be significantly worse - but we'd be very
interested in any numbers that you are able to produce.

> We also have a similar HMAC like digest mode using MD5 and SHA1 via 
> EVP_Digest.  Will that API be around long term?

We expect EVP_Digest* to be around for the long term.

Matt