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 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:
- make a raw dd copy of the entire filesystem
- change filesystem UUID
- 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
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 :-}