Date: Sun, 17 Dec 2017 09:06:08 +0000 From: halfdog <me@...fdog.net> To: oss-security@...ts.openwall.com Subject: Re: Recommendations GnuPG-2 replacement Solar Designer writes: > On Thu, Dec 07, 2017 at 06:32:11AM +0000, halfdog wrote: > > After getting gpg and agent running, I noticed, that not reliably > > stopping the gpg-agent on initrd would introduce a private key > > data leak via /proc from early boot process to running system > > when stopping fails. > > Can you elaborate on this, please? As the agent process stays alive and initrd PID namespace is the same as final init-process PID namespace, the agent will stay via /proc and traceable by root using PTRACE. > > 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: ... > > Personally, I intend to stay with GnuPG 1 for now. As Debian marked the packages with "gnupg1 - GNU privacy guard - a PGP implementation (deprecated "classic" version)" I wanted to anticipate the changes now, giving me more time to evaluate the changes and to find alternatives when needed. Apart from that, I am also inclined to switching, when statements from open-source community seem to indicate, that the burden to maintain both versions in a LTS scheme might be too much to carry. They should have their hands free for doing good work on the latest version, leaving the LTS procedures to payed service providers, I do not use privately. > ... > > has changed > > from gpgv1 to gpgv2, so that it is ignored in gpg2 but does not > > cause any warning or error. Thus previous audited procedures continue > > to work but do not produce the same results any more. Of course, > > I could have compared documentation of all parameters of (at least > > security-related) programs after Jessie to Stretch upgrade, but > > I assumed, that security critical parameters would not change > > their meaning without any noticable effect - so just my fault. > > 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. Here is the gpgv2 documentation: " --s2k-count n Specify how many times the passphrases mangling for symmetric encryption 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 set to the default of 3." You noticed the additional "symmetric" word? According to GPG developer that means, that with gpgv2 this setting is only applied with symmetric schemes, e.g. the "--symmetric" mode of GPG. For assymetric mode the parameter is just ignored. > This doesn't say the option is ignored - only that "the default is > inquired from gpg-agent." Is the option in fact ignored? That would be > a bug in either code or documentation. > > > Still, this would just be a minor mishap, but what reduced my > > trust in GPG, was the comment of a developer: it was assumed, > > that they know better, where there software will be run without > > specifying that "where" in the documentation. Also his replies > > matched that picture, e.g. "(gpg-agent will) ... calibrate the > > S2K count to match the current machine", assuming that this is > > good reason to change "--s2k-count" meaning and ignore the parameter. > > I see no problem with gpg-agent providing a calibrated default, if that > default can be overridden. If it can't be, and especially if that's in > conflict with the documentation, that's problematic. It is not in conflict with documentation, as the "symmetric" word was added but therefore the parameter's meaning changed quite radically, considering that gpg is a tool used for assymetric encryption mainly. > > 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. > > You may process the private key file with gpg2john, then try to crack it > with john. This will output the actual value, as well as show you the > speed at which passphrases can be tested against that key on your system > and with that version of JtR. To use a GPU, add "--format=gpg-opencl". > Please use latest bleeding-jumbo off GitHub for all of this. Done that, but still fighting how to use "gpg2john" with the new gpgv2 "private-keys-v1.d" key format. Exporting the private keys using gpgv2 does not help as that requires the passphrase already, thus removing the gpgv2-encryption, we want to test. Just FYI: your releases on Openwall are still signed with the old openwall-key, according to http://www.openwall.com/signatures/ the key is "Old Openwall offline signing key (no longer used)". Apart from that, gnupgv2 cannot read it any more anyway. (gpg man page "You only need to use GnuPG 1.x if your platform doesn't support GnuPG 2.x, or you need support for some features that GnuPG 2.x has deprecated, e.g., decrypting data created with PGP-2 keys." > .... hd
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ