Re: CMAC timings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2020-06-17 at 23:02 +0200, Kurt Roeckx wrote:
> On Wed, Jun 17, 2020 at 03:50:05AM -0700, Hal Murray wrote:
> > levitte@xxxxxxxxxxx said:
> > > What does surprise me, though, is that direct EVP_MAC calls would
> > > be slower
> > > than going through the PKEY bridge.  I would very much like to
> > > see your code
> > > to see what's going on. 
> > 
> > Over on an ntpsec list, Kurt Roeckx reported that he was still
> > waiting...
> > 
> > Richard's message said "I", so I sent him a copy off
> > list.  Correcting that...
> 
> So I took a look at at the EVP_PKEY case, and it seems we spend most
> of our time doing:
> - alloc/free. 12 alloc and 16 free calls per signature
> - OPENSSL_cleanse: 10 calls per signature
> - EVP_CIPHER_CTX_reset: 6 calls per signature
> 
> Most of the time is spent in those functions.
> 
> The manpage documents:
> The call to EVP_DigestSignFinal() internally finalizes a
> copy of the digest context. This means that calls to
> EVP_DigestSignUpdate() and EVP_DigestSignFinal() can be called
> later to digest and sign additional data.
> 
> And:
>        EVP_MD_CTX_FLAG_FINALISE
>            Some functions such as EVP_DigestSign only finalise
>            copies of internal contexts so additional data can be
>            included after the finalisation call. This is
>            inefficient if this functionality is not required, and
>            can be disabled with this flag.
> 
> (A reference to the EVP_MD_CTX_set_flags manpage would have been
> useful.)
> 
> So after the EVP_MD_CTX_new(), I added an:
>         EVP_MD_CTX_set_flags(ctx, EVP_MD_CTX_FLAG_FINALISE);
> 
> For me it changed things with 3.0 from:
>      AES-128  16 48
> 16   1696   1.696  475ac1c053379e7dbd4ce80b87d2178e
> to:
>      AES-128  16 48
> 16    754   0.754  475ac1c053379e7dbd4ce80b87d2178e
> 
> While 1.1 gives me this without the change:
>      AES-128  16 48
> 16    739   0.739  475ac1c053379e7dbd4ce80b87d2178e
> and with the change:
>      AES-128  16 48
> 16    291   0.291  475ac1c053379e7dbd4ce80b87d2178e
> 
> I question the default behaviour, I think most people don't need
> that support.

Unfortunately that would be an API break that could be very hard to
discover, so I do not think we can change this even in 3.0.

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





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux