A one-time reverse mount which is then optimised for forward mounts

[jpluscplusm]

Hi folks 👋

I have a large, static dataset that I'd like to store on a cloud provider. I'm going to use deterministic filenames both to avoid diriv files, and also so that I can move files across directories (behind the scenes) without downloading and re-encrypting them, as & when I reorganise the data. So far, so good.

My dataset is currently unencrypted. I would like to use reverse mode to give my tooling a view of the encrypted corpus that it can upload. This will avoid me having to duplicate the dataset locally, first, and avoid me needing to copy it into a forward-mode mount and temporarily using double the disk space.

However, the dataset will be 100% read-only after it's created - so here's my problem: by doing a standard -reverse mount, I believe that I'll be immutably baking AES-SIV into the decryption process. And here's my gocryptfs -speed output:

$ gocryptfs -speed
gocryptfs v2.4.0 without_openssl; go-fuse v2.3.0; 2023-06-10 go1.20.3 linux/amd64
cpu: Intel(R) Core(TM) i7-8500Y CPU @ 1.50GHz; with AES acceleration
AES-GCM-256-OpenSSL                 N/A
AES-GCM-256-Go                  2853.68 MB/s    (selected in auto mode)
AES-SIV-512-Go                   177.37 MB/s
XChaCha20-Poly1305-OpenSSL          N/A
XChaCha20-Poly1305-Go           1416.31 MB/s    (selected in auto mode)

AES-SIV appears to be more than an order of magnitude slower than AES-GCM, which is the option that I would select if I were creating a filesystem for forward mounting.

• Am I correct to believe that using a reverse mount to initially populate the encrypted files will force AES-SIV to be used for that data, forever?
• Is there any way to achieve my aim of getting a view onto an encrypted dataset without baking AES-SIV into the decryption process, but also without requiring 100% extra disk space to be available (albeit temporarily)?
• Is this a problem that other folks have faced? And solved? :-)

Thanks, all! :-D