2
1
I have encrypted my root partition with dm-crypt/LUKS/cryptsetup on Ubuntu 12.04.
Since it uses PBKDF2:
I'd like to make it a little harder to brute-force :)
Naftuli Kay
Posted 2014-06-09T18:11:20.027
Reputation: 8 389
3
Is it possible, during creation of the encrypted disk, to specify a custom amount of PBKDF2 iterations for key derivation?
Yes. You can use the -i switch of cryptsetup to specify the iteration count. You can also use --iter-time to specify a time in seconds to benchmark the iteration count to achieve a certain execution time on your system.
Is it possible, after the encrypted disk has already been created, to modify the amount of PBKDF2 iterations for key derivation?
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.
Polynomial
Posted 2014-06-09T18:11:20.027
Reputation: 1 339
1Why 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. – Gilles 'SO- stop being evil' – 2014-06-09T19:09:44.167
@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 – 2014-06-09T19:14:57.740
2Plausible 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. – Gilles 'SO- stop being evil' – 2014-06-09T19:35:23.153
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. – Gilles 'SO- stop being evil' – 2014-06-09T19:36:21.773
I'm not trying to say that it's necessary, I'm saying that they chose it for their security model and had some reasons which they felt were solid. I don't see anything insecure about their model, so I won't say it's wrong. It may not offer much but it does err on the side of caution. – Polynomial – 2014-06-09T19:45:41.223
@Gilles, that's exactly what I'm trying to compete against (ie: I could care less that key derivation takes 10 seconds on my machine, as I really only need to enter my disk encryption key once, whereas someone trying to bruteforce would hate a 10 second delay). – Naftuli Kay – 2014-06-09T21:21:15.797
@Polynomial why would not re-encrypting the volume mean that I would lose plausible deniability? Perhaps that belongs in another question. – Naftuli Kay – 2014-06-09T21:21:56.003
1@NaftuliTzviKay You would not lose plausible deniability, since you never had it in the first place. – Gilles 'SO- stop being evil' – 2014-06-09T21:23:09.817