On 12/06/2020 00:27, Hal Murray wrote: > > levitte@xxxxxxxxxxx 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
