to...@openssl.org said:
> We would have to introduce the special semantics similar to EVP_CipherInit()
> with EVP_MAC_init(). I.e., that the EVP_CipherInit() with NULL key keeps the
> key schedule from the previous initialization.
Seems like a good idea to me. The current code doesn't crash an
On Mon, 2021-04-12 at 05:48 -0700, Hal Murray wrote:
> > 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
> 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 th
Did you attempt to pass NULL for the key and zero for it's length to the
EVP_MAC_init() call?
Pauli
On 5/4/21 10:51 pm, Hal Murray wrote:
It used to take just a ctx. Now it also wants a key+length and a params.
I have some simple/hack code to time 2 cases. The first gives it the key each
ti
pa...@openssl.org said:
> Does EVP_MAC_CTX_dup() after the MAC context has been initialised
> do what you want?
Thanks. Adding a dup/free gets the right answer, but isn't much of a speedup.
Is there a way to copy the critical bits into a working ctx?
I looked in the header file but didn't see
Does EVP_MAC_CTX_dup() after the MAC context has been initialised do
what you want?
Pauli
On 5/4/21 10:51 pm, Hal Murray wrote:
It used to take just a ctx. Now it also wants a key+length and a params.
I have some simple/hack code to time 2 cases. The first gives it the key each
time. The
It used to take just a ctx. Now it also wants a key+length and a params.
I have some simple/hack code to time 2 cases. The first gives it the key each
time. The second preloads the key. That would require an evp per key, but I
might we willing to make that space/time tradeoff.
The each ti
