2014-11-25 11:30 GMT+01:00 Liu Bo <bo.li....@oracle.com>: > On Mon, Nov 24, 2014 at 11:34:46AM -0800, John Williams wrote: >> On Mon, Nov 24, 2014 at 12:23 AM, Holger Hoffstätte >> <holger.hoffstae...@googlemail.com> wrote: >> >> > Would there be room for a compromise with e.g. 128 bits? >> >> For example, Spooky V2 hash is 128 bits and is very fast. It is >> noncryptographic, but it is more than adequate for data checksums. >> >> http://burtleburtle.net/bob/hash/spooky.html >> >> SnapRAID uses this hash, and it runs at about 15 GB/sec on my machine >> (Xeon E3-1270 V2 @ 3.50Ghz) > > Thanks for the suggestion, I'll take a look. > > Btw, it's not in kernel yet, is it? >
The best option would be blake2b, but it isn't implemented in the kernel. It is not a problem to use it locally (I can upload the code stripped for usage in kernel). from https://blake2.net/ Q: Why do you want BLAKE2 to be fast? Aren't fast hashes bad? A: You want your hash function to be fast if you are using it to compute the secure hash of a large amount of data, such as in distributed filesystems (e.g. Tahoe-LAFS), cloud storage systems (e.g. OpenStack Swift), intrusion detection systems (e.g. Samhain), integrity-checking local filesystems (e.g. ZFS), peer-to-peer file-sharing tools (e.g. BitTorrent), or version control systems (e.g. git). You only want your hash function to be slow if you're using it to "stretch" user-supplied passwords, in which case see the next question. https://blake2.net/ https://github.com/floodyberry/blake2b-opt Best regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
