PKEY CMAC timings

2020-06-17 Thread Hal Murray
Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz After Kurt's improvement, with our usage patterns (48 bytes), PKEY mode on 3.0.0 takes 2x as many cycles as 1.1.1 That factor probably depends on how good the hardware AES support is in your CPU. I think it's significantly faster in newer CPU chips. 1.1

Re: PKEY CMAC timings

2020-06-17 Thread Dr Paul Dale
How does it look for large input? As in many kilobytes or megabytes? Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 18 Jun 2020, at 1:18 pm, Hal Murray wrote: > > Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz > > After K

Re: PKEY CMAC timings

2020-06-17 Thread Hal Murray
> How does it look for large input? As in many kilobytes or megabytes? 16K is all I was willing to wait for. Timing for really long blocks turns into a memory test. The right unit is ns/byte. If that's an interesting case, I'll hack some code to do longer blocks. 1.1.1g AES-128 16 48

Re: PKEY CMAC timings

2020-06-17 Thread Richard Levitte
I think 16k was enough to demonstrate that the timing difference becomes more marginal the larger the amount of data to encrypt in the same session is. This makes me think that we might want to rethink the reset functions, i.e. the likes of EVP_CIPHER_CTX_reset()... could we change that function

Re: PKEY CMAC timings

2020-06-18 Thread Richard Levitte
On Thu, 18 Jun 2020 08:27:13 +0200, Richard Levitte wrote: > > I think 16k was enough to demonstrate that the timing difference > becomes more marginal the larger the amount of data to encrypt in the > same session is. > > This makes me think that we might want to rethink the reset functions, > i

Re: PKEY CMAC timings

2020-06-18 Thread Dr Paul Dale
I honestly believe that the various contexts should be reusable. Without this, the recent provider additions will impose a significant overhead. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 18 Jun 2020, at 4:27 pm, Ri

Re: PKEY CMAC timings

2020-06-18 Thread Hal Murray
In the context of making things go fast/clean, do I need a reset? If so, why? My straw man is that setup has 3 stages: 1: get storage and whatever for the cipher 2: setup tables and such for a key 3: init internal data In the same key case, the basic operation is Init (does step 3) Upd

Re: PKEY CMAC timings

2020-06-18 Thread Richard Levitte
On Thu, 18 Jun 2020 09:25:43 +0200, Hal Murray wrote: > > In the context of making things go fast/clean, do I need a reset? If so, why? No. I sent another message where I pointed out that I made a mistake when saying so. -- Richard Levitte levi...@openssl.org OpenSSL Project