gpg-agent cache keygrip

[Peter Lebbing]

On 27/07/17 13:27, MFPA wrote:
> I guess I should have trimmed my quote less severely. Using a password
> manager would enable somebody who says they cannot remember multiple
> decent-quality unique passwords to not share passwords between
> different keys.

Ah yes :-). I agree.

> The single point of failure stops being a passphrase used across
> multiple keys; it becomes the password required to open the password
> manager that protects the multiple passphrases.

Let's look at multiple cases of passphrase reuse:

1) Using the same passphrase for multiple remote systems

If one of the remote systems is compromised, all your accounts with the
same passphrase are compromised. Sounds to me like a bad idea. There are
many different actors and implementations. All it takes is one bad apple.

2) Using the same passphrase in multiple different programs on your own
computer.

When an attacker can compromise one of the programs, but only that, the
attacker still gains access to the encrypted data held in multiple
programs, even if the others are safe by themselves. Possible ways of
compromise that spring to mind are some way to access a running program
remotely, such as by feeding it crafted data exploiting a vulnerability
in the program, or by the fact that data at rest is not well encrypted,
using a file from a backup the attacker gained access to.

3) Using the same passphrase for multiple instances of data in the same
program.

If an attacker is able to compromise one instance, why couldn't they do
another? You might be lucky if it is an attack that requires a running
computer and the attacker only manages to entice the program once. If it
is an attack at data at rest, at poor encryption of the file, then the
workload increases a mere factor two. If they need five days to crack
the encryption of one instance, they only need yet another five days to
crack the other even if the passphrases were different.

For case 3), I'd say it is sheer luck if an attacker only learns one
passphrase rather than the multiple passphrases you use with the same
program. It's not a significant increase in security.

This way of reasoning gets you quite far. It's not completely
conclusive; for one, it depends on all instances being treated the same
way, i.e., all secret keys are stored on the same system /and/ in the
same backups. And suppose some form of key derivation can be cracked
quicker if there are multiple derivations of the same data and salting
is somehow compromised. Then it would be a bad idea to reuse a
passphrase for multiple instances, but I'd say that key derivation or
the random number generator involved is bad anyway and shouldn't be used
at all, even when you don't reuse passphrases. And there are probably a
few different scenarios where you might make yourself weaker.

But personally, without further details convincing me otherwise, I would
not be overly worried about using the same key for multiple instances in
the same program on the same system.

Furthermore, I'd say that the way GnuPG uses a passphrase is safe and an
encrypted private key file doesn't help an attacker to gain access to
the same passphrase in a different program.

Now let's get on to a passphrase manager and GnuPG specifically. A
different way to look at it is this: would you use GnuPG to protect your
passphrase manager? This is actually a feature request I've seen
multiple times: please provide a way to use my OpenPGP key to unlock my
passphrase manager. In that way, the security of the passphrase manager
is utterly dependent on the security of GnuPG. Crack GnuPG, and the
passphrase manager falls immediately as well.

Now there is one avenue left: would we mind if the security of GnuPG is
utterly dependent on the security of the passphrase manager? If you
propose to store the GnuPG passphrases in the passphrase manager,
apparently you're okay with that as well. Crack the passphrase manager,
and GnuPG has no further protections.

Okay, so let's say we don't mind if the security of GnuPG utterly
depends on the security of the passphrase manager, *or* vice versa.
Furthermore, I state pretty confidently that the way GnuPG uses
passphrases does not cause an interaction with other data being
encrypted with the same passphrase in a different program; there is no
way to crack some other piece of data, say your passphrase manager
database, quicker because you have access to the *encrypted* private
keys of GnuPG. Conversely, there is no way to crack an encrypted private
key in GnuPG quicker because some other key derivation function is used
with the same passphrase (other than to crack that other key derivation
by itself).

Then why don't you just use the same passphrase for your passphrase
manager as for your private keys in GnuPG? Again, this only goes if you
belong to both user groups touched upon: those who would consider it a
good thing if the passphrase manager unlocks with their OpenPGP private
key, and those who would store their GnuPG passphrases in a passphrase
manager.

By the way, to reiterate, merely considering data at rest, I dare to
state that reusing passphrases in GnuPG does not compromise the
encrypted data in any way. If an attacker has access to two encrypted
private keys from GnuPG, encrypted with the same passphrase, they are no
further in cracking it than if they had only the one. Once they do crack
it, they can access both. But the cracking itself is, and remains,
impossible for a good passphrase, no matter how many pieces of data from
GnuPG with the same passphrase the attacker has. That's an important
property of a good key derivation function.

My 2 cents,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170727/d7c17a4e/attachment.sig>