7

I read that LUKS uses 256-bit AES with CBC by default. CBC, of course, has the disadvantages that if you change something in the plain text, you have to change everything that comes after it. In the case of hard drive encryption, that's usually at least a few hundred GB, often several TB. You don't want to rewrite several TB every time a word in a text file is changed, obviously.

I then read that LUKS solves this problem by only using CBC within small blocks (e.g. 512 Byte) which it encrypts independently from each other. Apart from having other problems, how does this not introduce the problems of ECB? Namely being structure-preserving and semantically malleable?

Is a new initialization vector chosen for each of those ~512 Byte blocks so these problems don't occur? If so: How is it chosen?

Why doesn't LUKS use CTR?

Improve this question
9
  • 1
    A text file is maybe a bad example. Most desktop applications write the entire file when saving. But databases will write random blocks within the file.
    – symcbean
    Commented Apr 30, 2017 at 22:42
  • AES CBC and AES CTR both have initialization vectors, then in CBC takes IV from previous block cypher text and in CTR IV takes Counter which is incremented every AES block. Let's say you have changed text and use CTR mode, for example inserted 32 bytes, then following blocks need to re-encrypt, too. Counter has +1 now, you cannot correctly decrypt otherwise.
    – VovCA
    Commented May 1, 2017 at 0:24
  • @symcbean I know that text editors typically check a different location; if there already is a file, delete it; then move the current file there; and then create a new file which contains the buffered data. Or actually, that's what the user application tells the library it uses to do which then tells the kernel to do that which then invokes the FS module which then does something at some point (possibly collects changes first). But that doesn't matter. It doesn't matter the slightest. My point is: User makes a tiny change. => Huge amount of data has to be rewritten (eventually).
    – UTF-8
    Commented May 1, 2017 at 11:44
  • 1
    @VovCA You never insert data when using disk encryption. You only update data.
    – UTF-8
    Commented May 1, 2017 at 11:45
  • 5
    It uses XTS by default nowadays. Previously it used AES-CBC-ESSIV, where ESSIV was used to generate the IV for each sector. Even before that, ESSIV wasn't used, and did have the structure-preserving problem. See security.stackexchange.com/questions/39306/… or security.stackexchange.com/questions/5158/… or gitlab.com/cryptsetup/cryptsetup/wikis/…
    – derobert
    Commented May 2, 2017 at 21:03

2 Answers 2

Reset to default
2

Liam Dennehy's answer shows that luks doesn't use CBC by default anymore. As for why it used it instead of CTR before, that's because, under the usual adversary model for disk encryption, CTR isn't secure for disk encryption (as you can see on Wikipedia).

Unless you change the IV on every change, which would require encrypting the entire disk for every change, if your adversary has at some point had the plain text and cipher text for a block, he can decrypt that block until you change the IV, as CTR encryption simply produces a stream of random bytes for a given block which is xored with the plain text. The only way to make it secure without requiring reencrypting the whole disk for each change would be to store an IV per block (which would change for each update), which would be either quite costly in terms of disk space, or would require big blocks and thus reencrypting a lot for each update.

Note that in CBC mode, each 512 byte block has its own IV generated from the key and block number, so two identical blocks will not be the same after encryption.

Improve this answer
0
1

The online man pages for cryptsetup I have found still refer to a really old release, and this may be the source for your outdated info.

A commit on June 28 2013 (four years ago as of this answer) updated the man page to show the new default for LUKS devices is aes-xts-plain64, which seems to be somewhere between the 1.6.0 and 1.6.2 release.

Improve this answer
1
  • But why didn't they use their complicated approach in the first place? It got to have some advantage over the standard stuff like CTR mode, right?
    – UTF-8
    Commented Jul 26, 2017 at 11:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .