On Sun, Feb 26, 2017 at 9:38 AM, brian m. carlson
<sandals@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> SHA-256:
> Common, but cryptanalysis has advanced. Preimage resistance (which is
> even more important than collision resistance) has gotten to 52 of 64
> rounds. Pseudo-collision attacks are possible against 46 of 64
> rounds. Slowest option.
> SHA-3-256:
> Less common, but has a wide security margin. Cryptanalysis is
> ongoing, but has not advanced much. Somewhat to much faster than
> SHA-256, unless you have SHA-256 hardware acceleration (which almost
> nobody does).
> BLAKE2b-256:
> Lower security margin, but extremely fast (faster than SHA-1 and even
> MD5).
>
> My recommendation has been for SHA-3-256, because I think it provides
> the best tradeoff between security and performance.
I initially was leaning towards SHA256 because of hw acceleration, but
noticed that the Intel SHA NI instructions that they've talking about
so long don't seem to actually exist anywhere (maybe the Goldmont
Atoms?)
So SHA256 acceleration is mainly an ARM thing, and nobody develops on
ARM because there's effectively no hardware that is suitable for
developers. Even ARM people just use PCs (and they won't be Goldmont
Atoms).
Reduced-round SHA256 may have been broken, but on the other hand it's
been around for a lot longer too, so ...
But yes, SHA3-256 looks like the sane choice. Performance of hashing
is important in the sense that it shouldn't _suck_, but is largely
secondary. All my profiles on real loads (well, *my* real loads) have
shown that zlib performance is actually much more important than SHA1.
Anyway, I don't think we should make the hash choice based on pure
performance concerns - crypto strength first, assuming performance is
"not horrible". SHA3-256 does sound like the best choice.
And no, we should not make extensibility a primary concern. It is
likely that supporting two hashes will make it easier to support three
in the future, but I do not think those kinds of worries should even
be on the radar.
It's *much* more important that we don't waste memory and CPU cycles
on being overly "generic" than some theoretical "but but maybe in
another fifteen years.."
Linus