Thought I would share this with you guys. I have been using a method to strengthen or harden my LUKS headers. Many of the common debian based distro's create the volumes using only sha1 and other lower quality "math" components in the header. I am referring to FDE where an LVM on LUKS is created in simple "auto-mode" from those distro's during system install. Problem is you end up with a weaker than easily available strength. For awhile, I was doing custom expert installs just to capture the hardened headers. Now I can accept the simple generic auto install knowing I can "fix" the weakness by doing the following simple procedure. I have done this now many times without any hitches at all. Cryptsetup offers a process/command whereby you can fully re-encrypt your entire LUKS container with your data fully IN PLACE. Cryptsetup will write through your original header and then convert your data through the header's algo turning it into plain text. It then sends the plain text (in RAM) back through the new header algo and writes the encrypted data back in place on the drive. I do this process using a LIVE Disk (14.04.5) so all volumes are static on the sata. I will paste a working example. Of course you need to know all passwords during the prompts for them. In the example below the LUKS container is on sda3. # offline and CLOSED during process: Reencrypt and also change cipher and cipher mode sudo cryptsetup-reencrypt /dev/sda3 -c twofish-xts-plain64 -s 512 -h sha512 -i 9000 On a very average machine I literally just finished a 150 Gig system in about 55 minutes or so. Works great. Made backups of the new LUKS header and MBR so I am good to go. ps - I always noise fill my disks before install so this reencrypt process does the entire 150 Gig not simply the used space. You could think of this as another "pass" of wiping. In a sense it is.
According to the Arch Wiki, SHA1 is still considered secure. I think you're defaulting to SHA1 because of Debian's Jessie older cryptsetup, which even turns "--iter-time 5000" into 10 seconds instead of 5 And according to it's own FAQ, SHA1 is not vulnerable https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects Verbatim Quote: I'm currently using SHA256 (the default value for current cryptsetup) with iter-time of 5000, but I personally wouldn't mind using SHA1 at all. I guess. I'm too paranoid to say anything cryptsetup -c twofish-xts-plain64 -y -s 512 --iter-time 5000 luksFormat /dev/sda2 is all I use for my device encryption.
Guys good points. While I cannot disagree with any comments above I do feel like using the strongest available models makes sense. Now I go off on a personal thought. Another reason to perform this task is so that I can switch from aes to twofish. There was a ton of politics involved in deciding which of the three leaders (aes, serpent, twofish) would become the standard. They are all great mathematical models. I would guess that 99% of users are employing aes because that is what the DEFAULT install uses. Most users will never learn anything custom or "under the hood". Therefore it is quite logical that any adversary will spend a huge amount of time trying to defeat AES because the payoff would be virtually every user. The flip side is that taking the time to defeat twofish will yield very little. That is my take. I have studied the math and done my reading. Regarding iter time. That is not static as many imagine. The iter time on a basic home machine is slower by far than should an attack happen using some super computer. I use an iter time much higher than I posted in my example above. Iter time only affects launching my Linux OS (or should I make a mistake keying the password). I will gladly wait several seconds longer during boot, knowing when its "cold" the extreme iteration requirement provides a great brute force obstacle.
Me too. I would use Serpent instead of AES, but it's too slow. I don't think that's true, at least for me. I've set my processor to disable 4 of the 6 cores and went from 4.1 GHz to 3.0 GHz and the time between the passphrase attempt abd boot was the same: 5 seconds. And then I went to full 6 cores and a core frequency of 4.7 GHz and the time was again 5 seconds. To me, "iter time" is the TIME which iterations will be made, regardless of the computer speed. It's an iteration timer thing, not an iteration counter thing. This is different from, say, VEraCrypt, where you're actually making tons of iterations before booting. It does make sense. However, note that while AES is the most used cipher, it's also the one that receives more attention and attacks, so if it is still under heavy usage today, despite all the attack attempts, it means it's probably complete safe to use. While I too use Twofish for encryption with the same line of thought as yours, note that even Bruce (one of the creators of Twofish) said that it's possible that is has an unknown attack that wasn't discovered yet because it gets less attention. I'm still waiting for ThreeFish
Well I am banking on the relative "zero payoff" of a successful twofish attack, being the thing that actually makes it a better choice. .02!!
