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
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ