2

I have encrypted my root partition with dm-crypt/LUKS/cryptsetup on Ubuntu 12.04.

Since it uses PBKDF2:

  1. Is it possible, during creation of the encrypted disk, to specify a custom amount of PBKDF2 iterations for key derivation?
  2. Is it possible, after the encrypted disk has already been created, to modify the amount of PBKDF2 iterations for key derivation?

I'd like to make it a little harder to brute-force :)

1 Answer 1

4

Is it possible, during creation of the encrypted disk, to specify a custom amount of PBKDF2 iterations for key derivation?

Yes. From the cryptsetup manual:

--iter-time, -i
    The number of milliseconds to spend with
    PBKDF2 password processing. This option
    is only relevant to the LUKS operations
    as luksFormat or luksAddKey. 

Specifying the -i / --iter-time allows you to choose a desired unlock time in milliseconds. It will then benchmark the iteration count to achieve a certain execution time on your exact system.

Is it possible, after the encrypted disk has already been created, to modify the amount of PBKDF2 iterations for key derivation?

LUKS1 Answer: Yes, though it's a bit of a pain. Versions of cryptsetup 1.5.0 and later come with the cryptsetup-reencrypt tool for offline re-encryption, which allows you to change the settings. From what I've read, it does a full re-encryption of the whole disk, which will take a long time. Technically it should only need to re-encrypt a new volume header, but there are security reasons for re-encrypting everything.

Update / 2021 News for LUKS2: There's now a safe, built-in cryptsetup reencrypt command which does a checksummed, resumable re-encryption which is safe against power loss. All LUKS2 disks should use the new tool since it is much safer than the old external (cryptsetup-reencrypt) tool. Check the cryptsetup man page for the new command's usage.

9
  • 2
    Why would you want to reencrypt to change the number of KDF iterations? The random key that the data is encrypted with doesn't change, only the password-derived key that's used to encrypt that key. Commented Jun 9, 2014 at 19:09
  • @Gilles I think the issue is that by changing only the header, you lose some plausible deniability about the data. I remember that TrueCrypt had a section on changing the password of an existing volume and the potential security issues.
    – Polynomial
    Commented Jun 9, 2014 at 19:14
  • 2
    Plausible deniability is not a feature that cryptsetup advertises, and is mostly useless anyway because 1. the burden on proof is usually on you to demonstrate that the data is actually random (and to make things worse, this cannot be proved without exterior knowledge) and 2. if you're going that route you can equally pretend having forgotten the password. Commented Jun 9, 2014 at 19:35
  • The usual reason to increase the number of rounds is to keep up with computer performance increases; this requires that you update all copies of the header but does not require doing anything about the key. If the key has been leaked, seeing that it's stored on the same medium as the data, then the data has usually been leaked as well. If the key has been leaked without the data, then you would need to reencrypt, but that has nothing to do with KDF iterations. Commented Jun 9, 2014 at 19:36
  • 1
    @NaftuliTzviKay You would not lose plausible deniability, since you never had it in the first place. Commented Jun 9, 2014 at 21:23

You must log in to answer this question.

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