Re: Native Encryption for ZFS on FreeBSD CFT

Hi Thomas,

Alan believes that, even with dedup disabled, the ZFS native encryption
support is vulnerable to watermarking attacks. I don't have enough exposure
to crypto to pass any judgement and was hoping that you'd share your point
of view. Thanks in advance.

-M



On Wed, Aug 22, 2018 at 12:42 PM Alan Somers <asomers_at_freebsd.org> wrote:

> 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
>>
>>
>>