I'd say "very", since files are encrypted with AES in CCM mode (by default). However, AES per se is not a guarantee, much depends on how it is implemented.
And there is this sentence in the documentation that
makesmade me wonder:
Review the following considerations when using the ZFS compression,
deduplication, and encryption properties:
When a file is written, the data is compressed, encrypted, and the checksum is verified. Then, the data is deduplicated, if possible.
When a file is read, the checksum is verified and the data is decrypted. Then, the data is decompressed, if required.
As far as I understand, for the data to be deduplicated after encryption it should be the case that two files (or two blocks of data) are identical. But with the blocks being encrypted with AES, this has either a vanishingly small probability of being true (2-128 for the default
aes-128-ccm), and therefore the time spent in deduplication checks might as well be saved altogether, or it means that two identical files will encrypt to identical encrypted files, which is only possible if the initialization vector is reused. Which is exactly what should not be done with a stream cipher, as AES in CCM mode boils down to.
On further search, however, I found that the IV constantly varies
by default we derive the IV from a combination of what dataset /
object the block is for and also when (its transaction) written
and that the deduplication algorithm is then mainly useful with clones. It is also apparent from several sources that careful consideration has been given to security issues and implementation details.
In conclusion, I believe that the encryption defaults are very secure; if you feel the need for even higher security you can employ the slower
aes-256-ccm algorithm. However,
aes-128-ccm is outside of the reach of even the most determined cracker; past a certain level of determination, however, the weak point is your FS no longer, and you need to start thinking about, say, physical security.