Calamares Installer Adds LUKS Encryption Support

[stikonas]

What are you talking about? I’ve never seen any encryption option in any BIOS.

Some drives have hardware encryption possibility. But then you have to trust that chip. Here (cryptsetup+dmcrypt) source code is open for inspection...

[stikonas]

What distributions use the Calamares installer?

Manarjo Linux based on Arch Linux.
Sabayon Linux based on Gentoo Linux.

Any other?

The full list of distributions that use Calamares can be found here: https://calamares.io/about/

[FuturePilot]

It's not really safe, enabling TRIM might leak e.g. what filesystem is used inside and maybe some other info... In principle enabling TRIM is just adding some options to crypttab/fstab. But we won't be doing this by default in Calamares/KDE Partition Manager.

By the way, Calamares actually uses full system encryption. And by full I mean including /boot.

How would any information leak if the entire disk is encrypted? Once you close the volume all you see is encrypted data.

Also please can you share how you were able to also encrypt /boot? I've been wanting to set up full disk encryption but I don't like the idea of having an LVM layer in there that is absolutely useless on a single disk setup. And I don't like having a separate unencrypted /boot. I've been using Ecryptfs but I've found that some data can get leaked to /tmp and /var in certain cases. I'd rather just do a full disk LUKS setup.

[stikonas]

How would any information leak if the entire disk is encrypted? Once you close the volume all you see is encrypted data.

Also please can you share how you were able to also encrypt /boot? I've been wanting to set up full disk encryption but I don't like the idea of having an LVM layer in there that is absolutely useless on a single disk setup. And I don't like having a separate unencrypted /boot. I've been using Ecryptfs but I've found that some data can get leaked to /tmp and /var in certain cases. I'd rather just do a full disk LUKS setup.

TRIM is passed through, so empty inside encrypted container will still be empty space if TRIM is enabled. Then you can compare it with patterns of empty space of various file systems.

Well, you just don't create a separate /boot partition to encrypt /boot. GRUB2 supports both LUKS and LVM2, i.e. for LUKS you add GRUB_ENABLE_CRYPTODISK=y to grub configuration. There is a small issue that you will have to reenter password once kernel boots. There is a workaround for this though. You just need to pass passphrase from grub to kernel. And while one might think grub doesn't do that, actually grub passes the whole initramfs to kernel. So you can include luks keyfile that is able to unlock your luks volume inside initramfs. Just make sure you have the right permissions, so random users wouldn't be able to read initramfs with that unlocking keyfile.

[starshipeleven]

Can somone explain to me the point of using encryption software instead of old fashioned bios based drive encryption.
Is seems that no one uses that anymore, even though it's available everywhere

BIOS only provides access passwords. If I remove the hard drive and place it in another PC I can read it.

Encryption is different, even if you move the drive to another PC you must give the password to read it (and have the other PC configured to decrypt the disk at all, like with GRUB or whatever)

[garegin]

I think you misunderstood. The hdd passwords actually do encryption on the drive. If you remove the drive and connect to another pc, the encryption still remains. Almost all computers support drive encryption from the bios menu.

https://en.m.wikipedia.org/wiki/Hardware-based_full_disk_encryption

[Luke]

It's not really safe, enabling TRIM might leak e.g. what filesystem is used inside and maybe some other info... In principle enabling TRIM is just adding some options to crypttab/fstab. But we won't be doing this by default in Calamares/KDE Partition Manager.

By the way, Calamares actually uses full system encryption. And by full I mean including /boot.

Using TRIM can reveal the type of filesystem used and exact size and position of files. If you need to conceal files of known length, as in a data smuggling machine or one containing files you did not create yourself (or have ever published) and must be able to deny posession of, you must not use TRIM on that partition but could use it on others. If you need to deny the existance of an encrypted partition then you should not use it on any partition.

In the case of some older ciphers it can be posssible to write to a file whose exact position and plaintext are known, thus allowing installation of malicious replacements without being able to unlock the drive. That doesn't work if the binaries are of unknown size(as with locally built files), have been moved around with other exact same-size files on the system, etc. It also does not work at all with the current XTS cipher, one of the reasons it was adopted. It's also much more difficult than installing a malicious replacement for GRUB in the totally encrypted disk case, or to your initramfs in the unencyrpted /boot case.

TRIM also has an advantage in security: when TRIM is used, all parts of deleted files that are not on a block that went read-only at the exact wrong time are totally destroyed, many forensic computer experts consider SSD's and TRIM a bigger problem than encryption itself due to widespread usage. If you have files whose plaintext is known to nobody else, whose lengths and positions need not be kept secret, and which sometimes require secure deletion (like say, meeting notes),
TRIM adds a second layer of defense by making most (maybe not all) of that deleted data all the way gone even if an adversary cracks your encryption by say, a dictionary attack on a weak passphrase.

Encryption /boot has an advantage and a disadvantage: Advantage is that the "evil maid" software keylogger is blocked unless inserted into GRUB itself. Disadvantage is that this transfers trust from your initramfs to the normally closed firmware keyboard driver used at boot time. Coreboot systems are the exception: in that case encrypting GRUB makes the machine more secure, possibly a lot more secure.

Firmware attacks are MORE common than that "evil maid" software attack, as the latter requires prior knowledge of the target. The NSA chooses this mode of attack when computers being shipped to adversaries like the Chinese military are intercepted in transit. More common yet are hardware keyloggers, more easily installed and requiring no advance knowledge of the target but much more easily found. On a laptop, gluing down the keyboard can be enough to block that attack if the keyboard can only be removed in pieces. On a desktop, the "cheap and common" attack would be a USB keylogger plugged into the back of the machine between keyboard and USB port in the hope that nobody ever looks there. Also the use of a wireless keyboard will expose your passphrase and everything else.

[anarki2]

The concern regarding FDE is never of performance, it's recovery.

[starshipeleven]

I think you misunderstood. The hdd passwords actually do encryption on the drive. If you remove the drive and connect to another pc, the encryption still remains. Almost all computers support drive encryption from the bios menu.
https://en.m.wikipedia.org/wiki/Hard...isk_encryption

Must be well-hidden in most devices I own and see, I remember only corporate stuff having encryption options in BIOS. I only have access passwords.

Anyway, I prefer software encryption. I suspect that too many vendors fuck with hardware encryption and I'm not looking forward to searching for the EXACT SAME device to read my data in case of hardware failure (similar to hardware or soft-RAID cards)