pass-gocrypt/README.md
Peter Cai b014a9a440 Concatenate the symmetric keys instead of using HMAC-SHA256
There is no point trying to KDF here. Gocryptfs does its own KDF anyway
(https://nuetzlich.net/gocryptfs/forward_mode_crypto/), and a leaked
gocryptfs password is not really in our security model (because that
compromises the entire storage in any case).
2022-10-10 20:13:52 -04:00

4.4 KiB

pass-gocrypt

An extension for pass that hides part of the password files inside a subdirectory encrypted by gocryptfs.

pass-gocrypt serves a somewhat similar purpose as pass-coffin and pass-tomb -- because pass does not encrypt the directory structure (metadata) by default, anyone who has access to the password store is able to deduce what websites / services does the owner have accounts on. Both pass-coffin and pass-tomb provide workarounds to this limitation by placing the entire password store inside an encrypted format when unused, shielding metadata from offline attacks.

This approach, in general, works perfectly fine, but comes with some shortcomings that, in the author's view, defeat the point of using pass. For example, when a password store is locked inside a coffin or a tomb, you lose the ability to synchronize the store using git, at least not without seriously compromising the security model of coffin and tomb. Furthermore, the all-or-nothing approach renders the entire password store unusable on mobile clients of pass (again, at least without compromising coffin and tomb themselves).

In pass-gocrypt, only a subtree of the password store will be encrypted. This encryption is done transparently with gocryptfs, with a password generated and managed by pass itself. You can optionally supply another passphrase when initializing this extension, which will be used along with the one managed by pass to derive the symmetric encryption key used by gocryptfs.

When the encrypted subtree is unlocked, it simply appears as a subdirectory of the original password store (gocrypt/), and all read operations from pass, including from web browser plugins, can be done without any special care (other than remembering to unlock the subtree first). The encrypted subdirectory is stored in the original password store under .gocrypt/, and can be managed by git just like how it was without encryption.

The biggest caveat of this is that write operations (such as edit and generate) have to be prefixed by the gocrypt subcommand to ensure compatibility when the outer password store is a git repository. Without the prefix, git commits that are normally created automatically by pass will not be generated during a write. See the Usage section of this document for examples.

Installation

This extension is consisted of only one script, gocrypt.bash, and can be simply copied into the .extensions folder inside your password store to be installed. You will need PASSWORD_STORE_ENABLE_EXTENSIONS to be set to true for pass to load the extension.

Alternatively, the extension can be installed to the system extension directory in /usr/lib/password-store/extensions.

Dependencies:

  • pass
  • bash
  • gocryptfs

Usage

Please run pass gocrypt help after installation for detailed help. Below is a simple example of using pass-gocrypt to encrypt a subset of your passwords.

To initialize:

pass gocrypt init
# With extra passphrase:
# pass gocrypt init -p

To generate a password inside the encrypted subdirectory:

pass gocrypt generate "My/Password"

To view a password from inside the encrypted subdirectory:

pass gocrypt show "My/Password"
# or simply: pass show "gocrypt/My/Password"
# or from any other pass-compatible GUI, when the subdirectory is opened

To move a password from outside of the encrypted subdirectory to inside:

pass gocrypt crypt "My/Insecure Password"

To close (unmount) the encrypted subdirectory:

pass gocrypt close

To re-open (mount) the encrypted subdirectory:

pass gocrypt open

To make the encrypted subtree a git repository of its own:

pass gocrypt git init

Note: This will allow changes inside the subdirectory to be recorded separately from the git repo of the outside password store. This has the benefit of retaining the unencrypted changelog once the subdirectory is opened (decrypted). The git log of the outside password store will still contain the encrypted form of the full inner repository, and the inner repository does not need to be synchronized separately. This is not a recommended mode of operation, but some users may prefer to do this to retain a full human-readable history of the encrypted part of their password store.