Hacker News Reader

Comment by shittyadmin | Hacker News Reader

There was also a series of issues found by with the encryption used by ecryptfs:

The full disk block-based (as opposed to this file-based) encryption is really the way to go if you want a good security and performance margin.

View on HN

Author of eCryptfs and EXT4 encryption chiming in.

"Series of issues?" Really? There were 3, and they were all scored "Low" by the authors for exploitability and security impact.

That said, I generally agree FDE is the way to go if your platform's constraints allow for it -- but only for security. Native EXT4 encryption will give you equal or better performance than FDE primarily because the file system metadata isn't encrypted. Which isn't to say that's a good tradeoff -- it's just the nature of the beast.

Because of performance and functionality issues (file name length, possibility of page cache inconsistency) eCryptfs shouldn't be used for anything any more.

Ah, you're right, I had it confused with a similar analysis on EncFS which had more significantly damaging findings.

https://defuse.ca/audits/encfs.htm

I wasn't even aware Ext4 had native encryption support though! I'll definitely have to give that a go. Thanks for the tip.

According to Michael Halcrow's LinkedIn [1], he was heavily involved on the EXT4 encryption:

"I was also the project lead for encryption in EXT4, which is now available as the mechanism implementing file-based encryption on Android."

[1] https://www.linkedin.com/in/michael-halcrow-1880601

There is (or at least _was_ when I last tried FDE) one major fly in this ointment: you lose the ability to reboot your machine remotely. Upon restarting it required that you enter the password, which you can only do from a local keyboard.

For such systems I consider the primary root file-system to be part of the 'bootloader'. Everything that I want to keep actually secure is inside of the encrypted PVs backing LVM volumes.

Yes, this presents a security risk in that someone could (offhand I think the term is 'evil maid'?) attack the root filesystem, but they could still have done that to the bootloader anyway.

Remote interaction is then required to bring the VMs on that system up.

They could not have done that to the bootloader because of SecureBoot.

With secureboot on Linux you can secure as much or as little as you want. On my system, grub isn't even safe, only the shim that load grub is secure. But I could set it up so the kernel is secure, have the kernel only load verified initrd, and then have the initrd check the root filesystem.

I don't, but secureboot can detect changes to the root filesystem if you want it to. I think this generally requires setting the rootfs to mount readonly.

On Debian-based systems including Ubuntu, they offer an initrd based Dropbear (lightweight SSH server) which can be used to connect and authenticate. Involved a bit of custom scripting last I checked though, but a possible solution if that's a requirement for you.

You could put a daemon on the initramfs (say, ssh) that allows you to remotely provide a key/password for decrypting the disk.

This would certainly be more work to set up than vanilla full-disk encryption, though.

Reply on news.ycombinator.com