2

This is an extension of my question on UNIX. Let's suppose I create a file, map it to /dev/loop0, and create a LUKS partition inside

dd if=/dev/zero of=myfile bs=1M count=1000
losetup /dev/loop0 myfile 
cryptsetup -c aes-cbc-essiv:sha256 -s 256 -v -y luksFormat /dev/loop0

I then open the encrypted partition

cryptsetup luksOpen /dev/loop0 myfile

Now, I have my encrypted file appear as a disk /dev/mapper/myfile. I need to create a filesystem before I can use it.

My Question:

What would be best practice in general regarding my setup. In particular, are there any filesystem options/parameters that I should change from defaults? Any suggestions as to which filesystem to use? Journal? Any other suggestions or comments?

Community
  • 1
Martin Vegter
  • 1,947
  • 4
  • 28
  • 39

2 Answers2

6

With respect to the cipher to chose -- that is aes-cbc-essiv:sha256 (the old default) versus aes-xts-plain64:sha256 (the new default) -- I've explained all this before in this answer:

How secure is Ubuntu's default full-disk encryption?

As for which filesystem to use -- obivously using a partition directly is going to give you the best performance: there's no second translation layer getting in the way between your pseudo block device and your real block device.

Since that appears to not be an option for you, then I'd recommend one of the EXT filesystems rather than one of the newer copy-on-write ones, since random-access to a large file with a COW filesystem would be messy. EXT4 is obviously the most recent and arguably most resilient of the lineage, though if you only have one large file then most of the FS features don't come in to play. So in that sense it probably doesn't matter a whole heap which filesystem you use. You're not really using the filesystem features.

As long as you allocate your file entirely at creation (as you've demonstrated in your question, as opposed to creating a sparse file), your file will be one contiguous block and the filesystem becomes largely transparent to your operation. Also, allocating your file BEFORE putting the other files on the FS will get your file closer to the start of the disk, which makes its access sometimes a bit faster.

As for security: (a) don't give out your password, (b) don't let anyone touch your computer. There's not a lot to it. Since you're running on an unsecured device, there's really no meaningful additional protection that can be put in place. If you encrypt your whole computer then perhaps you'll have something, but as it is, just be careful of how it gets used.

Community
  • 1
tylerl
  • 82,665
  • 26
  • 149
  • 230
  • It is not `aes-xts-plain64:sha256`, but simply `aes-xts-plain64` because `plain64` does not use any hash function (in contrast with `essiv`). – Mitar Nov 27 '17 at 20:27
5

From a security perspective, it is unlikely to matter what filesystem and filesystem options you use inside the encrypted loopback device. Personally I would use ext4, since it's currently the de-facto standard for Linux filesystems.

That said, I would make a couple tweaks to how you're setting up the LUKS container:

  1. Fill the file with random bytes, instead of zero bytes (replace /dev/zero with /dev/urandom). This ensures that an attacker cannot distinguish between used and unused blocks.

  2. Use xts-plain64:sha256 instead of aes-cbc-essiv:sha256, and pass -s 512 instead of -s 256. XTS is newer than CBC-ESSIV and is both more performant and possibly more secure (note that it requires double the key size for an equivalent security level).

AGWA
  • 500
  • 4
  • 5