EVP_MAC_init() in 3.0 alpha 13

[Hal Murray]

> Did you attempt to pass NULL for the key and zero for it's length to the
> EVP_MAC_init() call? 

Yes.

We can do better.  If we have to use dup/free, we can move the EVP_MAC_init() 
to before the dup, out of the timing path.

My model is that initialization is 2 parts.  The first is turning the key into 
a big table.  The second is initializing a small amount of state that is 
whatever is needed/updated by EVP_MAC_update().

I was hoping that EVP_MAC_init() with NULL key would bypass the first step and 
do the second.

If the second step involves a lot of computation we get into the space/time 
tradeoff of computing it during step one and saving it in case EVP_MAC_init is 
called with NULL key.

If there was a copy operation we could use it instead of dup/free.

Where is the code that does the key setup?  I expect it will be obvious after 
I see it, but I don't know my way around that linkage yet.  I'm using the 
default AES-128-CBC.

---------

I don't think I've said it explicitly, but thanks for the change to the API 
for EVP_MAC_init()

----------

Should PKEY be a potentially interesting approach for something like this?  I 
think it was suggested months ago.  One advantage is that the code works with 
1.1.1.

It's horribly slow in 3.0

alpha14:
0.777 CMAC
7.533 PKEY
3.323 PKEY preload
0.392 EVP_MAC
0.308 EVP_MAC Preload with dup+free
0.102 EVP_MAC Preload (no dup, wrong answer)

1.1.1k:
0.285 CMAC
0.550 PKEY
0.196 PKEY preload



-- 
These are my opinions.  I hate spam.