On Wednesday,2009-11-04, at 7:04 , Darren J Moffat wrote:
The SHA-256 is unkeyed so there would be nothing to stop an
attacker that can write to the disks but doesn't know the key from
modifying the on disk ciphertext and all the SHA-256 hashes up to
the top of the Merkle tree to the
Nicolas Williams wrote:
On Tue, Nov 03, 2009 at 07:28:15PM +, Darren J Moffat wrote:
Nicolas Williams wrote:
Interesting. If ZFS could make sure no blocks exist in a pool from more
than 2^64-1 transactions ago[*], then the txg + a 32-bit per-transaction
block write counter would suffice.
Zooko Wilcox-O'Hearn wrote:
Dear Darren J Moffat:
I don't understand why you need a MAC when you already have the hash of
the ciphertext. Does it have something to do with the fact that the
checksum is non-cryptographic by default
(http://docs.sun.com/app/docs/doc/819-5461/ftyue?a=view ),
Dear Darren J Moffat:
I don't understand why you need a MAC when you already have the hash
of the ciphertext. Does it have something to do with the fact that
the checksum is non-cryptographic by default (http://docs.sun.com/app/
docs/doc/819-5461/ftyue?a=view ), and is that still true?
On Fri, 30 Oct 2009, Darren J Moffat wrote:
The SHA256 checksums are used even for blocks in the pool that aren't
encrypted and are used for detecting and repairing (resilvering) block
corruption. Each filesystem in the pool has its own wrapping key and
data encryption keys.
Due to some
On Sun, Nov 01, 2009 at 10:33:34PM -0700, Zooko Wilcox-O'Hearn wrote:
I don't understand why you need a MAC when you already have the hash
of the ciphertext. Does it have something to do with the fact that
the checksum is non-cryptographic by default (http://docs.sun.com/app/
For the encryption functionality in the ZFS filesystem we use AES in CCM
or GCM mode at the block level to provide confidentiality and
authentication. There is also a SHA256 checksum per block (of the
ciphertext) that forms a Merkle tree of all the blocks in the pool.
Note that I have to
