thoughts about encrypting the paths / names in the tree

[J Rt]

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 erayd.net> 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 gmail.com> 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:
>> https://gitlab.com/roddhjav/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