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).
|8 months ago|
|.gitignore||8 months ago|
|LICENSE||8 months ago|
|README.md||8 months ago|
|gocrypt.bash||8 months ago|
|pass-test||8 months ago|
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.
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
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
tomb. Furthermore, the
all-or-nothing approach renders the entire password store unusable on mobile clients of
pass (again, at least without compromising
pass-gocrypt, only a subtree of the password store will be encrypted. This encryption is done transparently with
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
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
generate) have to be prefixed by the
to ensure compatibility when the outer password store is a git repository. Without the prefix, git commits that are normally created
pass will not be generated during a write. See the Usage section of this document for examples.
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
pass to load the extension.
Alternatively, the extension can be installed to the system extension directory in
pass gocrypt help after installation for detailed help. Below is a simple example of using
pass-gocrypt to encrypt
a subset of your passwords.
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.