Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 18 Dec 2017 10:58:43 -0500
From: Daniel Kahn Gillmor <>
To: halfdog <>,
Subject: Re: Recommendations GnuPG-2 replacement

On Sun 2017-12-17 09:06:08 +0000, halfdog wrote:
> Solar Designer writes:
>> On Thu, Dec 07, 2017 at 06:32:11AM +0000, halfdog wrote:
>> > 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.
>> Can you elaborate on this, please?
> As the agent process stays alive and initrd PID namespace is the
> same as final init-process PID namespace, the agent will stay
> via /proc and traceable by root using PTRACE.

I think what you're saying is basically that the key (or its passphrase)
remains in RAM while the agent is running.

This is also true for things like ssh-agent.

Keeping the key in RAM enables convenient, simple reuse -- this is a
security benefit, because it means it is possible to do things like read
a series of encrypted e-mails without entering your password for each
message.  Without this, reading encrypted mail is an extreme nuisance
(esp. at the rate at which some people send and receive mail), and it
encourages people to just revert to cleartext mail in the first place.

>> Personally, I intend to stay with GnuPG 1 for now.
> As Debian marked the packages with "gnupg1 - GNU privacy guard -
> a PGP implementation (deprecated "classic" version)" I wanted to
> anticipate the changes now, giving me more time to evaluate the
> changes and to find alternatives when needed.

Hi!  I'm the person who marked gpg1 "deprecated" in debian.  i consider
it deprecated for several reasons, including:

 * upstream is not devoting much time to it, especially as compared to
   the "modern" branch.  Upstream has (like all of us) limited time and
   energy, and i want to encourage them to stay focused.

 * gpg1 does not support any of the newer cryptographic primitives,
   which people are now starting to use in the wild.  You will not be
   able to verify elliptic-curve signatures, nor will you be able to
   encrypt to people who have encryption-capable keys using ECDH.  gpg1
   will *never* support these primitives.

 * gpg1's network interaction is entirely one-shot, and doesn't make use
   of any cached information, which makes it inefficient (sometimes
   retrying things it just tried and found to be failing).  It also
   lacks convenient "use-tor" options for network access (gpg2's network
   daemon both retains and makes use of cached history about network
   access, and offers use-tor)

 * gpg1 always holds private key material in-process. it can be PTRACE'd
   by the user themselves (not just as root) for full recovery of the
   secret key.  gpg2 never sees the private key material, since it
   delegates that task to the agent.  This process separation means it's
   possible to create gpg-agent backend processes that run in isolated
   namespaces, that hook into hardware, that store keys in the kernel,
   etc.  While these steps haven't been taken yet, they will only be
   possible with gpg2, since gpg1 expects to handle the private keys

 * gpg1 retains and provides backward compatibility for known-broken
   formats, like PGP-2, and will likely never effectively drop them.
   Modern gnupg has taken steps to avoid this, and is intended to be a
   safe tool for users to pick up and use without doing a lot of
   fiddling to turn off the dangerous features.

Alexander, i encourage you to switch to the modern GnuPG suite, and
would be happy to talk with you about any remaining concerns that you
might have.

> Done that, but still fighting how to use "gpg2john" with the new
> gpgv2 "private-keys-v1.d" key format. Exporting the private keys
> using gpgv2 does not help as that requires the passphrase already,
> thus removing the gpgv2-encryption, we want to test.

This is a distinct question, and should probably be broken out from this
thread.  the AES keywrapping used in "private-keys-v1.d" is indeed not
related to OpenPGP.  private-keys-v1.d/ is used to store private keys
for CMS (S/MIME) and SSH, as well as OpenPGP, and it uses a single
common format for encrypting the key (usually -- there's an exception
for recently-imported keys that were ingested in batch mode, which
retain their original wrapping).

the current canonical format is a gcrypt s-expression, where some of the
elements are key-wrapped blobs (noted as "protected-private-key")

The best place to discuss this particular format is on, but note that upstream makes no claims of
stability of this format -- it is strictly internal, not covered by the
public API boundary offered by gpg-agent, so any code that tries to deal
with these files directly may break if there is a gpg-agent upgrade.

> Just FYI: your releases on Openwall are still signed with the old
> openwall-key, according to the
> key is "Old Openwall offline signing key (no longer used)". Apart
> from that, gnupgv2 cannot read it any more anyway. (gpg man page
> "You only need  to  use  GnuPG  1.x  if  your  platform
> doesn't  support  GnuPG 2.x, or you need support for some features that
> GnuPG 2.x has deprecated, e.g.,  decrypting  data  created  with  PGP-2
> keys."

Please, please please stop using PGP-2 keys.  It's about to be 2018,
let's use a format with reasonable defaults, plausibly functional
fingerprints and digest algorithms, and keys that were generated in this
decade :)

All the best,


Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)

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.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.