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 <[email protected]> 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, <[email protected]> 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
