6

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?

UTF-8
  • 2,300
  • 1
  • 9
  • 24
  • 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 Apr 30 '17 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 May 01 '17 at 00: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 May 01 '17 at 11:44
  • 1
    @VovCA You never insert data when using disk encryption. You only update data. – UTF-8 May 01 '17 at 11:45
  • 4
    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 https://security.stackexchange.com/questions/39306/how-secure-is-ubuntus-default-full-disk-encryption or https://security.stackexchange.com/questions/5158/for-luks-the-most-preferable-and-safest-cipher or https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects – derobert May 02 '17 at 21:03
  • How exactly would using CTR fix the malleability problem ? – b0fh Jun 07 '17 at 12:31
  • @b0fh Not at all. I didn't claim that. I just don't see the advantage their complicated approach has over simple and standard CTR. – UTF-8 Jun 07 '17 at 12:48
  • This seem seems have some answers: https://crypto.stackexchange.com/questions/48069/pros-and-cons-of-block-ciphers-mode-of-operations#48077 which links to this for comparing CBC with CTR mode: https://security.stackexchange.com/questions/27776/block-chaining-modes-to-avoid/27780#27780 – OpenStandards.net Aug 03 '19 at 19:08
  • Would galois counter mode not make the most sense in this situation? – leaustinwile Aug 03 '19 at 19:33

2 Answers2

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.

user2313067
  • 916
  • 1
  • 6
  • 9
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.

Liam Dennehy
  • 587
  • 2
  • 8
  • 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 Jul 26 '17 at 11:31