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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ