[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 18 Dec 2017 10:58:43 -0500
From: Daniel Kahn Gillmor <dkg@...thhorseman.net>
To: halfdog <me@...fdog.net>, oss-security@...ts.openwall.com
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
directly.
* 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
gnupg-devel@...pg.org, 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 http://www.openwall.com/signatures/ 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,
--dkg
Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
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.
