On Fri, Jun 16, 2017 at 6:24 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > And while I am really thankful that Adam chimed in, I think he would agree > that BLAKE2 is a purposefully weakened version of BLAKE, for the benefit > of speed That is correct. Although worth keeping in mind that the analysis results from the SHA-3 process informed this rebalancing. Indeed, NIST proposed[1] to do the same with Keccak before stamping it as SHA-3 (although ultimately did not in the context of public feeling in late 2013). The Keccak team have essentially done the same with K12. Thus there is evidence of a fairly widespread belief that the SHA-3 parameters were excessively cautious. [1] https://docs.google.com/file/d/0BzRYQSHuuMYOQXdHWkRiZXlURVE/edit, slide 48 > (with the caveat that one of my experts disagrees that BLAKE2b > would be faster than hardware-accelerated SHA-256). The numbers given above for SHA-256 on Ryzen and Cortex-A72 must be with hardware acceleration and I thank Brian Carlson for digging them up as I hadn't seen them before. I suggested above that BLAKE2bp (note the p at the end) might be faster than hardware SHA-256 and that appears to be plausible based on benchmarks[2] of that function. (With the caveat those numbers are for Haswell and Skylake and so cannot be directly compared with Ryzen.) K12 reports similar speeds on Skylake[3] and thus is also plausibly faster than hardware SHA-256. [2] https://github.com/sneves/blake2-avx2 [3] http://keccak.noekeon.org/KangarooTwelve.pdf However, as I'm not a git developer, I've no opinion on whether the cost of carrying implementations of these functions is worth the speed vs using SHA-256, which can be assumed to be supported everywhere already. Cheers AGL