> A major point of discussion when NIST announced the SHA3 finalist being Keccak back in ~2012(?) was that BLAKE1 at the time offered significantly better software performance
IIRC, Keccak had a smaller chip area than Blake. Hardware performance is more important than software performance if the algorithm is likely to be implemented in hardware, which is a good assumption for a NIST standard. Of course, SHA3 hasn't taken off yet but that's more to do with how good SHA2 is.
> BLAKE1 family is still considered secure today, its internal HAIFA design is very close to existing known designs like Merkle–Damgård, it isn't some radically new thing.
Given that the purpose of the competition was to replace SHA2 if/when it is weakened, choosing a similar construction would not have been the right choice.
> Hardware performance is more important than software performance if the algorithm is likely to be implemented in hardware
I don't think that's necessarily a given at all, but I grant that's mostly a matter of opinion I guess.
> Given that the purpose of the competition was to replace SHA2 if/when it is weakened
I think the dirty secret hiding there is that I see very few actual expectations SHA2 will ever be broken. Assuming it can be and picking a different secure construction, of course, is a good idea. But even the designers of BLAKE have admitted such and so did NIST.
IIRC, Keccak had a smaller chip area than Blake. Hardware performance is more important than software performance if the algorithm is likely to be implemented in hardware, which is a good assumption for a NIST standard. Of course, SHA3 hasn't taken off yet but that's more to do with how good SHA2 is.
> BLAKE1 family is still considered secure today, its internal HAIFA design is very close to existing known designs like Merkle–Damgård, it isn't some radically new thing.
Given that the purpose of the competition was to replace SHA2 if/when it is weakened, choosing a similar construction would not have been the right choice.