Re: Recommendations GnuPG-2 replacement

[Solar Designer <solar () openwall com>]

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?

> 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

Of course, it's best to use GnuPG in an environment where side-channels
within the same host would not matter anyway.

Personally, I intend to stay with GnuPG 1 for now.

> "--s2k-count" parameter, which specifies the number of rounds
> of key deriviation function to unlock the private key,

Fun fact: it never actually specified the number of rounds (including
not in RFC 4880), but rather the number of bytes passed through SHA-1:

http://www.openwall.com/lists/john-dev/2015/04/12/7

As I wrote there:

"I think GnuPG documentation is wrong, and should be revised.  Both
texinfo and man.  Would you care to report this to GnuPG, perhaps along
with a documentation patch?"

but I think we never reported it to GnuPG.  So please feel free.  Also,
I think the man page is generated from the texinfo source, so would not
need to be revised separately.

> 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.

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.

> 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.

On Thu, Dec 07, 2017 at 03:15:06PM +0000, Jeremy Stanley wrote:
> Sounds like my use case is likely not your use case, so perhaps you
> should look at the signify utility OpenBSD developed for this
> purpose instead? It's included in Debian since Stretch under the
> package name "signify-openbsd" and seems to work well; I've used it
> semi-regularly as I tend to do a lot of cross-platform things in a
> mixed Debian/OpenBSD environment.

There's also asignify:

https://github.com/vstakhov/asignify

Alexander