Native Encryption for ZFS on FreeBSD CFT

[Alan Somers]

Only encrypting L0 blocks also leaks a lot of information.  That means
that, if encryption is set to anything but "off", watermarking attacks will
still be possible based on the size and sparsity of a file.  Because I
believe that with any encryption mode, ZFS turns continuous runs of zeros
into holes.  And I don't see anything in zio_crypt.c that addresses that.
-Alan

On Wed, Aug 22, 2018 at 1:23 PM Sean Fagan <sef at ixsystems.com> wrote:

> On Aug 22, 2018, at 12:20 PM, Alan Somers <asomers at freebsd.org> wrote:
> > ]That doesn't answer the question about what happens when dedup is
> turned off.  In that case, is the HMAC still used as the IV?  If so, then
> watermarking attacks are still possible.  If ZFS switches to a random IV
> when dedup is off, then it would probably be ok.
>
> From the same file:
>
>  * Initialization Vector (IV):
>
>  * An initialization vector for the encryption algorithms. This is used
> to
>  * "tweak" the encryption algorithms so that two blocks of the same data
> are
>  * encrypted into different ciphertext outputs, thus obfuscating block
> patterns.
>  * The supported encryption modes (AES-GCM and AES-CCM) require that an IV
> is
>  * never reused with the same encryption key. This value is stored
> unencrypted
>  * and must simply be provided to the decryption function. We use a 96 bit
> IV
>  * (as recommended by NIST) for all block encryption. For non-dedup blocks
> we
>  * derive the IV randomly. The first 64 bits of the IV are stored in the
> second
>  * word of DVA[2] and the remaining 32 bits are stored in the upper 32
> bits of
>  * blk_fill. This is safe because encrypted blocks can't use the upper 32
> bits
>  * of blk_fill. We only encrypt level 0 blocks, which normally have a fill
> count
>  * of 1. The only exception is for DMU_OT_DNODE objects, where the fill
> count of
>  * level 0 blocks is the number of allocated dnodes in that block. The
> on-disk
>  * format supports at most 2^15 slots per L0 dnode block, because the
> maximum
>  * block size is 16MB (2^24). In either case, for level 0 blocks this
> number
>  * will still be smaller than UINT32_MAX so it is safe to store the IV in
> the
>  * top 32 bits of blk_fill, while leaving the bottom 32 bits of the fill
> count
>  * for the dnode code.
>
>
> Sean
>
>
>