Date: Tue, 31 May 2016 09:03:56 -0700 From: Matthew Ahrens <matt@mahrens.org> To: Allan Jude <allanjude@freebsd.org> Cc: Ivan Klymenko <fidaj@ukr.net>, "src-committers@freebsd.org" <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r301010 - in head/sys: cddl/contrib/opensolaris/common/zfs cddl/contrib/opensolaris/uts/common cddl/contrib/opensolaris/uts/common/fs/zfs cddl/contrib/opensolaris/uts/common/fs/zfs/sys ... Message-ID: <CAKUb7ithORkuyLWsOCyjg6qvjQ90_abUFgyaVM9XOW=Pw6XP0g@mail.gmail.com> In-Reply-To: <10b10f89-0212-2a9d-06ed-6477ef658962@freebsd.org> References: <201605310412.u4V4CEh4021513@repo.freebsd.org> <20160531144155.7e96c5a5@nonamehost.local> <10b10f89-0212-2a9d-06ed-6477ef658962@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 31, 2016 at 7:44 AM, Allan Jude <allanjude@freebsd.org> wrote: > On 2016-05-31 07:41, Ivan Klymenko wrote: > > On Tue, 31 May 2016 04:12:14 +0000 (UTC) > > Allan Jude <allanjude@FreeBSD.org> wrote: > > > >> Author: allanjude > >> Date: Tue May 31 04:12:14 2016 > >> New Revision: 301010 > >> URL: https://svnweb.freebsd.org/changeset/base/301010 > >> > >> Log: > >> Connect the SHA-512t256 and Skein hashing algorithms to ZFS > >> > >> Support for the new hashing algorithms in ZFS was introduced in > >> r289422 However it was disconnected because FreeBSD lacked > >> implementations of SHA-512 (truncated to 256 bits), and Skein. > >> > >> These implementations were introduced in r300921 and r300966 > >> respectively > >> This commit connects them to ZFS and enabled these new checksum > >> algorithms > >> This new algorithms are not supported by the boot blocks, so do not > >> use them on your root dataset if you boot from ZFS. > >> > > > > Hello. > > > > Tell me please, who is now the fastest of these algorithms? > > > > What remains of the available algorithms checksum algorithm by default? > > > > Thanks. > > > > None of the old checksums were removed > This means the available checksums are (from fastest to slowest): > > off (bad idea) > fletcher2 (not recommended, weak) > fletcher4 (default) > edon-r (not implemented, possibly insecure) > To be clear, all of the above are (possibly) insecure. Edon-R and fletcher4 are not used for dedup, so they doesn't need to be secure. Edon-R can be used for nop-write, which also doesn't need to be secure, it just needs to prevent accidental hash collisions (intentional ones are fine, because they only mess up the block being written, and if you can write then by definition you can arbitrarily modify the block being written). That said, even intentional collisions with Edon-R would be nontrivial, because of the secret salt. This is documented in the zpool-features manpage: edonr GUID org.illumos:edonr READ-ONLY COMPATIBLE no DEPENDENCIES none This feature enables the use of the Edon-R hash algorithm for checksum, including for nopwrite (if compression is also enabled, an overwrite of a block whose checksum matches the data being written will be ignored). In an abundance of caution, Edon-R can not be used with dedup (without verification). Edon-R is a very high-performance hash algorithm that was part of the NIST SHA-3 competition. It provides extremely high hash performance (over 350% faster than SHA-256), but was not selected because of its unsuitability as a general purpose secure hash algorithm. This implementation utilizes the new salted checksumming functionality in ZFS, which means that the checksum is pre-seeded with a secret 256-bit random key (stored on the pool) before being fed the data block to be checksummed. Thus the produced checksums are unique to a given pool, blocking hash collision attacks on systems with dedup. --matt > skein > sha512 > sha256 > > -- > Allan Jude > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKUb7ithORkuyLWsOCyjg6qvjQ90_abUFgyaVM9XOW=Pw6XP0g>