About using encryption twice: the maintainer of ecryptfs wrote: "I use both dm-crypt and eCryptFS on my Ubuntu laptop ;-)" (although both ecryptfs and dm-crypt are part of the linux kernel. So they should be much better tested and evaluated than gocryptfs). He explains himself: "Every elevator you have ever used has redundant safety mechanisms. Your car has both seat belts and air bags. Your friendly cashier will double bag your groceries if you ask. And I bet you've tied your shoes with a double knot before.Your servers have redundant power supplies, and redundant hard drives." He wrote about Heartbleed and states that using encryption twice (like in a webservice he developed) would have prevented this disaster.

I think this view is quite rare.

The way to do it is to use eCryptFS. Use it to create an encrypted hidden sub-directory that gets mounted when you log in.

Ubuntu makes this really, really easy.

With that, you can use whatever program you want to sync the hidden encrypted eCryptFS directory. Just make sure you don't lose your private .ecryptfs directory, or else you may be left with unrecoverable files.

Ya'll might consider this:

http://ecryptfs.org/about.html

It encrypts each file on disk, and you do a sort of "loopback" mount to present the unencrypted version to the system.

The nice thing about it is you can back up the underlying filesystem (with ZFS, zfs send and everything) and the data will remain encrypted in backups too, which won't work with the LUKS method mentioned below.

ecryptfs is not associated with ZFS; it works with any filesystem. That's what we use where I work for an encrypted file share.

First of all; Awesome article. I for one is also interested in a smartcard/encryption solution and have glanced at eCryptfs as it's "per-file", easy to setup with PAM and easier for backups as opposed to LUKS "block" encryption which is extremely fast and efficient, but cumbersome. There seems to be some yubikey usage out there as well.

The easiest way to achieve that, IMO, is to just use rsnapshot but make the target backup directory encrypted, with eCryptfs or EncFS.

You're absolutely right. I got my programs confused. LUKS and ecryptfs are more on par with the functionality of TrueCrypt.

> If the topic about encrypting only /home/ is relevant here then I would need to be able to install Manjaro and rsync only /home/ without crashing system. But this would not install packages and libraries so it is useless in my case. And the backed up computer is air-gapped / offline that must be as most secured as it can.

It depends on how you ecrypt /home. If you use something like EcryptFS that stacks onto the filesystem you can simply use rsync on the whole system. Encrypted files get copied as encrypted files, which can be less efficient than with unencrypted files, but it is still lossless, and much less complicated.

> It would be much easier to insert an exploit into my system and once I would run my system afterthat this exploit would store some information. Then such a information might be send out from my computer after it got connection to internet or being transfered via pendrive or other medium if the exploit would be present also at the system I am transferring files via pendrive too

Yes, full-disk encryption protects against attacks that home-folder encryption doesn’t. But if those attacks are unlikely to happen, protecting against them isn’t necessary. Indeed, it can be counterproductive.

More generally, if you choose your security policies arbitrarily, they usually end up being either inadequate or overkill. And overkill can be just as bad as inadequate—as you’re now discovering with your backup woes.

Also, basing your threat assessment on what’s possible instead of what’s probable is a deep, deep rabbit hole that inevitably leads to never using a computer at all.

IMO. Caveat emptor.

Luks is probably overkill. It either requires you to type in a password at boot, or store the key somewhere accessible at boot time. In either case, it kinda defeats the purpose of full disk encryption if your machine just boots normally from a key stored on the drive.

You also mentioned you run on a Raspberry Pi, which means there is no hardware support for AES-NI, so encryption will be slow. Given the limited bandwidth available on the RPi you may not feel it through. I’ve tried LUKS on an Odroid HC2, which is an Octo core ARM chip with 2GB ram, and a SATA-3 port, and there is a noticeable slowdown when using LUKS.

Instead I would probably look into something like eCryptfs, and only encrypt the files that absolutely requires it.

If you do choose LUKS, it can be done in a an somewhat secure automated mode. My server uses LUKS for all data disks, and the way it mounts it is, the keys for the data disks is stored on a USB key running Btrfs “RAID1” (Single device raid, 2 copies of all files), which is encrypted as well with a key stored on the server.

When it boots, it first mounts he USB key, then uses that to mount the data disk. Dispose of the USB drive, and the disks are unreadable.

Mount an Encrypted Volume on your Synology Array

1. Create directory: mkdir /volume1/Encryption_Test
2. Mount encrypted directory, use these options when prompted --
   • AES 32-bit key
   • no plain text passthrough
   • filename encryption — you may see some errors, it is OK to ignore them
     mount.ecryptfs /volumeUSB2/usbshare/Encryption_Test/@EncryptionTest@/ /volume1/Encryption_Test/ (this is a one-liner)
3. Create Shared Folder in DSM named Encryption_Test. Set permissions appropriately.

Unmount the encrypted folder and volume

1. Unmount encrypted directory umount /volume1/Encryption_Test
2. Eject disk via DSM
3. Remove share via DSM

These instructions assume the operator has a working knowledge of how to obtain a CLI prompt on a Synology array.

If your plan is to mount the volume on a workstation, you'll need to install eCryptfs workstation and work forward from there.

This is interesting. They use http://ecryptfs.org and my understanding is the hardware acceleration for encryption where supported; and your nas seems to support “Hardware Encryption Engine (AES-NI)”

When you copy the data to the encrypted share how does cpu utilization look like? Do you see single core saturated? Or maybe disk queue goes out of hand due to non-sequential access pattern with encrypted data?

Came here to say this… it's not actually "safe" unless you're on an SSD and are using a filesystem mounted with TRIM support. You're much better off using an encrypted eCryptfs directory, IMHO. Just make sure your text editor is set up to not dump a ~/.viminfo or anything like that.