CMAC timings

[Hal Murray]

Thanks.

> The manpage documents: The call to EVP_DigestSignFinal() internally finalizes
> a copy of the digest context. This means that calls to EVP_DigestSignUpdate()
> and EVP_DigestSignFinal() can be called later to digest and sign additional
> data. 

I saw that, but couldn't figure out what it meant.  "additional" suggests that 
it would keep going and sign the current data plus new data.  That didn't seem 
very relevant for my use case.  "another" might be a better word.

Is the idea that it makes the internal state so it is the same as after 
EVP_DigestSignInit()?  If so, that would allow significant CPU savings in the 
request/response case where we sign twice with the same key.


> - alloc/free. 12 alloc and 16 free calls per signature

I'm curious.  12 seems like a huge number.  I'd expect 1.  What's going on?


> And:
>        EVP_MD_CTX_FLAG_FINALISE
>            Some functions such as EVP_DigestSign only finalise
>            copies of internal contexts so additional data can be
>            included after the finalisation call. This is
>            inefficient if this functionality is not required, and
>            can be disabled with this flag. 

Now that you have explained it, I can try to read between the lines.

That "only" seems misleading.

"inefficient if this functionality is not required" doesn't make much sense 
(too me) in the context of finalize.  The inefficiency is that you will have 
to repeat the setup if you want to do another run with the same key.


-- 
These are my opinions.  I hate spam.