Date: Thu, 07 Dec 2017 06:32:11 +0000 From: halfdog <me@...fdog.net> To: oss-security@...ts.openwall.com Subject: Recommendations GnuPG-2 replacement 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