&gt; the whole thing is encrypted as a blob<p>No, it&#x27;s not.<p>With pass (just to be sure - we&#x27;re talking about zx2c4&#x27;s one, right?), the store contains a bunch of independent gpg-encrypted text files. However, the filenames are not encrypted or obfuscated by any means.<p>This has pros and cons. On the good side, you don&#x27;t have to decrypt anything (which means, actually use your GPG key, which is best kept on an unplugged HSM) to just check if the credential&#x27;s in the store (think auto-fill suggestion). Also, this architecture allows dead-simple (plain rsync or git!) approach for synchronization when there are no entry-level conflicts. On the bad side, anyone who has access to the filenames (local filesystem access or a clone of git repo) can figure out which resources you have credentials for. That&#x27;s the price of the simplicity.<p>I.e. what you see in the very first example at <a href="https:&#x2F;&#x2F;www.passwordstore.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.passwordstore.org&#x2F;</a> in the &quot;Using the password store&quot; section are the actual at-rest filenames. Run `ls -lR ~&#x2F;.password-store` if you don&#x27;t believe me ;)<p>Use of ecryptfs&#x2F;encfs or git-remote-gcrypt was suggested to mitigate this, but those aren&#x27;t perfect. Well, everything depends on the threat scenarios you consider.