Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 7 Dec 2017 10:16:44 +0100
To:, halfdog <>
Subject: Re: Recommendations GnuPG-2 replacement


for the gpg scenario on initrd I use:
echo $PASSWORD |/bin/gpg -d --passphrase-fd 0 --lock-never
--no-auto-check-trustdb --no-tty -q --no-keyring --batch --yes
--no-permission-warning /etc/a_key.gpg

To fix the "--s2k-count" problem I've added argon2 before using the pipe
for gpg.

Its not great but it works for me.



On 12/07/2017 07:32 AM, halfdog wrote:
> Hello list,
> Are there recommendations for open-source light-weight replacements
> of GnuPG2 suitable for use on Debian? I would like discontinue
> using GnuPG project, as the GnuPG design regarding security seems
> to be moving in a direction, that does not match my personal security
> needs any more.
> The two main events causing me considering the change were related
> to the Debian Jessie to Stretch switch - thus giving a small
> impression on the current needs:
> Event 1:
> While gpg1 was a light-weight tool, just doing what said, the
> new gpg2 cannot really work without gpg-agent, pinentry frontend.
> Both are very nice for desktop usecases. As I also used it during
> machine setup for generating material related to disk encryption,
> the agent first did not want to start -- the primitive /dev/ttyX
> via openvt was not the environment gpg tools were expecting
> for password input, thus failing. gpg2 by default will not ask
> the passphrase any more on the terminal, it was started from,
> but tries to work out using various information, where passphrase
> input should be delegated to.
> 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. This is also more annoying as it is not possible
> to instruct gpg, that a single private key should NOT be cached,
> and you have to configure gpg-agent beforehand, something not
> quite funny and little error prone on limited functionality systems
> like on an initrd systems.
> 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.
> Event 2:
> After getting everything working, which was little anoying as
> building of initrds, testing via QEmu is not very user friendly
> regarding debugging for less experienced users - but at least not
> GnuPG's fault at any reason - I noticed, that the password protection
> of the key was significantly lower than expected. Getting back
> to the developers, we found out, that the specification of the
> "--s2k-count" parameter, which specifies the number of rounds
> of key deriviation function to unlock the private key, 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.
> 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 had the impression, that it did not come to mind, that someone
> might have used such a parameter for a reason, e.g. because speed
> calibration might not be the best idea, while the system is taking
> in data at the maximum speed the ethernet adapter, disk controller
> can do during system setup.
> Another bonmot on the mathematical complexity of private key
> unlocking: "For user experience 100ms is a good value; your
> suggested 1000ms is an annoying long delay which would most user
> only increase the cache time." But the discussion was not on
> user defaults. If I deem it a good idea to requirea longer KDF
> computation time for material with higher sensitivity, e.g. to
> to unlock data storage once at startup, and therefore tell the
> software to perform that computation, it should accept that
> decision. Thus someone not understanding or accepting the
> existance of such choices in alternative usecase might not be
> the right person to develop the software, I want to use.
> Result:
> For all steps regarding system startup, I switched to LUKS only,
> using detached headers for special features. For release signing,
> mail sign/encrypt, a good light-weight solution is still needed.
> hd
> 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