thoughts about encrypting the paths / names in the tree

J Rt jean.rblt at
Mon May 11 17:21:59 CEST 2020

Thanks for your message :) I agree that some form of encrypted
filesystem makes it much simpler, and this is more or less what
pass-tomb does, right? The problem then is that this confuses for
example git synchronization, in addition to adding a big monolithic
pass tomb, that may either be far too big or need resizing if it grows
too much. Also, in a sense, relying on an encrypted filesystem means
that you have a lot of software under your feet, in a sense it is more
self-contained to just use a few gpg tricks - this argument may be a
bad / weak one though.

I also wonder if it would be nice to have this functionality
integrated in the 'core' pass. It is a bit annoying with pass-tomb,
this means yet-another-package to install, there are several repos on
github that claim to be pass-tomb so that is confusing, etc. I also
agree that this is a weak argument though.

On Mon, May 11, 2020 at 4:27 PM Steve Gilberd <steve at> wrote:
> This feels very, very out of scope for Pass.
> There are many ways to create an encrypted filesystem - why not simply use whichever one of those the user prefers, if this is actually functionality they want?
> Cheers,
> Steve
> On Tue, 12 May 2020, 01:19 J Rt, <jean.rblt at> wrote:
>> 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
>> characters.
>> 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
>> it.
>> - 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
>> Cheers,
>> JRT

More information about the Password-Store mailing list