Skip Navigation

User banner

Avid Amoeba

@ avidamoeba @lemmy.ca

Posts
44
Comments
1241
Joined
3 yr. ago

  • Private network storage for my users?

    Jump

  • The fact you didn’t mention the barest of minimums in your comment if where the issue lies.

    I described the procedure step-by-step mentioning each layer. That's the best I could do.

    OP specifically said they DID NOT want exactly what you’re describing.

    OP said they're worried about performance with this solution. Hence why my first response addressed the performance issue. The rest was responding to you (and anyone else who is reading) since you thought that is not an E2E solution. I tried explaining why it's client-side encryption and no keys are stored on the host.

  • Private network storage for my users?

    Jump

  • OP, test the performance of LUKS image, VeraCrypt (if entertaining that) and Cryptomator and tell us how they perform! 😁

    You could run a small set of fio runs to test sequential, random and parallel perf.

  • Private network storage for my users?

    Jump

  • The host mounts no LUKS. The host just exports a network share via NFS. The client mounts that NFS share to a local mount pount. Then the client has a dir which actually resides on the host. So far completely standard NAS stuff. Then the client creates a file in that dir. E.g. secretcontainer.img. This file is then encrypted on the client using cryptsetup (LUKS). Then it's mounted on the client using LUKS. All the LUKS stuff happens on the client. The only interaction with the host is throgh NFS. The host just sees a file appear called secretcontainer.img on its storage. The same idea would work with VeraCrypt instead of LUKS. Or Cryptomator. Or anything else that can store encrypted data in file(s) in a directory.

    LUKS can be used on a single file where the file acts as a disk device.

    Also what I'm describing here is bog-standard Linux functionality that's existed at least for 2 decades. Nothing fancy. It's stuff that's good to know so I'd be happy to answer questions.

    E:

    The procedure on the client is roughly:

     
        
cd /network/share/mountpoint
fallocate -l 1G test.img
cryptsetup luksFormat test.img
cryptsetup open test.img test_decrypted
mkfs.ext4 /dev/mapper/test_decrypted
mount /dev/mapper/test_decrypted /mnt

    Once that's done, subsequent uses are:

     
        
cryptsetup open test.img test_decrypted
mount /dev/mapper/test_decrypted /mnt

    Of course that can be automated further.

    Just tested it in a local dir and it works fine. The only difference between that and the real scenario is whether test.img resides on a network mount or local disk. Since the network mounts behave like normal disks, everything else works the same. The only concern is what the performance would be, which depends on how the underlying network fs handles reads/writes to test.img. E.g. if you change 0.5MB, does it send that 0.5MB or does it rewrite the whole 1GB file. When reading, does it have to read the whole 1GB file or just parts of it as needed. Etc.

  • Private network storage for my users?

    Jump

  • 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.

  • Private network storage for my users?

    Jump

  • 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.

  • Private network storage for my users?

    Jump

  • 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.

  • Banal but brutal: Career anxiety is a driving force behind authoritarianism

    Jump

  • Marx entered the chat

  • At Davos, NVIDIA, Microsoft CEOs deny AI bubble

    Jump

  • 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.

  • Ring Cameras Join Flock and Amazon to Now Create Direct Data Access for ICE

    Jump

  • How were collaborators treated the last time around though?

  • Trump Is Obsessed With Oil. But Chinese Batteries Will Soon Run the World

    Jump

  • 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.

  • Convenience is relative

    Jump

  • Everything is relative even if we agree that some things are absolute by convention. An unchanging signal doesn't carry much information. 😄

  • Trump Is Obsessed With Oil. But Chinese Batteries Will Soon Run the World

    Jump

  • 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.

  • Trump’s Letter to Norway Should Be the Last Straw

    Jump

  • The Atlantic - a fundamental part of The Last Straw consortium within the MSM, providing the vital straws that keep the hope alive, that the exploitation is about to stop increasing.

  • Trump’s Letter to Norway Should Be the Last Straw

    Jump

  • W

  • Reproducible alternatives to nextcloud?

    Jump

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

  • Make Microsoft's CEO cry by installing Chrome's 'Microslop' extension

    Jump

  • Jeff Bezos said the quiet part out loud — hopes that you'll give up your PC to rent one from the cloud

    Jump

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

  • Alternatives to syncthing for syncing files with android

    Jump

  • And when they do, you take care of it. Also, if you use Tailscale or equiv, you can stop Syncthing's exposure to the internet. Then you can stay on a fixed version across clients and limit unexpected breakage that comes with autotomatic updates.

  • Alternatives to syncthing for syncing files with android

    Jump

  • Build a Syncthing Android apk yourself. You don't need to update to every release. I'm still using 1.30 with 2.x.

  • Digg launches its new Reddit rival to the public

    Jump

  • The warm and cozy feel of a VC-funded social network.