[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171207225332.GA9059@openwall.com>
Date: Thu, 7 Dec 2017 23:53:32 +0100
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
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:
>
> http://openwall.com/lists/oss-security/2017/07/06/8
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
<https://eprint.iacr.org/2017/627>. [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.
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
