Your parenthetical comments here raise some concerns, or at least eyebrows, with me. Hopefully you can lower them again.
> compress, encrypt, checksum, dedup. > (and you need to use zdb to get enough info to see the > leak - and that means you have access to the raw devices) An attacker with access to the raw devices is the primary base threat model for on-disk encryption, surely? An attacker with access to disk traffic, via e.g. iSCSI, who can also deploy dynamic traffic analysis in addition to static content analysis, and who also has similarly greater opportunities for tampering, is another trickier threat model. It seems like entirely wrong thinking (even in parentheses) to dismiss an issue as irrelevant because it only applies in the primary threat model. > (and the way I have implemented the IV > generation for AES CCM/GCM mode ensures that the same > plaintext will have the same IV so the ciphertexts will match). Again, this seems like a cause for concern. Have you effectively turned these fancy and carefully designed crypto modes back into ECB, albeit at a larger block size (and only within a dataset)? Let's consider copy-on-write semantics: with the above issue an attacker can tell which blocks of a file have changed over time, even if unchanged blocks have been rewritten.. giving even the static image attacker some traffic analysis capability. This would be a problem regardless of dedup, for the scenario where the attacker can see repeated ciphertext on disk (unless the dedup metadata itself is sufficiently encrypted, which I understand it is not). > (you need to understand > what I've done with the AES CCM/GCM MAC I'd like to, but more to understand what (if any) protection is given against replay attacks (above that already provided by the merkle hash tree). I await ZFS crypto with even more enthusiasm than dedup, thanks for talking about the details with us. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
