I've been thinking about ways to improve the security of my data stored and backed up using the "3-2-1" method. Moreover by using several layers of encryption to encrypt and decrypt a filesystem structure steps by steps.

Consider the following :


What if sensitivefile1 was first encrypted using AES256, then subfolder2 would be encrypted using a different AES256 key, then folder2 using yet another key, then /root using a fourth key and so on ...

I am aware of the fact that since AES 256 is considered strong enough, only one layer would be needed to secure all of this (as mentionned here: Does encrypting data multiple times using different passwords increase security?), but I'm trying to figure whether a system that decrypts the structure as needed instead of decrypting the whole filesystem at once would even make sense.

I've been using MEGA for my cloud storage for a while but it seems to be decrypting my whole filesystem once I log in rather than chunks of it, which I would prefer.

Am I overthinking this ? Would that make sense or is that just a late-night brainfart ? Is this kind of system already used somewhere that I'd be missing or would that actually be less effective (secured) than some other method ?

Looking forward for your thoughts about the matter. Regards,

  • $\begingroup$ Well, the existance of meta data of the directory structure makes the attacks worst, the cost of first layer is around $2^{256}$ the the second layer is also around $2^{256}$. So total two layers are $2*2^{256}$. So there is no gain from double encryption... Why don't you use just VeraCrypt with good password instead of inventing the wheel? $\endgroup$
    – kelalaka
    Sep 19, 2023 at 22:41
  • $\begingroup$ The structure's meta data may have to be indexed under some kind of obfuscation (gotta think this through). The gain from double encryption is more about having different keys for each encrypted file if needed, allowing to share chunks of a filesystem without having to duplicate the data and/or to avoid displaying a potentially sensitive file to some over-the-shoulder looking guy. Rclone/crypt may seem to be more fittable for what I had in mind. I'll read VeraCrypt's doc as well just in case. Thanks! $\endgroup$
    – Xcrowzz
    Sep 19, 2023 at 22:54
  • $\begingroup$ Sharing is completely different question a there are lots of cases like, single share or multiple share, time limit of the share, share cancel. In general, however, one can encrypt with a random key file encryption then encrypt this with a key derived from password see here. The sharing is a bit need consideration since once shared they can get the copy.... $\endgroup$
    – kelalaka
    Sep 19, 2023 at 22:59
  • $\begingroup$ Precisely, there are a few use cases that I haven't mentionned because I consider them to be out of scope. That's why I limited my question to more or less "Does such cryptographic system exist and if not, what issue am I missing with it ?". $\endgroup$
    – Xcrowzz
    Sep 19, 2023 at 23:12

1 Answer 1


I'm going to say that you could do this and it wouldn't help you much, but this is mostly because of how hardware works. One encrypted volume is enough for security, but there are real world reasons to do what you described.

Firstly, we should discuss the hardware aspect. If you have harddisk that has built in encryption, it does exactly what you describe where you only decrypt chunks as you need it. This is because you have AES with a key and each "block" is configured with a counter with modifier to the key. This is due to the fact that you have a memory bank on the harddrive as a buffer, and then you have dist write buffers that relate to the "sectors", and you'll encrypt the block the size of the sector buffer. You'll pull from the disk and decrypt it, update, and to an encrypted write. Some of these have multiple AES keys so you can have different "volumes" with different keys, but I've never seen that used. It's just a footnote in the IC datasheet.

Now on to the "software" approach. Generally, everything will be encrypted with the same key on the cloud as it looks like a "loopback" volume that is decrypted and mounted. Many smaller loopback volumes are faster in the software sense because there's fewer updates that need to go across the whole tree. Filesystems were designed without encryption in mind, so inode updates on a large volume can be costly because you don't know where all of the inodes are until you follow the linked list to the end, and this can take a lot of time.

I can see that on the cloud, you could have a speedup by having sub-volumes with different keys, but a lot of this will depend on how the OS handles the loopback mounts.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.