[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <0ac49cb5-f257-f6c2-d104-7110ecf463d2@stachelkaktus.net>
Date: Thu, 7 Dec 2017 10:16:44 +0100
From: oss-security@...chelkaktus.net
To: oss-security@...ts.openwall.com, halfdog <me@...fdog.net>
Subject: Re: Recommendations GnuPG-2 replacement
Hello,
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.
cheers
wof
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
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.
