Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 7 Dec 2017 23:53:32 +0100
From: Solar Designer <>
Subject: Re: Recommendations GnuPG-2 replacement

On Thu, Dec 07, 2017 at 10:01:34PM +0100, Solar Designer wrote:
> On Thu, Dec 07, 2017 at 06:32:11AM +0000, halfdog wrote:
> > Thus the Debian switch from gpg1 to gpg2 just introduced efforts
> > fiddling with functionality I do not need and cannot disable,
> > provides a keymanagement that cannot be configured easily to
> > protect against the threats it should mitigate (theft of key material)
> > and creating additional attack surface without any recognizable
> > benefit.
> I think the benefit is being on a version upstream intends to maintain
> to a greater extent and for a longer time.  For example, when yet
> another side-channel leak was reported against GnuPG 1 & 2 recently,
> upstream officially patched it for GnuPG 2 only and said that GnuPG 1
> probably contains many other side-channel leaks anyway:

Turns out upstream shortly released GnuPG 1.4.22 fixing this.  It's good
news, which I had missed.

Noteworthy changes in version 1.4.22 (2017-07-19)

 * Mitigate a flush+reload side-channel attack on RSA secret keys
   dubbed "Sliding right into disaster".  For details see
   <>.  [CVE-2017-7526]

 * Fix some minor bugs.

> Are you saying "--s2k-count" option to "gpg2" is ignored, and moreover
> that this is documented?  gnupg-2.1.23/doc/gpg.texi says (formatted):
> `--s2k-count `n''
>      Specify how many times the passphrase mangling is repeated.  This
>      value may range between 1024 and 65011712 inclusive.  The default
>      is inquired from gpg-agent.  Note that not all values in the
>      1024-65011712 range are legal and if an illegal value is selected,
>      GnuPG will round up to the nearest legal value.  This option is
>      only meaningful if `--s2k-mode' is 3.

I should have looked at GnuPG 2.2.3, but its description of the above
option is the same, and it describes the corresponding option to
gpg-agent as follows:

'--s2k-count N'
     Specify the iteration count used to protect the passphrase.  This
     option can be used to override the auto-calibration done by
     default.  The auto-calibration computes a count which requires
     100ms to mangle a given passphrase.

     To view the actually used iteration count and the milliseconds
     required for an S2K operation use:

          gpg-connect-agent 'GETINFO s2k_count' /bye
          gpg-connect-agent 'GETINFO s2k_time' /bye

     To view the auto-calibrated count use:

          gpg-connect-agent 'GETINFO s2k_count_cal' /bye

Looks sane to me, and this might also answer your question:

> > PS: I do not know, how much the gpg-agent calibration under
> > increased system load reduced the KDF complexity, as I failed
> > to extract the KDF rounds value from the gpg data structures,
> > but the value seems to be at least below 70ms due to total time
> > measurements for gpg-agent (math, interprocess communication,
> > filesystem) to unlock a key on an idle system.


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ