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.