avidamoeba

Cryptomator encrypts files individually right?

E:

For the curious like me, here's how Cryptomator makes a directory with multiple encrypted files appear as a single vol when decrypted. From mount:

fuse-nio-adapter on $HOME/.local/share/Cryptomator/mnt/test type fuse.fuse-nio-adapter (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

It uses its own fuse module to present it as a volume. The real directory has its own file structure:

~/test/test$ find
.
./c
./vault.cryptomator
./vault.cryptomator.12A05032.bkup
./d
./d/LO
./d/LO/AYYSWMZO35ASQ2HOACU3I7LRVIAMH4
./d/LO/AYYSWMZO35ASQ2HOACU3I7LRVIAMH4/PmAyroZAF5W7kGoHxr3Fhi-NeQIeO7SZcufE.c9r
./d/LO/AYYSWMZO35ASQ2HOACU3I7LRVIAMH4/dirid.c9r
./IMPORTANT.rtf
./masterkey.cryptomator.7DB56291.bkup
./masterkey.cryptomator

This looks like a good option. Perhaps more flexible than using LUKS/VeraCrypt file, but those should work too if the underlying dir is on NFS/SAMBA.

Not sure I'm getting you and probably didn't explain myself well. Here's what I mean:

• Host exposes a network share (1-time setup)
• Client mounts the network share (N-time setup, could be automated)
• Client creates a LUKS or VeraCrypt (or something else) file in that network share, secured with their key. The key is generated on the client and it doesn't leave the client or enter the host. (1-time setup)
• Client decrypts the image with their key and mounts it on the client (N-time setup, can be automated)
• Client modifies data in the decrypted vol
• Client unmounts the volume (N-time, not required)
• Client unmounts the network share (N-time, not required)

At no point does the client's key leave their computer and the host only ever sees encrypted data.

Subsequent uses without automation:

• Client mounts network share
• Client decrypts volume

That's at least how I understood OP's suggestion for putting LUKS images on the NAS and that is secure indeed. They're worried about performance.

LUKS-encrypted images won't have bad performance. Could also use VeraCrypt or something like that for better portability if you need cross-platform function. Expose the folders where the images are stored via NFS/SAMBA. Flexible and portable solution.

You could expose volumes with iSCSI and format/mount them on the clients. Probably don't want to do that.

E:

LUKS-encrypted images won't have bad performance.

Actually it depends whether the underlying network fs can do partial writes. I imagine both NFS and SAMBA can. If the file has to be fully rewritten with every change, then perf would be dead.

Marx entered the chat

If it's this useful, we're (and them) fucked too because the economy would collapse under falling aggregate demand due to falling wages and layoffs. The "people will find new jobs" won't save us from a shift this large without a depression. And all sorts of things happen during depressions.

How were collaborators treated the last time around though?

Yeah they can't match top of the line Li-Ion like lithium-cobalt batteries. Neither can LFP, but LFP is good enough for lower range EVs cars as they're already used in such. Sodium ion has even lower density than LFP but not dramatically so and it's still early days so their density is likely to improve. Look at these two cells currently on sale:

The first one is a CATL-made LFP. The second is some smaller manufacturer's sodium ion. The 729Whr vs 713Whr, 1944cm³ vs 2593cm³. If the sodium ones can be made cheap enough, these are already usable in low range vehicles like Nissan Leaf or equivalent. And then there's buses, trucks, other ICE powered equipment.

Beyond EVs, the much cheaper sodium-ion battery is entering mass production in China. We can already buy B-grade cells on AliExpress. This will have implications for all sorts of use cases that could use batteries but don't due to cost.

This is the version I setup just yesterday. Much simpler setup than the AIO. The AIO controls Docker to manage its collection of containers.

Shitty ass thin client running cheap hw that can't do anything, a.k.a. Chromebook.