Warning - long and somewhat off-topic post follows ^-^
Gordon wrote:Uncertain how to interpret that. From the links you provided it seems a hacker would need to get to the B3 multiple times, with you accessing it in between and entering the password which could then be read in plain text by the returning hacker.
That's not quite it. This issue is that CBC mode
enables a hacker with knowledge of the contents and location of at least some plaintext system files on your HDD (not unreasonable if a standard install process has been followed post LUKS format), and access to your (encrypted) HDD, to overwrite appropriate ciphertext blocks on that device to inject
shellcode, which then executes during the boot process at root privilege.
The attack is possible because
CBC mode encrypts like this:
CBC adds the xor step to address the major problem with
ECB (electronic codebook) mode, in which identical plaintext blocks (a block = 128 bits in AES, regardless of key length) appear as identical ciphertext blocks, allowing e.g. the encrypted disk to be scanned for the 'fingerprints' of certain target files:
ECB mode: Encrypted, But Still Identifiable
However, although CBC mode fixes this issue, it introduces another (the malleability vulnerability). It decrypts blocks as follows:
As such, if an attacker knows the (true) plaintext of block n on the HDD (128 bits/16 bytes from an init script, for example), she can overwrite the ciphertext of block n-1, to force
any desired text to come out as the result of decrypting block n. She
doesn't need to know the encryption key to do this.
To see how this exploit works, let:
Cn -1 = (original) ciphertext of block n-1
Cn = (original) ciphertext of block n
Pn = known (original) plaintext of block n
Dn = result of decrypting Cn with (unknown to attacker) key K, prior to xor
Sn = desired (128 bit) shellcode for block n
+ = xor
Then, because Pn = Cn-1 + Dn, if we replace Cn-1 with Sn + Cn-1 + Pn, the decoder will dutifully return:
(Sn + Cn-1 + Pn) + Dn
= Sn + Pn + (Cn-1 + Dn)
= Sn + Pn + Pn
= Sn, and the fix is in.
Of course, this means that the decrypted text of block n-1 will be garbage. However, that may not matter; for example, if block n-1 contains comment text in a script file.
As such, it is now generally recommended not to use CBC mode for disk encryption, but to use either a
counter mode or (most commonly seen)
Xor-encrypt-xor tweaked codebook mode with ciphertext stealing (XTS), which encrypts like this:
OK, so, if XTS mode is chosen, then you still need to fix on the
block cipher,
key length and
hash (used in the LUKS header).
Reasonable choices for the
block cipher include
AES/Rijndael and (my own personal favourite)
Serpent.
As to
key length, a
key length of 128 bits (for AES or Serpent)
should be sufficient against any feasible brute force attack using
conventional hardware, barring any catastrophic break in the underlying cryptosystem.
However, if usable quantum computers are really on the way, then be aware that
Grover's algorithm will let these essentially
halve the number of bits of effective security - so a 128 bit key will become a 64 bit key (for a
symmetric cipher). As such, a more conservative approach (and that now advocated by the NSA) is to use a 256 bit key. (Of course, the bigger problem with quantum computing is for
public key cryptography, most variants of which (via
Shor's algorithm) it will effectively render useless overnight... but that's another story.)
Whatever key length you choose, be aware that if you use XTS mode this utilizes two different keys internally, usually created by splitting your original key in half. So, to get e.g. 256 bits of protection, you actually need to specify a 2 * 256 bits = 512 bits key.
The last piece of the puzzle is the
hash used by LUKS during key generation. Any of the
SHA-2 family (e.g. SHA512 or SHA256) would be sensible choices here.
Conclusion
Putting this together, a relatively paranoid
cryptsetup might be:
Code: Select all
# cryptsetup -v --cipher serpent-xts-plain64 --key-size 512 --hash sha512 --use-random --verify-passphrase --iter-time 2000 luksFormat <device>
for Serpent, or
Code: Select all
# cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 --use-random --verify-passphrase --iter-time 2000 luksFormat <device>
for AES.
We use the former personally on all our home B3s and have never experienced any disk performance issues (but YMMV, if your processor is particularly loaded most of the time with other tasks, for example). Of course, follow all local laws etc. when setting up an encrypted system.
I have some other comments about LUKS setup in my Gentoo Wiki setup guide
here (this is oriented towards users setting up a PC, but there are some useful references etc. in the text).
Finally, as with all things crypto, it is best to keep a sense of perspective... if a TLA
really wanted your data (credit:
xkcd):
^-^
Best, sakaki
PS any reference to 'text' in the above is purely in the cryptographic sense and does not imply e.g. ASCII - it could be any binary payload e.g. machine code.