On 18/06/2020 20:18, Kurt Roeckx wrote:
> On Thu, Jun 18, 2020 at 07:24:39PM +0200, Kurt Roeckx wrote:
>>
>> Now that a large fraction of the cost has been found, I can look
>> again to see where the biggest cost in 3.0 comes from now and if we
>> can do something about it.
>
> So a code path
On Thu, Jun 18, 2020 at 07:24:39PM +0200, Kurt Roeckx wrote:
>
> Now that a large fraction of the cost has been found, I can look
> again to see where the biggest cost in 3.0 comes from now and if we
> can do something about it.
So a code path that I've noticed before when looking at the
profile
On Thu, Jun 18, 2020 at 02:12:56PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> 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.
Note that I
On 6/18/20, 12:46, "openssl-users on behalf of Kurt Roeckx"
wrote:
On Thu, Jun 18, 2020 at 10:41:40AM +0200, Tomas Mraz wrote:
>> > I question the default behaviour, I think most people don't need
>> > that support.
>>
>> Unfortunately that would be an API break that could
On Thu, Jun 18, 2020 at 10:41:40AM +0200, Tomas Mraz wrote:
> > 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.
But I think the
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"
wrote:
On Wed, 2020-06-17 at
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
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:
> > levi...@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
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)
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,
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 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
> 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
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
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.
Thanks.
> 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.
I saw that, but couldn't figure out
On Wed, Jun 17, 2020 at 03:50:05AM -0700, Hal Murray wrote:
> levi...@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
Thanks.
levi...@openssl.org said:
> Quick forst answer, EVP_MAC_CTX is a typedef of struct evp_mac_ctx_st, which
> you find in crypto/evp/evp_local.h. It's quite small (smaller than
> EVP_MD_CTX and EVP_PKEY_CTX):
How much space does the crypto stuff take? The idea is to do all of the setup
levi...@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
Quick forst answer, EVP_MAC_CTX is a typedef of struct evp_mac_ctx_st,
which you find in crypto/evp/evp_local.h. It's quite small (smaller
than EVP_MD_CTX and EVP_PKEY_CTX):
struct evp_mac_ctx_st {
EVP_MAC *meth; /* Method structure */
void *data;
In general, things have slowed down.
The new EVP_MAC code takes 3 times as long as the old CMAC code on 1.1.1.
The new PKEY code takes twice as long as the old CMAC code on 1.1.1
The one ray of hope is that the API for EVP_MAC has split the part of the
setup that uses the key out of the init
21 matches
Mail list logo
