Mailing List Archive

Performance regression for gnupg v2 keys
Hi,

I have older keys and newer keys that behave quite different in the
decryption performance.

Old keys: Generated with gnupg-1.4.x, rsa2048, at 2017-01-10.
New keys: Generated with gnupg-2.2.8, rsa2048, some weeks ago.

I've always been using the defaults for generating the keys (no
--full-gen-key, no --expert).

Test case: Unfortunatelly a bit complicated. It is postgresql's
pg_pub_decrypt() that performs approx. 10x slower when the keys,
generated by gnupg and being passed to postgresql as a binary
string, are generated with gnupg-2.2.8. Postgresql is using gnupg
internally.

My questions here:

(1)
If the issue is caused by the keys: Do I have the chance to compare
old/new key internals? I've diff'ed the output of gpg -ivv ... of
both keys and AFAIK only the default digest algo has changed from
SHA1 to SHA256. Not sure here though.

(2)
What would be a suitable test case with gpg only, without postgresql.

Thanks


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Performance regression for gnupg v2 keys [ In reply to ]
fkater:

> Hi,
>
> I have older keys and newer keys that behave quite different in the
> decryption performance.
>
> Old keys: Generated with gnupg-1.4.x, rsa2048, at 2017-01-10.
> New keys: Generated with gnupg-2.2.8, rsa2048, some weeks ago.
>
> I've always been using the defaults for generating the keys (no
> --full-gen-key, no --expert).
>
> Test case: Unfortunatelly a bit complicated. It is postgresql's
> pg_pub_decrypt() that performs approx. 10x slower when the keys,
> generated by gnupg and being passed to postgresql as a binary
> string, are generated with gnupg-2.2.8. Postgresql is using gnupg
> internally.
>
> My questions here:
>
> (1)
> If the issue is caused by the keys: Do I have the chance to compare
> old/new key internals? I've diff'ed the output of gpg -ivv ... of
> both keys and AFAIK only the default digest algo has changed from
> SHA1 to SHA256. Not sure here though.
>
> (2)
> What would be a suitable test case with gpg only, without postgresql.


A little update:

When I change the passphrase of an existing 1.x generated key with
gpg 1.4.x, the key stays ok (fast).

When I change the passphrase of an existing 1.x generated key with
gpg 2.2.8, the key gets somehow updated (slow).

So, besides fast/slow:

What's the difference between default (rsa 2048) keys generated with
1.x and 2.x?

Felix


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Performance regression for gnupg v2 keys [ In reply to ]
On Thu, 20 Sep 2018 15:05, fkater@posteo.net said:

> When I change the passphrase of an existing 1.x generated key with
> gpg 2.2.8, the key gets somehow updated (slow).

So this is not about the key but about the protection of the private
key. That protection (teh passphrase) is there as a failsafe mechanism
in case the private key is leaked without the machine being compromosed
(backup take lost, etc.).

We try to achieve that this decryption process takes about 100ms; that
value can be changed at build time using the configure option
--with-agent-s2k-calibration=MSEC but not at run time. When you change
the passphrase of an old key the first time or when you import it to gpg
the key is re-encrypted so that it takes that long.

In contrast gpg 1.4 uses a fixed value here and does not calibrate it to
the actual machine in use. The outcome is that a gpg 1.4 created/
passphrase changes key has a too weak protection in that a dictionary
attack can be more easily mounted.

It seems that you are doing a lot of operations with that key in a row.
gpg-agent's cache will cache the unprotected key so that the 100ms to
unprotect the key is only spend once during the caching time to live (10
minutes by default). Make sure tha the cache is enabled by checking the
options --max-cache-ttl and default-cache-ttl. Depending on your use
case you may want to work without a passphrase (key protection) at all.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Performance regression for gnupg v2 keys [ In reply to ]
wk:

> We try to achieve that this decryption process takes about 100ms;

Oh, I see...

> When you change the passphrase of an old key the first time or
> when you import it to gpg the key is re-encrypted so that it takes
> that long.

So, the trigger for this delay is then inherent to the re-encrypted
key itself, not primarily dependent on the agent or gnupg library
configuration, correct?

I am asking this detail because

- I need to move the keys to another machine, into a postgresql
database where gnupg seems to be part of postgresql itself
(pgcrypto) and cannot be hand-configured easily, and

- I'd like to know if I have to re-create all existing (slow) keys
after applying --with-agent-s2k-calibration=MSEC to gnupg (on the
machine where the keys are generated).

Please confirm.


> It seems that you are doing a lot of operations with that key in a row.
> gpg-agent's cache will cache the unprotected key so that the 100ms to
> unprotect the key is only spend once during the caching time to live (10
> minutes by default). Make sure tha the cache is enabled by checking the
> options --max-cache-ttl and default-cache-ttl. Depending on your use
> case you may want to work without a passphrase (key protection) at all.

Indeed: We do many decryptions, let me explain in short:

It is postgresql that receives passphrase protected gpg keys
(pgcrypto). Otherwise it couldn't execute SQL queries on encrypted
data. So, I am forced to move the whole decryption work to
postgresql instead of dealing with decryption after the query using
(a clean version of) gnupg. I don't know about postgresql's
internals but it doesn't seem to even run an agent... And just as an
example: A query using gnupg 1.x keys that completes within 3 sec
takes 40 sec with 2.x keys.


> that value can be changed at build time using the configure option
> --with-agent-s2k-calibration=MSEC but not at run time.

This sounds like a suitable solution. I've seen that option here
[1] but it is missing in official gnupg. What do you recommend?

Felix

[1] https://dev.gnupg.org/source/gnupg/browse/master/configure.ac


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Performance regression for gnupg v2 keys [ In reply to ]
Hi,

I permit myself to sum up the open questions:

> that value can be changed at build time using the configure option
> --with-agent-s2k-calibration=MSEC but not at run time.

That option doesn't seem to be present in gnupg configure.ac...?


> When you change the passphrase of an old key the first time or
> when you import it to gpg the key is re-encrypted so that it takes
> that long.

With the above build-time setting applied, do all previously
generated (slow) keys have to be recreated or is this delay gone
with a newly compiled agent/gnupg library?

Thanks
Felix

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users