Request for comments: Allow more than one encrypted master key

[aanno]

Hello,

I've hacked a fix to #748. This is not ready for merge. But before putting more work into this, I need some feedback.

So long, gocryptfs only allows one instance of the encrypted master key. (Decryption could be done with a passphrase or by using a (modern) FIDO2 device.)

I hacked the gocryptfs.conf configuration format from v2 to v3. The new format supports (a) several instances of the encrypted master key and (b) several instances of the FIDO2 device details. v2 could be easily converted to v3.

Omissions:

1. No documentation.
2. Around 9% of the tests still fail (mostly tests that rely on the v2 format).
3. No new tests for the new features.

Usage

# init a new crypted fs
gocryptfs -init -user user cipher
# add another user/password instance
gocryptfs -user user -add-user testuser cipher
# use it
gocryptfs -user testuser cipher mnt

# add FIDO2 device
gocryptfs -user testuser -add-fido2 /dev/hidraw3 -add-fido2-name solo cipher
# use FIDO2 device
gocryptfs -fido2 /dev/hidraw3 -fido2-name solo cipher mnt
umount cipher
# delete FIDO2 device
gocryptfs -user user -delete-fido2-name solo cipher

Is that anything gocryptfs could consider to merge when ready?

Kind regards,

aanno

[rfjakob]

Hi, thanks for the PR! I understand the need, but I am afraid of the complexity and the format change.

Maybe this could be done by having multiple copies of gocryptfs.conf ? Like, gocryptfs.user1.conf etc. This would work already today using the -config= flag, but could be made more userfriendly by adding -user= as you suggested, though I would call it `keyslot" to match what LUKS does.

[schlomie]

This does work already. The only UX improvement I would recommend is prompting the user for the masterkey (to recreate the config file) instead of accepting it on stdin - as to not expose the masterkey to buffer and history.