4 ms·

> 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

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

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