EVP_MAC_init() in 3.0 alpha 13

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

EVP_MAC_init() in 3.0 alpha 13

Hal Murray

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 time mode of my old code put the cipher and key into a params array,
then called
  EVP_MAC_CTX_set_params(ctx, params) and then
  EVP_MAC_init(ctx)
That's easy to change.  I just drop putting the key into a params slot and
drop calling set_parms and add the key and parms to EVP_MAC_init.  That worked.

Is there a way to use a preloaded key?  I tried using NULL for key and params
when calling EVP_MAC_init.  It compiles and runs but doesn't get the right
answer.  Is that, or something like it supposed to work?

--------

EVP_MAC_CTX_set_params() seems ugly to me.

My inner loop looks like:
  EVP_MAC_CTX_set_params()
  EVP_MAC_init()
  EVP_MAC_update()
  EVP_MAC_final()

I'm trying to make things go fast.  It's going to have to do string compares
to figure out what I want to do.  I'm working with small blocks of data (48
bytes) so the setup cost is important.  Or I think it is, so I'm trying to
measure it.

The case I'm trying to get working is to move the EVP_MAC_CTX_set_params() out
of the loop.

--
These are my opinions.  I hate spam.



Reply | Threaded
Open this post in threaded view
|

Re: EVP_MAC_init() in 3.0 alpha 13

Dr Paul Dale-2
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 second preloads the key.  That would require an evp per key, but I
> might we willing to make that space/time tradeoff.
>
> The each time mode of my old code put the cipher and key into a params array,
> then called
>    EVP_MAC_CTX_set_params(ctx, params) and then
>    EVP_MAC_init(ctx)
> That's easy to change.  I just drop putting the key into a params slot and
> drop calling set_parms and add the key and parms to EVP_MAC_init.  That worked.
>
> Is there a way to use a preloaded key?  I tried using NULL for key and params
> when calling EVP_MAC_init.  It compiles and runs but doesn't get the right
> answer.  Is that, or something like it supposed to work?
>
> --------
>
> EVP_MAC_CTX_set_params() seems ugly to me.
>
> My inner loop looks like:
>    EVP_MAC_CTX_set_params()
>    EVP_MAC_init()
>    EVP_MAC_update()
>    EVP_MAC_final()
>
> I'm trying to make things go fast.  It's going to have to do string compares
> to figure out what I want to do.  I'm working with small blocks of data (48
> bytes) so the setup cost is important.  Or I think it is, so I'm trying to
> measure it.
>
> The case I'm trying to get working is to move the EVP_MAC_CTX_set_params() out
> of the loop.
>

Reply | Threaded
Open this post in threaded view
|

Re: EVP_MAC_init() in 3.0 alpha 13

Hal Murray
In reply to this post by Hal Murray

[hidden email] 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 anything suspicious.

--------

i5-3570 CPU @ 3.40GHz AES-128-CBC, 48 byte packets
Times in microseconds.

1.1.1k:
0.339 CMAC
0.676 PKEY
0.236 PKEY preload

alpha12:
0.933 CMAC
1.091 EVP_MAC
0.185 EVP_MAC Preload

alpha13:
0.905 CMAC
0.463 EVP_MAC
0.359 EVP_MAC Preload with dup/free
0.123 EVP_MAC Preload without dup/free, WRONG ANSWER


--
These are my opinions.  I hate spam.



Reply | Threaded
Open this post in threaded view
|

Re: EVP_MAC_init() in 3.0 alpha 13

Dr Paul Dale-2
In reply to this post by Hal Murray
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
> 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 time mode of my old code put the cipher and key into a params array,
> then called
>    EVP_MAC_CTX_set_params(ctx, params) and then
>    EVP_MAC_init(ctx)
> That's easy to change.  I just drop putting the key into a params slot and
> drop calling set_parms and add the key and parms to EVP_MAC_init.  That worked.
>
> Is there a way to use a preloaded key?  I tried using NULL for key and params
> when calling EVP_MAC_init.  It compiles and runs but doesn't get the right
> answer.  Is that, or something like it supposed to work?
>
> --------
>
> EVP_MAC_CTX_set_params() seems ugly to me.
>
> My inner loop looks like:
>    EVP_MAC_CTX_set_params()
>    EVP_MAC_init()
>    EVP_MAC_update()
>    EVP_MAC_final()
>
> I'm trying to make things go fast.  It's going to have to do string compares
> to figure out what I want to do.  I'm working with small blocks of data (48
> bytes) so the setup cost is important.  Or I think it is, so I'm trying to
> measure it.
>
> The case I'm trying to get working is to move the EVP_MAC_CTX_set_params() out
> of the loop.
>

Reply | Threaded
Open this post in threaded view
|

Re: EVP_MAC_init() in 3.0 alpha 13

Hal Murray
In reply to this post by 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.



Reply | Threaded
Open this post in threaded view
|

Re: EVP_MAC_init() in 3.0 alpha 13

Tomas Mraz-3
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.
>
> 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.

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.

> 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.

I do not think we want to introduce the copy operation. We are trying
to get out of the copy() pattern as it is much harder to handle
correctly than the dup().

> 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
>
>
>
--
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]


Reply | Threaded
Open this post in threaded view
|

Re: EVP_MAC_init() in 3.0 alpha 13

Hal Murray
In reply to this post by Hal Murray

[hidden email] 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 and doesn't
generate an error return.  Is there any other useful thing that a NULL key
could do?

I don't have a big picture view.  Is there any reason that all of the crypto
init type procedures can't keep the current key schedule if called with a NULL
key?

Am I the only one (so far) that is interested in reusing the current key
schedule to save CPU cycles?



--
These are my opinions.  I hate spam.