As computing power grows in time and new exploits are discovered, it may be necessary to:
Change the header and/or payload encryption & hashing algorithms when they become potentially unsafe
Increase the number of password hash iterations (PBKDF2) based on the executing machine computing power
Reencrypt the header or payload with the new settings when necessary
The difficulty, when using deniable encryption, is that those header encryption settings cannot be stored with the deniable payload, or they wouldn't be deniable. However, they can be given by the user as arguments each time the volume is decrypted, or must be stored/hard-coded in the executable as default settings.
The second solution is the most practical, and that's what Truecrypt does: it stores a long list of hash algorithm+cipher+keysize+etc. mix and tries them all. But as Truecrypt has to run on most machines, even the ones with limited computing power, it unnecessarily weakens the header encryption settings so that it doesn't take forever to open a Truecrypt volume on an weak machine.
On the other hand, LUKS uses by default:
The default hash and cipher algorithms defined in a constant; This can evolve in time with newer cryptsetup versions, when the old default settings become obsolete.
A number of hash iterations computed during the volume creation, and based on the executing machine CPU computing power.
These settings are store unencrypted in the LUKS header. That's great, but not deniable.
I believe that the best solution is to use by default:
The default hash and cipher algorithms defined in a constant, dependant on cryptsetup-deluks version. When the header can't be decrypted due to cryptsetup update, cryptsetup should try the hash/cipher algorithms of previous versions and warn the user that it should reencrypt the header and/or payload with newer, safer settings.
A number of hash iterations determined during the executable compilation. This setting should be stored within cryptsetup-deluks and grub-crypto deluks executables at compilation time based on the compilation machine computing power. The user should be informed of the value of this setting (in a power of 2) everytime cryptsetup/cryptomount is run, in case the user needs to port the encrypted volume to another machine with different cryptsetup/cryptomount executables.
One last remark is that nowadays, crackers tends to use GPU or even APU instead of CPU for brute-forcing.
There are two challenges:
Find a replacement to PBKDF2-HMAC-XXX that uses 100% GPU computing power to derive a key from 1 password, and that is slow to run on CPU.
Leverage GPU power at boot time to run this algorithm and decrypt the volume key from the password. That's probably quite hard or possibly unpractical to leverage GPU power from grub.
As computing power grows in time and new exploits are discovered, it may be necessary to:
The difficulty, when using deniable encryption, is that those header encryption settings cannot be stored with the deniable payload, or they wouldn't be deniable. However, they can be given by the user as arguments each time the volume is decrypted, or must be stored/hard-coded in the executable as default settings.
The second solution is the most practical, and that's what Truecrypt does: it stores a long list of hash algorithm+cipher+keysize+etc. mix and tries them all. But as Truecrypt has to run on most machines, even the ones with limited computing power, it unnecessarily weakens the header encryption settings so that it doesn't take forever to open a Truecrypt volume on an weak machine.
On the other hand, LUKS uses by default:
I believe that the best solution is to use by default:
One last remark is that nowadays, crackers tends to use GPU or even APU instead of CPU for brute-forcing. There are two challenges: