I think that the default behavior should change for 3.0, and the API change described in the Release Notes. I find that alternative less impacting that this silent sudden performance deterioration.
On 6/18/20, 04:42, "openssl-users on behalf of Tomas Mraz" <openssl-users-bounces@xxxxxxxxxxx on behalf of tmraz@xxxxxxxxxx> wrote:
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.]
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
