On Wed, Aug 22, 2018 at 12:30 PM Sean Fagan <sef_at_ixsystems.com> wrote: > On Aug 21, 2018, at 8:16 PM, Alan Somers <asomers_at_freebsd.org> wrote: > > > > > The last time I looked (which was a long time ago), Oracle's ZFS > encryption looked extremely vulnerable to watermarking attacks. Did > anybody ever fix that? > > This is the comment about dedup in zio_crypt.c: > > * CONSIDERATIONS FOR DEDUP: > * In order for dedup to work, blocks that we want to dedup with one > another > * need to use the same IV and encryption key, so that they will have the > same > * ciphertext. Normally, one should never reuse an IV with the same > encryption > * key or else AES-GCM and AES-CCM can both actually leak the plaintext of > both > * blocks. In this case, however, since we are using the same plaintext as > * well all that we end up with is a duplicate of the original ciphertext > we > * already had. As a result, an attacker with read access to the raw disk > will > * be able to tell which blocks are the same but this information is given > away > * by dedup anyway. In order to get the same IVs and encryption keys for > * equivalent blocks of data we use an HMAC of the plaintext. We use an > HMAC > * here so that a reproducible checksum of the plaintext is never > available to > * the attacker. The HMAC key is kept alongside the master key, encrypted > on > * disk. The first 64 bits of the HMAC are used in place of the random > salt, and > * the next 96 bits are used as the IV. As a result of this mechanism, > dedup > * will only work within a clone family since encrypted dedup requires use > of > * the same master and HMAC keys. > > (So, same issue. I don’t think encryption and deduplication should live > together, > so I would not have made that choice.) > > Sean. > 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. -AlanReceived on Wed Aug 22 2018 - 17:46:31 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:17 UTC