EVP_MAC_init() in 3.0 alpha 13
hmurray at megapathdsl.net
Mon Apr 12 12:48:57 UTC 2021
> Did you attempt to pass NULL for the key and zero for it's length to the
> EVP_MAC_init() call?
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
I don't think I've said it explicitly, but thanks for the change to the API
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
It's horribly slow in 3.0
3.323 PKEY preload
0.308 EVP_MAC Preload with dup+free
0.102 EVP_MAC Preload (no dup, wrong answer)
0.196 PKEY preload
These are my opinions. I hate spam.
More information about the openssl-users