1

I'm using ext4 encryption. https://wiki.archlinux.org/index.php/Ext4#Using_file-based_encryption

Before I decrypt a directory, I can see lots of encrypted filenames in it.

I would like to copy the encrypted files so that I can decrypt them on a different machine.

I could do this with ecryptfs. How do I do this with ext4 encryption.

5

You can see encrypted & padded filenames, but you should be unable to read file contents. So trying to copy the files unencrypted will result in errors such as:

cp: cannot open 'vault/YgI8PdDi8wY33ksRNQJSvB' for reading: Required key not available

So you are pretty much not supposed to do this. The practical answer is to decrypt it, then copy it. The copy will be re-encrypted if you picked an encrypted location as the target directory. Over the network with rsync/ssh the transfer will be encrypted also. So most things work, just storing it in the cloud is probably out of the question. Filesystem specific encryption does not work outside of the filesystem.

Circumventing the read barrier is not sufficient: unlike ecryptfs where all metadata is regular files, the ext4 encryption involves metadata hidden in the filesystem itself, not visible to you, so you cannot easily copy it.

The closest I found is e4crypt get_policy, e4crypt set_policy which allows you to encrypt a directory with an existing key without knowing the actual key in clear text. But it only works for empty directories, not for files.

You can also encrypt a vault directory, populate it with files, then hardlink those files to the root directory, then delete the vault directory. You end up with encrypted files (contents) in the root directory (which you are not supposed to be able to encrypt). The filesystem just knows that the file is encrypted. (Not recommended to actually do this.)


If you must make a copy anyway, I guess you can do it the roundabout way:

  1. make a raw dd copy of the entire filesystem
  2. change filesystem UUID
  3. delete the files you didn't want

Otherwise I guess you'd need a specialized tool that knows how to replicate an encrypted directory + metadata from one ext4 filesystem to another, but I didn't see a way to do so with e4crypt or debugfs.


debugfs in particular seems to be devoid of policy / crypt related features except for ls -r which shows encrypted filenames in their full glory as \x1e\x5c\x8d\xe2\xb7\xb5\xa0N\xee\xfa\xde\xa66\x8axY which means the ASCII representation regular ls shows is encoded in some way to be printable.

Actual filename is [padded to and actually stored in the filesystem as] 16 random bytes, but regular ls shows it as 22 ASCII characters instead. Copying such a file the traditional way would create a file stored as its ASCII character representation when you really need to store it as random bytes. So that's just bound to fail in so many layers.


tl;dr if there is a way to do it then I don't know about it :-}

  • Thanks for a comprehensive answer. – fadedbee Jun 5 at 12:38
  • Just to expand on the "copy to another system" comment, you can enter the key on the remote system, use ssh to coy the files (which will be encrypted over the wire), and write to a remote encrypted filesystem. Yes, the files will be in plaintext for a short time while in RAM on the source and destination, but that is no worse than using the ext4-fscyrpt files in the first place. – LustreOne Jun 7 at 19:56
  • It should also be noted that ZFS 0.8 allows doing backups (via zfs send/recv) of encrypted filesystems without having the key. The encrypted blocks are written in the target exactly as in the source, so the per-file key generation is unaffected. – LustreOne Jun 7 at 20:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.