Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 14 Dec 2017 06:18:23 +0000
From: halfdog <me@...fdog.net>
To: oss-security@...chelkaktus.net
cc: oss-security@...ts.openwall.com
Subject: Re: Recommendations GnuPG-2 replacement

Hi,

> 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

Yes, that is quite similar to my use, only the "echo" is missing -
but taking into account your knowledge about KDFs, I guess you
have it just in here for demonstration purposes, knowing the security
implications.

> To fix the "--s2k-count" problem I've added argon2 before using the pipe
> for gpg.
>
> Its not great but it works for me.

Thanks for the hint. "argon2" seems to be what, what I'm looking
for. This solves the issues also in a more "UNIX-like" way, as
it can be combined with any, where high-cost KDFs are wanted.

hd

PS: sorry about the delayed reply: when in bad mood I just do
not manage to open my mailbox for weeks or month.

> 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