Support for multiple (independently revocable) keys for the same encrypted data

[dumblob]

Hi, I'm coming here from the feature comparison table on https://wiki.archlinux.org/title/Data-at-rest_encryption#Comparison_table and would like to ask about the "Support for multiple (independently revocable) keys for the same encrypted data".

Does gocryptfs support it? If so, what are the downsides (if any) of the implementation? If not, would it be possible to implement it?

[rfjakob]

You mean that there should be multiple passwords that can unlock the filesystem?

This is possible by creating multiple copies of gocryptfs.conf, let's call them gocryptfs.conf.user1 and gocryptfs.conf.user2. Then, you do

gocryptfs -passwd -config cipherdir/gocryptfs.conf.user1
gocryptfs -passwd -config cipherdir/gocryptfs.conf.user2

to set the passwords you want.

Revoking is problematic, though. To "revoke" user1, you would delete gocryptfs.conf.user1. BUT: the user could have made a private copy of gocryptfs.conf.user1, so this is not bulletproof.

[dumblob]

Revoking is problematic, though. To "revoke" user1, you would delete gocryptfs.conf.user1. BUT: the user could have made a private copy of gocryptfs.conf.user1, so this is not bulletproof.

Oh, sorry for not being clear about this. Yes, my actual use case is to create & revoke chosen users' access at arbitrary time points. Basically this is to allow access to multiple persons without sharing one password up front (i.e. with fully independent access life cycle without side effects).

Do you think this is a useful feature?

It's also about eliminating single point of failure - ensuring a group of people will not lose access to the given data.

[yahesh]

In order for this to be a useful feature, one would have to re-encrypt all encrypted files once a user's access is revoked and the user hasn't created a local copy of the files. Otherwise, as already mentioned by @rfjakob, a user could just use a backed-up copy of their config file. Furthermore, a user could extract the master encryption key when they still have normal access to the files which would allow them to decrypt the files as long as they have access to them.

[rfjakob]

Agreed @yahesh , I also think this cannot work.

[dumblob]

Thank you for the insights. It seems this functionality would be tied to RTC with "blockchain-like" assurance to guarantee inability to "go back".