Re: Native Encryption for ZFS on FreeBSD CFT

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