ZFS ZFS: Any practical difference between 128bit and 256bit hashes when using encrypted datasets

I am trying to understand the difference between unencrypted ZFS and natively encrypted ZFS datasets. It looks like that in an unencrypted ZFS dataset the data is checksumed with a 256 bit hash but encrypted datasets use "only" 128 bit hashes because the rest of 128 bits are needed for authentication.

Is data integrity then, in principle, worse in encrypted datasets? Does this has any practical difference, and if not, why 256 bit hashes where used in the first place?
 
I am sorry I cannot answer your question, however, I do recommend using geli + unencrypted ZFS, it's performance is much better
 
It looks like that in an unencrypted ZFS dataset the data is checksumed with a 256 bit hash but encrypted datasets use "only" 128 bit hashes because the rest of 128 bits are needed for authentication.
Where did you get that information?

This is 13.0-RELEASE, ZFS version
Code:
zfs-2.0.0-FreeBSD_gf11b09dec
zfs-kmod-2.0.0-FreeBSD_gf11b09dec

This is a encrypted test vdev named 'tank':
Code:
# zfs get encryption tank
NAME   PROPERTY     VALUE          SOURCE
tank   encryption   aes-256-gcm    -

# zfs get checksum tank
NAME   PROPERTY     VALUE          SOURCE
tank   checksum     sha512         local

See zfsprops(8) for details.
 
Where did you get that information?
Article "OpenZFS Encryption Arrives on FreeBSD", FreeBSD Journal March/April 2020:

"This unexpected feat is accomplished by splitting what was once a 256-bit hash field into a still more-
than-ample 128-bit hash juxtaposed with a 128-bit message authentication code (MAC). "
 
when I last tested portability there was an issue ... so files written in Linux could not be read in FreeBSD (on encrypted datasets)
 
-RELEASE was in April of 2021. I'd know, I was really looking forward to it at the time, and reading about how showstopper bugs delayed the release 4 times. ;)
 
Back
Top