PKEY CMAC timings

[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, Richard Levitte <levitte at openssl.org> 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.e. the likes of EVP_CIPHER_CTX_reset()...  could we change that
> function to become a call down to provider code?  We do allow that for
> the non-provider back-ends, they can implement a 'cleanup' function.
> Right now, EVP_CIPHER_CTX_reset() just calls the provider's function
> to free its operation context, which forces us to re-initialize
> everything with a restarted session, i.e. pass the key anew, etc etc
> etc.
> 
> Cheers,
> Richard
> 
> On Thu, 18 Jun 2020 06:50:45 +0200,
> Hal Murray wrote:
>> 
>>> 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.
> pp> 
>> 1.1.1g
>>     AES-128  16 48 16    225   0.225  475ac1c053379e7dbd4ce80b87d2178e
>>     AES-128  16 1024 16   1682   1.682  159d6d5c13f35d37c72efc5f6dbf40ad
>>     AES-128  16 16384 16  24566  24.566  581f7b133ad6f3697f33c3f836fdb6e6
>> 
>> 3.0.0 alpha3
>>     AES-128  16 48 16    496   0.496  475ac1c053379e7dbd4ce80b87d2178e
>>     AES-128  16 1024 16   1953   1.953  159d6d5c13f35d37c72efc5f6dbf40ad
>>     AES-128  16 16384 16  24820  24.820  581f7b133ad6f3697f33c3f836fdb6e6
>> 
>> -----------
>> 
>> 3.0.0 alpha3:
>> CMAC
>>     AES-128  16 16384 16  25270  25.270  581f7b133ad6f3697f33c3f836fdb6e6
>> PKEY
>>     AES-128  16 16384 16  24839  24.839  581f7b133ad6f3697f33c3f836fdb6e6
>> EVP_MAC
>>     AES-128  16 16384 16  25462  25.462  581f7b133ad6f3697f33c3f836fdb6e6
>> EVP_MAC with Preload cipher and key
>>     AES-128  16 16384 16  24567  24.567  581f7b133ad6f3697f33c3f836fdb6e6
>> 
>> 
>> 
>> -- 
>> These are my opinions.  I hate spam.
>> 
>> 
>> 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200618/5171372c/attachment.html>