[<prev] [next>] [day] [month] [year] [list]
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
