4 ms·

> one can only encrypt the whole disk with a single key You can still use partitions. > not all cryptographic algorithms can be used as the block layer doesn'

> one can only encrypt the whole disk with a single key You can still use partitions. > not all cryptographic algorithms can be used as the block layer doesn't have a high-level overview of the data anymore I do not really understand this. Which cryptographic algorithms can't be used? > Most common algorithms require some sort of block chaining to be secure Nowadays I would say that from these only CTR is common, which does not require chaining. > Application and file system level encryption are usually the preferred choice for client systems because of the flexibility One big issue with "Application and file system level encryption" is that you often end up leaking metadata (such as the date edited, file name, file size, etc). Regardless I think that this is a really nice article. I can't wait to try their patches on my laptop.

steerablesafe 7y ago
> One big issue with "Application and file system level encryption" is that you often end up leaking metadata (such as the date edited, file name, file size, etc). I wonder how cryfs stacks up in this regard. https://www.cryfs.org https://www.cryfs.org
richardwhiuk 7y ago
> I do not really understand this. Which cryptographic algorithms can't be used? CBC - which is one the most common stream cipher algorithm. It's not clear me whether GCM would work or not.
- dependenttypes 7y ago
  Apparently CBC is used by cryptsetup by default, see https://linux.die.net/man/8/cryptsetup https://linux.die.net/man/8/cryptsetup It might not be ideal but it still can be used. Though, I would not call CBC common at all. Pretty much everyone has switched to CTR or some variant of it (such as GCM). Also, CBC is not a stream cipher algorithm.
  - JoshTriplett 7y ago
    That online manpage is quite outdated; I recommend man7.org, which gets regularly auto-updated: http://man7.org/linux/man-pages/man8/cryptsetup.8.html http://man7.org/linux/man-pages/man8/cryptsetup.8.html . The current default for LUKS is XTS.
- brandmeyer 7y ago
  GCM requires somewhere to put the nonces and authentication tags. In principle, you could use a layer of indirection not entirely unlike a page table to store that information. For example, a 64-bit nonce, 64-bit block pointer, and 128-bit authentication tag could pack together in a radix tree for the job, retiring 7 bits of the virtual-to-physical mapping per level for 4 kB blocks. Of course, the downside is that now the block layer must tackle all of the write ordering issues that a filesystem does when updating the tree. The block layer would find itself greenspunning up a filesystem inside itself, even if it was a filesystem of only one file.
  - wahern 7y ago
    The 128-bit tag length, which offers less than 128-bit strength depending on the nonce size, makes GCM and similar AEAD constructions poorly suited for archival storage. If you want to store more data without rekeying you need to reduce the authentication security. GCM makes perfect sense for ephemeral, message-based network traffic. Traditional, separate, keyed MACs still seem preferable for archival storage, especially with tree-based modes--native as with BLAKE3 or KangarooTwelve, or constructed like SHA-3-based ParallelHash.
    - brandmeyer 7y ago
      The tag's strength doesn't depend on the nonce size in cases where you can use sequential nonces. Longer nonce sizes are valuable only when using randomly allocated nonces and you need to avoid the birthday paradox. 64 bits is considerably longer than the total write lifetime of modern disks. Even if you used a nonce per 512-byte block, you'd need well over a yottabyte of writes to roll through that counter. The profile that authenticated encryption defends against is an attacker who is attempting to feed the victim specially crafted bad blocks. 128-bit tags are good enough that the disk will be completely trashed long before the victim executes something of the attacker's choosing.
nemo1618 7y ago
> Which cryptographic algorithms can't be used? You can't use any algorithm that requires O(n) IVs (e.g. a separate IV per disk sector), because there's nowhere to store the IVs. (Another consequence of this is that you can't store checksums anywhere, so you can't provide integrity checks.) You can't use CTR mode either, because you'll end up reusing counter values. What do you do when you need to overwrite a block with new data? XTS mode solves this, at least partially. It's like CTR mode, but with an extra "tweak" that essentially hashes the block's content into the encryption key. So if you overwrite a block with new data, you get a new encryption key. This isn't perfect, though, because it's still deterministic. If an attacker can see multiple states of the disk, they can tell when you revert a block to a previous state. But it's much better than other modes, especially since the main threat you want to protect against is your laptop getting stolen (in which case the attacker only sees a single state).
- dependenttypes 7y ago
  > You can't use any algorithm that requires O(n) IVs (e.g. a separate IV per disk sector), because there's nowhere to store the IVs Certainly you can. You just have to reduce the effective sector size that the file system can use. > What do you do when you need to overwrite a block with new data? You generate a new random nonce (as per XChacha) and you store it in the sector.
  - Hello71 7y ago
    > Certainly you can. You just have to reduce the effective sector size that the file system can use. get back to me when you find a high-performance (FAT doesn't count) Linux filesystem that supports sector sizes of 496.
    - dependenttypes 7y ago
      Modern disks use much bigger sectors. See https://en.wikipedia.org/wiki/Advanced_Format https://en.wikipedia.org/wiki/Advanced_Format
yrro 7y ago
https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/ https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

steerablesafe 7y ago

> One big issue with "Application and file system level encryption" is that you often end up leaking metadata (such as the date edited, file name, file size, etc). I wonder how cryfs stacks up in this regard. https://www.cryfs.org https://www.cryfs.org

richardwhiuk 7y ago

> I do not really understand this. Which cryptographic algorithms can't be used? CBC - which is one the most common stream cipher algorithm. It's not clear me whether GCM would work or not.

dependenttypes 7y ago
Apparently CBC is used by cryptsetup by default, see https://linux.die.net/man/8/cryptsetup https://linux.die.net/man/8/cryptsetup It might not be ideal but it still can be used. Though, I would not call CBC common at all. Pretty much everyone has switched to CTR or some variant of it (such as GCM). Also, CBC is not a stream cipher algorithm.
- JoshTriplett 7y ago
  That online manpage is quite outdated; I recommend man7.org, which gets regularly auto-updated: http://man7.org/linux/man-pages/man8/cryptsetup.8.html http://man7.org/linux/man-pages/man8/cryptsetup.8.html . The current default for LUKS is XTS.
brandmeyer 7y ago
GCM requires somewhere to put the nonces and authentication tags. In principle, you could use a layer of indirection not entirely unlike a page table to store that information. For example, a 64-bit nonce, 64-bit block pointer, and 128-bit authentication tag could pack together in a radix tree for the job, retiring 7 bits of the virtual-to-physical mapping per level for 4 kB blocks. Of course, the downside is that now the block layer must tackle all of the write ordering issues that a filesystem does when updating the tree. The block layer would find itself greenspunning up a filesystem inside itself, even if it was a filesystem of only one file.
- wahern 7y ago
  The 128-bit tag length, which offers less than 128-bit strength depending on the nonce size, makes GCM and similar AEAD constructions poorly suited for archival storage. If you want to store more data without rekeying you need to reduce the authentication security. GCM makes perfect sense for ephemeral, message-based network traffic. Traditional, separate, keyed MACs still seem preferable for archival storage, especially with tree-based modes--native as with BLAKE3 or KangarooTwelve, or constructed like SHA-3-based ParallelHash.
  - brandmeyer 7y ago
    The tag's strength doesn't depend on the nonce size in cases where you can use sequential nonces. Longer nonce sizes are valuable only when using randomly allocated nonces and you need to avoid the birthday paradox. 64 bits is considerably longer than the total write lifetime of modern disks. Even if you used a nonce per 512-byte block, you'd need well over a yottabyte of writes to roll through that counter. The profile that authenticated encryption defends against is an attacker who is attempting to feed the victim specially crafted bad blocks. 128-bit tags are good enough that the disk will be completely trashed long before the victim executes something of the attacker's choosing.

nemo1618 7y ago

> Which cryptographic algorithms can't be used? You can't use any algorithm that requires O(n) IVs (e.g. a separate IV per disk sector), because there's nowhere to store the IVs. (Another consequence of this is that you can't store checksums anywhere, so you can't provide integrity checks.) You can't use CTR mode either, because you'll end up reusing counter values. What do you do when you need to overwrite a block with new data? XTS mode solves this, at least partially. It's like CTR mode, but with an extra "tweak" that essentially hashes the block's content into the encryption key. So if you overwrite a block with new data, you get a new encryption key. This isn't perfect, though, because it's still deterministic. If an attacker can see multiple states of the disk, they can tell when you revert a block to a previous state. But it's much better than other modes, especially since the main threat you want to protect against is your laptop getting stolen (in which case the attacker only sees a single state).

dependenttypes 7y ago
> You can't use any algorithm that requires O(n) IVs (e.g. a separate IV per disk sector), because there's nowhere to store the IVs Certainly you can. You just have to reduce the effective sector size that the file system can use. > What do you do when you need to overwrite a block with new data? You generate a new random nonce (as per XChacha) and you store it in the sector.
- Hello71 7y ago
  > Certainly you can. You just have to reduce the effective sector size that the file system can use. get back to me when you find a high-performance (FAT doesn't count) Linux filesystem that supports sector sizes of 496.
  - dependenttypes 7y ago
    Modern disks use much bigger sectors. See https://en.wikipedia.org/wiki/Advanced_Format https://en.wikipedia.org/wiki/Advanced_Format

yrro 7y ago

https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/ https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/