Native Encryption for ZFS on FreeBSD CFT
Matthew Macy
mmacy at freebsd.org
Wed Aug 22 22:39:31 UTC 2018
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
>>
>>
>>
More information about the freebsd-current
mailing list