Protect .gpg-id

[Kjetil Torgrim Homme]

Den 07. des. 2016 17:52, Emile Cantin skreiv:
> As Brian said, in that particular case, I think Alice and Bob should use
> a repo where Eve doesn't have access, or at least write access.
> 
> I think the key here is that 'pass init' reads and re-encrypts
> everything with the new key(s), but Eve didn't actually use 'pass init'
> but did it manually (because she can't read the files). This leads to a
> situation where files in the directory are encrypted with a different
> set of keys than the ones present in .gpg-id, which might be detectable.
> Perhaps we can try to detect that kind of situation and throw a big
> nasty warning in these cases?

Alice and/or Bob must have Eve's public key in their keyrings in order
to encrypt to her key.  the addition of her key can be done
automatically by an eager e-mail client (quite common, in fact), but GPG
will still require Eve's key to be trusted, directly or indirectly.  Eve
might be able to trick others which Alice/Bob trust transitively into
trusting her key, though.

so here are some possible mitigations:

1) PASSWORD_STORE_GPG_OPTS="--trust-model direct"

this means each and every key in .gpg-id must be trusted explicitly and
individually by Alice and Bob before it is used to encrypt to that
recipient.

2) use a separate keyring for pass use, so that your e-mail client
doesn't mess around with pass keys.

  PASSWORD_STORE_GPG_OPTS="--keyring password-store.gpg"

you can even combine the two if you like.

-- 
Kjetil T. Homme
Redpill Linpro - Changing the game

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20161219/dd9c1d4a/attachment.asc>