concurrency
Should I be able to use Luks concurrently on a shared filesystem from different computers?
Attempts so far have failed with writes not being seen from the other computer until both computers remount the filesystem or reboot. Specifically, virtualbox shareable disks and shared folders, but potentially, any nfs/cloud storage.
Am I missing something or is there another tool for this case?
Hi,
in order to have a shared filesystem work, you need, well, a shared filesystem! Do not under any circumstances share the block-device or the LUKS-remapped decrypted block device. I suspect you do soemthing like that, because otherwise the question would not even arise.
The rigth way to do this is
raw-block-device -> LUKS decrypted block device -> Filesystem -> export of that filesystem, e.g. via NFS.
(last two steps possibly one with other network filesystyems)
Of course, NFS (or the network filesystem of your choice) has some transactional assurances and is missing others. For example, on NFS, nothing is atomic, except locks or rename operation (as far as I remember).
But if you do follow the right layering, what you have is not a LUKS problem at all, but something stemming from the filesystem layer and possibly wrong assumptions about the assurances it offers.
Regards,
Arno
Quoted 12 lines · Hugh Bragg
Should I be able to use Luks concurrently on a shared filesystem from different computers?
Attempts so far have failed with writes not being seen from the other computer until both computers remount the filesystem or reboot. Specifically, virtualbox shareable disks and shared folders, but potentially, any nfs/cloud storage.Am I missing something or is there another tool for this case?
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier
Hi Arno,
Thanks very much for taking time to respond Arno.
You're right. I'm sharing a virtual disk and trying to decrypt and mount that in multiple locations.
The other thing I tried was mounting a disk image on a virtualbox shared folder.
I don't want to need a dedicated server to deliver a decrypted filesystem because I don't want the decrypted data to be exposed to the network. I understand I could use secure communications, but this is all way too much overhead compared to what I'm trying to achieve.
From your response I gather that the answer is no, It doesn't support sharing of the raw block device with concurrent mounting. Is this just due to implementation or are there functional reason why this is so?
I've been trying encfs and ecryptfs too, but they suffer from security and functional deficiencies.
Is there some other solution that does support this setup?
Thanks,
Hugh
Quoted 42 lines · Arno Wagner
Hi,
in order to have a shared filesystem work, you need, well, a shared filesystem! Do not under any circumstances share the block-device or the LUKS-remapped decrypted block device. I suspect you do soemthing like that, because otherwise the question would not even arise.
The rigth way to do this is
raw-block-device -> LUKS decrypted block device -> Filesystem -> export of that filesystem, e.g. via NFS.(last two steps possibly one with other network filesystyems)
Of course, NFS (or the network filesystem of your choice) has some transactional assurances and is missing others. For example, on NFS, nothing is atomic, except locks or rename operation (as far as I remember).
But if you do follow the right layering, what you have is not a LUKS problem at all, but something stemming from the filesystem layer and possibly wrong assumptions about the assurances it offers.
Regards,
ArnoQuoted 12 lines · Hugh Bragg
Should I be able to use Luks concurrently on a shared filesystem from different computers?
Attempts so far have failed with writes not being seen from the other computer until both computers remount the filesystem or reboot. Specifically, virtualbox shareable disks and shared folders, but potentially, any nfs/cloud storage.Am I missing something or is there another tool for this case?
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Hi Hugh,
quite frankly, what you are doing is likely to corrupt your filesystem beyond recovery pretty fast. It will also corrupt data. Filesystems are _not_ designed to have changes on the underlying block-layer without being notified. The only case where this is safe is a read-only filesystem. You are tampering with the fundamental assumptions the filesystem-designers have to make.
If you want a filesystem that is not read-only to be visible in several places, you need to distribute it at or above the filesystem layer. Nothing else works.
That said, depending on your use-case, there may be options. One is a read-only export and a different mechanism for updates. You could tunnel NFS over OpenVPN or SSH or the like. You may also be able to use rsync/rdiff-backup or even SVN or git to synchronize data.
But putting the raw, LUKS-encrypted block device out there, mapping it in different machines and and then mounting read-write it is not a viable solution and cannot be one. Sorry. This is a case where security takes some effort that cannot be avoided.
Regards,
Arno
Quoted 73 lines · Hugh Bragg
Hi Arno,
Thanks very much for taking time to respond Arno.
You're right. I'm sharing a virtual disk and trying to decrypt and mount that in multiple locations.
The other thing I tried was mounting a disk image on a virtualbox shared folder.I don't want to need a dedicated server to deliver a decrypted filesystem because I don't want the decrypted data to be exposed to the network. I understand I could use secure communications, but this is all way too much overhead compared to what I'm trying to achieve.
Quoted 1 line
From your response I gather that the answer is no, It doesn't support
sharing of the raw block device with concurrent mounting. Is this just due to implementation or are there functional reason why this is so?
I've been trying encfs and ecryptfs too, but they suffer from security and functional deficiencies.
Is there some other solution that does support this setup?Thanks,
HughQuoted 24 lines · Arno Wagner
Hi,
in order to have a shared filesystem work, you need, well, a shared filesystem! Do not under any circumstances share the block-device or the LUKS-remapped decrypted block device. I suspect you do soemthing like that, because otherwise the question would not even arise.
The rigth way to do this is
raw-block-device -> LUKS decrypted block device -> Filesystem -> export of that filesystem, e.g. via NFS.(last two steps possibly one with other network filesystyems)
Of course, NFS (or the network filesystem of your choice) has some transactional assurances and is missing others. For example, on NFS, nothing is atomic, except locks or rename operation (as far as I remember).
But if you do follow the right layering, what you have is not a LUKS problem at all, but something stemming from the filesystem layer and possibly wrong assumptions about the assurances it offers.
Quoted 18 lines
Regards,
ArnoQuoted 12 lines · Hugh Bragg
Should I be able to use Luks concurrently on a shared filesystem from different computers?
Attempts so far have failed with writes not being seen from the other computer until both computers remount the filesystem or reboot. Specifically, virtualbox shareable disks and shared folders, but potentially, any nfs/cloud storage.Am I missing something or is there another tool for this case?
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier
Thanks again for the feedback.
I take you points. Actually neither virtualbox shareable disk nor shared folder are on any network so that wouldn't be a problem in those cases. In the other case of an actual network share, I see no reason why the data couldn't be shared if it was implemented to do so. ie. Decrypt/Encrypt as the point of use and always flush data immediately. It's a pity it isn't as in the new world of cloud storage, this would be very useful. I'd thought this would be obvious these days. I've seen a few solutions, but they're all proprietary and non-standard or poorly maintained.
I'm investigating CryFs now, but it's non standard. encfs is good if the maintainers were more active.
Hugh
Quoted 105 lines · Arno Wagner
Hi Hugh,
quite frankly, what you are doing is likely to corrupt your filesystem beyond recovery pretty fast. It will also corrupt data. Filesystems are _not_ designed to have changes on the underlying block-layer without being notified. The only case where this is safe is a read-only filesystem. You are tampering with the fundamental assumptions the filesystem-designers have to make.
If you want a filesystem that is not read-only to be visible in several places, you need to distribute it at or above the filesystem layer. Nothing else works.
That said, depending on your use-case, there may be options. One is a read-only export and a different mechanism for updates. You could tunnel NFS over OpenVPN or SSH or the like. You may also be able to use rsync/rdiff-backup or even SVN or git to synchronize data.
But putting the raw, LUKS-encrypted block device out there, mapping it in different machines and and then mounting read-write it is not a viable solution and cannot be one. Sorry. This is a case where security takes some effort that cannot be avoided.
Regards,
ArnoQuoted 72 lines · Hugh Bragg
Hi Arno,
Thanks very much for taking time to respond Arno.
You're right. I'm sharing a virtual disk and trying to decrypt and mount that in multiple locations.
The other thing I tried was mounting a disk image on a virtualbox shared folder.I don't want to need a dedicated server to deliver a decrypted filesystem because I don't want the decrypted data to be exposed to the network. I understand I could use secure communications, but this is all way too much overhead compared to what I'm trying to achieve.
Quoted 1 line
From your response I gather that the answer is no, It doesn't support
sharing of the raw block device with concurrent mounting. Is this just due to implementation or are there functional reason why this is so?
I've been trying encfs and ecryptfs too, but they suffer from security and functional deficiencies.
Is there some other solution that does support this setup?Thanks,
HughQuoted 24 lines · Arno Wagner
Hi,
in order to have a shared filesystem work, you need, well, a shared filesystem! Do not under any circumstances share the block-device or the LUKS-remapped decrypted block device. I suspect you do soemthing like that, because otherwise the question would not even arise.
The rigth way to do this is
raw-block-device -> LUKS decrypted block device -> Filesystem -> export of that filesystem, e.g. via NFS.(last two steps possibly one with other network filesystyems)
Of course, NFS (or the network filesystem of your choice) has some transactional assurances and is missing others. For example, on NFS, nothing is atomic, except locks or rename operation (as far as I remember).
But if you do follow the right layering, what you have is not a LUKS problem at all, but something stemming from the filesystem layer and possibly wrong assumptions about the assurances it offers.
Quoted 18 lines
Regards,
ArnoQuoted 12 lines · Hugh Bragg
Should I be able to use Luks concurrently on a shared filesystem from different computers?
Attempts so far have failed with writes not being seen from the other computer until both computers remount the filesystem or reboot. Specifically, virtualbox shareable disks and shared folders, but potentially, any nfs/cloud storage.Am I missing something or is there another tool for this case?
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Quoted 8 lines · Hugh Bragg
Thanks again for the feedback.
I take you points. Actually neither virtualbox shareable disk nor shared folder are on any network so that wouldn't be a problem in those cases. In the other case of an actual network share, I see no reason why the data couldn't be shared if it was implemented to do so. ie. Decrypt/Encrypt as the point of use and always flush data immediately. It's a pity it isn't as in the new world of cloud storage, this would be very useful. I'd thought this would be obvious these days.
You misunderstand: While this would be useful, it is not possible. Disk encryption has a different protection model that is, as Milan pointed out, not secure when you share the encrypted disk over the net. Disk encryption protects against an attacker that has access to the encrypted disk once and the assumption is that the user noticed that (laptop stolen, e.g.). When you put it over the net, the attacker has access multiple times and things are not secure anymore.
For example, SSH, OpenVPN, SSL, TLS, etc. all need to use different encryption keys for each session in order to be secure. When you share an encrypted block device, the key is alwasy the same and has to be. Hence you need to tunnel the date over secure _network_ encryption anyways.
Quoted 4 lines
I've seen a few solutions, but they're all proprietary and non-standard or poorly maintained.
I'm investigating CryFs now, but it's non standard. encfs is good if the maintainers were more active.
I don't know CryFs, but I know Joern Mueller-Quade and from him I would expect the design will be good. However the actual thesis supervisor is Jochen Rill, and I do not know him at all.
From a very brief look at the thesis, I see that they are using version counters (Sections 7.2.2 and 4.4.1), however I fail to find that version counter in Table 5.2 or anywhere else for that matter. From this and other indicators I conclude that this is primarily a theoretical work and that while the theory is possibly good, the implementation is at the very least shoddily described and may not be good.
Regards,
Arno
Quoted 113 lines
Hugh
Quoted 26 lines · Arno Wagner
Hi Hugh,
quite frankly, what you are doing is likely to corrupt your filesystem beyond recovery pretty fast. It will also corrupt data. Filesystems are _not_ designed to have changes on the underlying block-layer without being notified. The only case where this is safe is a read-only filesystem. You are tampering with the fundamental assumptions the filesystem-designers have to make.
If you want a filesystem that is not read-only to be visible in several places, you need to distribute it at or above the filesystem layer. Nothing else works.
That said, depending on your use-case, there may be options. One is a read-only export and a different mechanism for updates. You could tunnel NFS over OpenVPN or SSH or the like. You may also be able to use rsync/rdiff-backup or even SVN or git to synchronize data.
But putting the raw, LUKS-encrypted block device out there, mapping it in different machines and and then mounting read-write it is not a viable solution and cannot be one. Sorry. This is a case where security takes some effort that cannot be avoided.
Quoted 79 lines
Regards,
ArnoQuoted 72 lines · Hugh Bragg
Hi Arno,
Thanks very much for taking time to respond Arno.
You're right. I'm sharing a virtual disk and trying to decrypt and mount that in multiple locations.
The other thing I tried was mounting a disk image on a virtualbox shared folder.I don't want to need a dedicated server to deliver a decrypted filesystem because I don't want the decrypted data to be exposed to the network. I understand I could use secure communications, but this is all way too much overhead compared to what I'm trying to achieve.
Quoted 1 line
From your response I gather that the answer is no, It doesn't support
sharing of the raw block device with concurrent mounting. Is this just due to implementation or are there functional reason why this is so?
I've been trying encfs and ecryptfs too, but they suffer from security and functional deficiencies.
Is there some other solution that does support this setup?Thanks,
HughQuoted 24 lines · Arno Wagner
Hi,
in order to have a shared filesystem work, you need, well, a shared filesystem! Do not under any circumstances share the block-device or the LUKS-remapped decrypted block device. I suspect you do soemthing like that, because otherwise the question would not even arise.
The rigth way to do this is
raw-block-device -> LUKS decrypted block device -> Filesystem -> export of that filesystem, e.g. via NFS.(last two steps possibly one with other network filesystyems)
Of course, NFS (or the network filesystem of your choice) has some transactional assurances and is missing others. For example, on NFS, nothing is atomic, except locks or rename operation (as far as I remember).
But if you do follow the right layering, what you have is not a LUKS problem at all, but something stemming from the filesystem layer and possibly wrong assumptions about the assurances it offers.
Quoted 18 lines
Regards,
ArnoQuoted 12 lines · Hugh Bragg
Should I be able to use Luks concurrently on a shared filesystem from different computers?
Attempts so far have failed with writes not being seen from the other computer until both computers remount the filesystem or reboot. Specifically, virtualbox shareable disks and shared folders, but potentially, any nfs/cloud storage.Am I missing something or is there another tool for this case?
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier
Quoted 9 lines · Arno Wagner
Quoted 8 lines · Hugh Bragg
Thanks again for the feedback.
I take you points. Actually neither virtualbox shareable disk nor shared folder are on any network so that wouldn't be a problem in those cases. In the other case of an actual network share, I see no reason why the data couldn't be shared if it was implemented to do so. ie. Decrypt/Encrypt as the point of use and always flush data immediately. It's a pity it isn't as in the new world of cloud storage, this would be very useful. I'd thought this would be obvious these days.
Quoted 8 lines
You misunderstand: While this would be useful, it is not possible. Disk encryption has a different protection model that is, as Milan pointed out, not secure when you share the encrypted disk over the net. Disk encryption protects against an attacker that has access to the encrypted disk once and the assumption is that the user noticed that (laptop stolen, e.g.). When you put it over the net, the attacker has access multiple times and things are not secure anymore.
It's not quite accurate to say it's not possible. Actually it is possible, it's just not very secure on its own, just like a stolen laptop. Existing applications such as Lastpass achieve a great result by keeping the key locally, using secure transfers for data and only storing encrypted data on the server storage system.
Quoted 5 lines
For example, SSH, OpenVPN, SSL, TLS, etc. all need to use different encryption keys for each session in order to be secure. When you share an encrypted block device, the key is alwasy the same and has to be. Hence you need to tunnel the date over secure _network_ encryption anyways.
Naturally, network communications are best encrypted. A task well suited to those tools. Disk encryption shouldn't worry about such things as they are a modular component. They should also not be concerned with caching either, a task more suited to disks drivers, filesystems and applications.
Quoted 16 lines
Quoted 4 lines
I've seen a few solutions, but they're all proprietary and non-standard or poorly maintained.
I'm investigating CryFs now, but it's non standard. encfs is good if the maintainers were more active.I don't know CryFs, but I know Joern Mueller-Quade and from him I would expect the design will be good. However the actual thesis supervisor is Jochen Rill, and I do not know him at all.
From a very brief look at the thesis, I see that they are using version counters (Sections 7.2.2 and 4.4.1), however I fail to find that version counter in Table 5.2 or anywhere else for that matter. From this and other indicators I conclude that this is primarily a theoretical work and that while the theory is possibly good, the implementation is at the very least shoddily described and may not be good.
Quoted 3 lines
Regards,
Arno
Yes, optimistic locking would work well in combination with something to handle contention for large files.
Thanks Arno. It's good to touch base on this with someone and helps to clarify my goals.
Quoted 112 lines
Quoted 112 lines
Hugh
Quoted 26 lines · Arno Wagner
Hi Hugh,
quite frankly, what you are doing is likely to corrupt your filesystem beyond recovery pretty fast. It will also corrupt data. Filesystems are _not_ designed to have changes on the underlying block-layer without being notified. The only case where this is safe is a read-only filesystem. You are tampering with the fundamental assumptions the filesystem-designers have to make.
If you want a filesystem that is not read-only to be visible in several places, you need to distribute it at or above the filesystem layer. Nothing else works.
That said, depending on your use-case, there may be options. One is a read-only export and a different mechanism for updates. You could tunnel NFS over OpenVPN or SSH or the like. You may also be able to use rsync/rdiff-backup or even SVN or git to synchronize data.
But putting the raw, LUKS-encrypted block device out there, mapping it in different machines and and then mounting read-write it is not a viable solution and cannot be one. Sorry. This is a case where security takes some effort that cannot be avoided.
Quoted 79 lines
Regards,
ArnoQuoted 72 lines · Hugh Bragg
Hi Arno,
Thanks very much for taking time to respond Arno.
You're right. I'm sharing a virtual disk and trying to decrypt and mount that in multiple locations.
The other thing I tried was mounting a disk image on a virtualbox shared folder.I don't want to need a dedicated server to deliver a decrypted filesystem because I don't want the decrypted data to be exposed to the network. I understand I could use secure communications, but this is all way too much overhead compared to what I'm trying to achieve.
Quoted 1 line
From your response I gather that the answer is no, It doesn't support
sharing of the raw block device with concurrent mounting. Is this just due to implementation or are there functional reason why this is so?
I've been trying encfs and ecryptfs too, but they suffer from security and functional deficiencies.
Is there some other solution that does support this setup?Thanks,
HughQuoted 24 lines · Arno Wagner
Hi,
in order to have a shared filesystem work, you need, well, a shared filesystem! Do not under any circumstances share the block-device or the LUKS-remapped decrypted block device. I suspect you do soemthing like that, because otherwise the question would not even arise.
The rigth way to do this is
raw-block-device -> LUKS decrypted block device -> Filesystem -> export of that filesystem, e.g. via NFS.(last two steps possibly one with other network filesystyems)
Of course, NFS (or the network filesystem of your choice) has some transactional assurances and is missing others. For example, on NFS, nothing is atomic, except locks or rename operation (as far as I remember).
But if you do follow the right layering, what you have is not a LUKS problem at all, but something stemming from the filesystem layer and possibly wrong assumptions about the assurances it offers.
Quoted 18 lines
Regards,
ArnoQuoted 12 lines · Hugh Bragg
Should I be able to use Luks concurrently on a shared filesystem from different computers?
Attempts so far have failed with writes not being seen from the other computer until both computers remount the filesystem or reboot. Specifically, virtualbox shareable disks and shared folders, but potentially, any nfs/cloud storage.Am I missing something or is there another tool for this case?
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Hi,
On 03/27/2016 01:53 AM, Hugh Bragg wrote:
...
Quoted 4 lines
I don't want to need a dedicated server to deliver a decrypted filesystem because I don't want the decrypted data to be exposed to the network. I understand I could use secure communications, but this is all way too much overhead compared to what I'm trying to achieve.
As Arno said, dm-crypt cannot be used this way - it is not designed to provide shared block device among servers.
On top what already mentioned, probably some combination with mechanism to share active/active block device could work (maybe DRBD) but such solution is quite fragile.
But there is another problem with your solution - you said that you do not want decrypted data on the wire.
While accessing encrypted device (dmcrypt/LUKS) this simple way will put encrypted data over your network, this solution is NOT secure.
Anyone can use reply attack and just replace old ciphertext content (some old already-seen data) in packets.
(Imagine it is as a snapshot of the encrypted device in time.)
You have to use encrypted network connection on top of this (SSH, VPN, ...) to provide secure transport layer here.
Just sharing encrypted disk device over network (even if it is just through point-to-point using iSCSI, NBD whatever) is simply not secure!
Milan
On 27 Mar 2016 00:50 +1000, from [email protected] (Hugh Bragg):
Quoted 4 lines
Should I be able to use Luks concurrently on a shared filesystem from different computers?
Attempts so far have failed with writes not being seen from the other computer until both computers remount the filesystem or reboot.
As a thought experiment, try removing LUKS from the equation. For the purposes of what you seem to be asking, LUKS is just a part of the physical storage layer.
Instead of [unencrypted physical storage device + LUKS container] providing the feature "encrypted storage of user-selected data", consider the case [self-encrypting physical storage device] which provides the same feature "encrypted storage of user-selected data" but this time without involving LUKS or dm-crypt.
_Would you expect what you have in mind to work after making that single change?_
If not, then there is no reason to expect it to suddenly start working when you introduce an additional component (LUKS) into the _physical_ storage stack. And as far as the file system is concerned, LUKS very much _is_ a part of the physical storage stack. (There would be nothing _architecturally_ weird with a HBA that itself runs LUKS and exposes the decrypted container while writing the encrypted data to the actual physical storage device. It would come with some fairly serious design challenges if one wants to make it secure, however.)
Signature · 3 lines
Michael Kjörling • https://michael.kjorling.se • [email protected] “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup)
Quoted 9 lines · Michael Kjörling
On 27 Mar 2016 00:50 +1000, from [email protected] (Hugh Bragg):
Quoted 4 lines
Should I be able to use Luks concurrently on a shared filesystem from different computers?
Attempts so far have failed with writes not being seen from the other computer until both computers remount the filesystem or reboot.As a thought experiment, try removing LUKS from the equation. For the purposes of what you seem to be asking, LUKS is just a part of the physical storage layer.
Quoted 8 lines
Instead of [unencrypted physical storage device + LUKS container] providing the feature "encrypted storage of user-selected data", consider the case [self-encrypting physical storage device] which provides the same feature "encrypted storage of user-selected data" but this time without involving LUKS or dm-crypt.
_Wouldyou expect what you have in mind to work after making that single change?_
Yes, in the case of virtualbox storage, if the disk was self encrypting it would work.
Sounds interesting. Are there any opensource tools that can do this? I was expecting lvm on luks on a virtual disk to do this, but it failed. For network shares, this wouldn't be any good. I wouldn't want to store the key on the cloud server.
Quoted 9 lines
If not, then there is no reason to expect it to suddenly start working when you introduce an additional component (LUKS) into the _physical_ storage stack. And as far as the file system is concerned, LUKS very much _is_ a part of the physical storage stack. (There would be nothing _architecturally_ weird with a HBA that itself runs LUKS and exposes the decrypted container while writing the encrypted data to the actual physical storage device. It would come with some fairly serious design challenges if one wants to make it secure, however.)