Manual Full System Encryption has been updated and simplified

[Paddy Landau]

Thanks, 3-david-o. That was useful information indeed.

The default iteration time for cryptsetup is 2 seconds. On my machine, for SHA512, this works out at 0.9 to 1.5 million iterations (depending, I suppose, on what was happening on the machine at the time).

If the decrypt time is, like yours, ten times slower, my decryption of roughly half a minute fits your observations.

I could allow the iteration time to be specified as part of the encryption script, although I worry that doing so would reduce security if people chose (as you have) just ½ second or even less.

[3-david-o]

... I could allow the iteration time to be specified as part of the encryption script, although I worry that doing so would reduce security if people chose (as you have) just ½ second or even less.

There's certainly an impact on security, which is why I mentioned that, and linked to a more authoritative document on the matter. But reducing the iter-time by a (mere) factor of 10 can be more than compensated for by making the passphrase 1 character longer - and typing one more character is likely to be quicker than waiting 20 seconds for a million hashing iterations.

According to the aforesaid document, if you have an iteration count of 100K (which is what I get on my machine with an iter-time of 100ms), and a 12-character passphrase composed of randomly-chosen letters, digits and punctuation, then a brute-force attacker would need to spend $20 TRILLION to find your passphrase. I think that's pretty secure.

I think that the bigger problem with allowing the iter-time to be specified as part of the encryption script is that people wont know, in advance, what would be a suitable value to specify. It so much depends on their hardware. So, it isnt until you've completed the encrypted installation and rebooted that you'll find out how long you need to wait when you boot. And, if you discover it is unreasonably long, then it would be daft to go though the whole installation process all over again simply to revise the iter-time. A much simpler approach would be to provide a utility script that allows it to be adjusted, following the steps I mentioned before (and providing suitable warnings about security). Obviously the process could be improved by prompting for the passphrase just a couple of times to begin with, and then passing it in as an argument to the other commands as required.

[Paddy Landau]

There's certainly an impact on security…

Thanks for the link to the article. It's already a bit outdated (such is the speed of technology change!), but a good article nonetheless.

I understand what you say about the importance of the quality of the passphrase, and using SHA512 rather than the default SHA256, thereby allowing the iterations to be decreased. (The encryption script uses SHA512.)

When I have time, which might not be for a long while, I'll look at adding iteration-time to the script.

[archphoenix]

Hello, looking at your scripts, it looks like you create an encryption keyfile (everything okay there) but copy it to initramfs later on.
What will protect the keyfile once stored on initramfs? Did I miss an initramfs encryption part? If so, how do it gets decrypted?

[Paddy Landau]

… it looks like you create an encryption keyfile (everything okay there) but copy it to initramfs later on.

If I'm doing that, it's a big mistake! Can you point out where exactly this happens, please, because it certainly isn't intentional.

EDIT: I presume you specifically mean that it's copied to the EFI partition, because everything else is encrypted.

[C.S.Cameron]

Does this mean that Full disk encryption is now working with Full installs to flash drive?
That would sure be a boost for bootable pendrive security.

[archphoenix]

If I'm doing that, it's a big mistake! Can you point out where exactly this happens, please, because it certainly isn't intentional.

EDIT: I presume you specifically mean that it's copied to the EFI partition, because everything else is encrypted.

"cp /etc/crypt.system "${DESTDIR}"/etc/"
line 1481
Part of "/etc/initramfs-tools/hooks/loadinitramfskey.sh"

If this is only copying to EFI partition, then EFI partition must be on removable media, but I don't see mentions of EFI in this part.

[Paddy Landau]

Does this mean that Full disk encryption is now working with Full installs to flash drive?
That would sure be a boost for bootable pendrive security.

It has worked in my test. However, because of varying hardware and lack of support from Canonical, I can't guarantee that it will work for you. I wish that I could guarantee it!

[Paddy Landau]

"cp /etc/crypt.system "${DESTDIR}"/etc/"
line 1481
Part of "/etc/initramfs-tools/hooks/loadinitramfskey.sh"

If this is only copying to EFI partition, then EFI partition must be on removable media, but I don't see mentions of EFI in this part.

That's fine. The folder /etc is on the system partition, so to access crypt.system, you would have had to decrypt the system partition anyway. It's not on the EFI System Partition (ESP).

[archphoenix]

Then i fail to understand why one would copy a file from etc to itself, as the source of the copy is already there.