thoughts about encrypting the paths / names in the tree

J Rt jean.rblt at
Mon May 11 15:17:22 CEST 2020

Dear all,

As is well known, there is arguably a slight issue with the current
way the password store is saved, namely, that the folders / names
under which the passwords are stored are not encrypted, which means
that an attacker can know which services are used / for which services
one has an account.

There is currently a solution for that thanks to pass-tomb: . However, this has problems of
its own, like, tomb size must be chosen at creation and may be
overkill at first / too little after a while, bad integration with git
tracking and backup on remotes, etc. In addition, why not have a
hiding of the saved entries names by default (i.e. secure as much as
possible by default)?

Therefore I was wondering: would it not be possible to somehow use the
same master gpg key to also encrypt the names of the stored items in
pass-store, and use the key once at the 'store opening' to decode
these names? Could this provide both the added security that is
provided currently by pass-tomb, but with still the convenience of git
integration etc? In addition, would it be possible to decrypt all the
paths / names with only 1 call to the master gpg key, so that people
using a smart card do not need to wait for a long time?

The following may be very naive, but would something like this be a solution?

- a pair of public / encrypted private keys is stored at the root of
the store. This pair of keys is the 'name hiding' pair. The encrypted
private key is encrypted using the master gpg key.

- all paths / names in the store are replaced with the 32 first
characters (base64-encoded) of their encryption by the 'name hiding'
key. In addition, the fully encrypted path / name is stored at the
same location, with the name_hiding_ prefix before the same 32 first

Regarding functionality:

- When calling `pass open`

- 1) a RAM drive of the right size (let us say typically 2 x size of
the .password-store folder) is created, after that all happens inside

- 2) the 'name hiding' private key is decrypted using the master key
(1 call to it for decryption, so 1 potential call to a slow
smartcard), loaded, made ready for use, etc.

- 3) the paths / names, contained in the name_hiding_ prefixed files,
are decrypted using the 'name hiding' key.

- 4) the decrypted names are used to replace the 32 base64-encoded hidden names

- 5) at this stage, we are back to having a perfectly normal password
store on the RAM drive

- When calling `pass close`, the RAM disk is destroyed

- When calling commands that only read from the pass store, this reads
from the RAM drive

- When calling commands that perform modifications to the password
store, the hiding is performed in the RAM disk, and then copied to the
'name hidden' folder (with previous encryption etc).

- The git commands are only applying on the 'name encrypted' store



More information about the Password-Store mailing list