Cleaning up usage of CMAC_xxx

[Hal Murray]

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:
       The structure returned by EVP_PKEY_new() is empty. To add a private or
       public key to this empty structure use the appropriate functions
       described in EVP_PKEY_set1_RSA(3), EVP_PKEY_set1_DSA, EVP_PKEY_set1_DH
       or EVP_PKEY_set1_EC_KEY.

We don't have public/private keys.  Perhaps it will help if I describe our 
environment.

The context is NTP.  NTP is a classic client/server, request/response 
protocol.  It uses UDP which is easily forged.  Basic packets are 48 bytes.

Shared-key authentication is optional.  Out of band, the client and server 
agree on a key, algorithm, and key ID.  The ID is an index into a (hash?) 
table of algorithm and key.  Authenticated packets have the ID and MAC 
appended to the packet.  The length of the MAC depends on the algorithm.

Key info comes from the keyboard or a text file with 1 line per key.  NIST 
uses USPS to distribute keys.

Busy servers process 10K-100K packets per second.  On the server, each packet 
requires 2 passes through the MAC algorithm, one to verify the MAC when 
receiving a request and another to compute the MAC when sending the response.  
The NTP protocol is simple.  The MAC calculations are a significant fraction 
of the per packet CPU load.  I'd like a fast/clean API to the low level MAC 
routines.  The CMAC API was good.

---------

I'm willing to do a reasonable amount of setup work during initialization, for 
example turning "AES" from a file to a EVP_CIPHER* to feed to CMAC_Init()  
Clean is more important than fast.

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

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 also have a similar HMAC like digest mode using MD5 and SHA1 via 
EVP_Digest.  Will that API be around long term?


-- 
These are my opinions.  I hate spam.