CMAC timings

[Blumenthal, Uri - 0553 - MITLL]

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 at openssl.org on behalf of tmraz at redhat.com> 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 at openssl.org 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.]


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200618/6ff92ba8/attachment-0001.bin>