[FR] Fully encrypted secret store (hiding secret names as well)

[KayLeung]

When you execute gopass, it shows the whole secrets tree. Can I make it fully-encrypted?

[AnomalRoil]

This is something we are trying to address already, yes. https://github.com/gopasspw/gopass/issues/673

@dominikschulz currently I'm not sure how it works and if it does encrypt the secret paths and then how/when you can see them unencrypted? Is this specified/documented somewhere? But I believe it is not yet fully implemented.

Maybe we should reopen #673 ?

[dominikschulz]

I've started to document this backend at https://github.com/gopasspw/gopass/blob/master/docs/backends/ondisk.md. But TBH a lot is missing there, e.g. how to use it. Not sure if we need to reopen #673, but we need to improve that document if we want users to be able to figure out how to use that backend.

Be warned, however, that this backend currently requires you to use age - at least for the index. And it's not more than a proof of concept. The disk layout and feature set will change over time.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dominikschulz]

The old ondisk backend has long been deemed infeasible and dropped. But I keep thinking about this and currently toying around with two ideas:

• Adding a badger based backend, that can be fully encrypted. There a challenge would be how to sync. We could toss the output into git but that'd be awkward.
• Adding a backend that uses files like the current gitfs backend but encrypting everything (e.g. filenames, commit messages) using the crypto provider (gpg or age). That would work with git but we'd likely need an additional mapping from encrypted file names to real file names. Also it would still leak some amount of meta data (e.g. filesizes, timestamps). But that's impossible to avoid with git anyway.

With the current requirements (i.e. most users seem to want to use gpg+git) it's very hard to come up with a useful fully encrypted backend.

[dertuxmalwieder]

With the current requirements (i.e. most users seem to want to use gpg+git)

Just for completeness’s sake: I want to use Fossil and would like to not rely on my GPG keys.

[dominikschulz]

@dertuxmalwieder Did you try the fossil backend with age?

[dertuxmalwieder]

I still plan to.

[dominikschulz]

https://github.com/aegistudio/enigma might be an option, too.

[dertuxmalwieder]

Probably overkill though, at least when using FUSE.

[dominikschulz]

https://rot256.dev/post/pass/ provides some more good reasoning why a fully encrypted backend might be a good idea.

[dominikschulz]

I'd like to try an kdbx based backend some day. That might hit a sweet spot for some people and it should be compatible with KeepassX 2.30+ at the same time. The UX would be sub-par, but some of the concerns could be addressed.

Let's see if/how we can make this work nicely.

[dertuxmalwieder]

That would probably make it harder to support version control though. KeePass database files are not incremental.

[Crown0815]

• Adding a backend that uses files like the current gitfs backend but encrypting everything (e.g. filenames, commit messages) using the crypto provider (gpg or age). That would work with git but we'd likely need an additional mapping from encrypted file names to real file names. Also it would still leak some amount of meta data (e.g. filesizes, timestamps). But that's impossible to avoid with git anyway.

For me, the main charm of gopass is the ability to store my passwords in git since I work a lot with git and virtually store everything there.

Some ideas to obfuscate the file sizes and timestamps:

• Filesizes could potentially be hidden by creating random padding on the contents of individual files. The length of that padding could be stored in the file providing the "mapping".
• The timestamps could be hidden to a certain degree by having each modification going along with the contents of two files being swapped (and again randomizing their padding)

This way:

• Any change would leave most files unchanged
• It would not be possible to directly extract information from file sizes and timestamps

I am not an expert (or even a novice) when it comes to cryptography, so I am aware that those ideas are likely naive. But I think by putting obfuscation information into the encrypted "mapping" file, it might be possible to provide additional security to the individual files. Maybe something along the lines of salting password hashes.