Its slowness in software and quickness in hardware have almost nothing to do with it being sponge-based, but are caused by the Boolean functions executed by the Keccak algorithm, which are easy to implement in hardware, but need many instructions on most older CPUs (but much less instructions on Armv9 CPUs or AMD/Intel CPUs with AVX-512).

The sponge construction is not inherently slower than the Merkle–Damgård construction. One could reuse the functions iterated by SHA-512 or by SHA-256 and reorganize them to be used in a sponge-based algorithm, obtaining similar speeds with the standard algorithms.

That is not done because for the sponge construction it is better to design a mixing function with a single wider input instead of a mixing function with 2 narrower inputs, like for Merkle–Damgård. Therefore it is better to design the function from the beginning for being used inside a sponge construction, instead of trying to adapt functions intended for other purposes.

Well, no. If you can do 1 AES block per second, that's a throughput of a blazing fast 16 bytes per second.

I know that's a pathological example, but I do understand your point - a typical workload on an MCU won't have to do much more than encrypt a few kilobytes per second for sending some telemetry back to a server. In that case, sure: ChaCha20-Poly1305 and your job is done.

However, what about streaming megabytes per second, such as an uncompressed video stream? In that case, lightweight crypto may start to make sense.

The monetary cost is most likely not the problem. Tacking on significant additional work is bound to consume more power and generate heat. Tiny devices often have thermal and power limits to consider.

Hardware capabilities vary widely; there isn't one optimal algorithm that fits (or, in the case of MCUs, is even viable) on every platform.

What's worse, efforts to shoehorn front-line mainstream constructions onto MCUs often result in insecure implementations, because, especially without hardware support (like carryless multiplication instructions), it's very difficult to get viable performance without introducing side channels.

Depends on what you mean by "performance". It could be latency: high frequency traders (HFTs) could probably be happy if their order data is protected for "only" an hour if it means dropping latency from (e.g.) 42 nanoseconds down to 24.

An hour ago for some trading platforms is stale as a decade ago.

I think the biggest problem is how they went about trying standardize it back in the day.

That is not even remotely significant. Facebook spends 25% (1 out of every 4) of my CPU cycles on tracking. Pretty much anything else they optimize (are they still using python and php?) Will have a bigger impact.

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.

It is intended only for microcontrollers embedded in various systems, e.g. the microcontrollers from a car or from a robot that automate various low-level functions (not the general system control), or from various sensors or appliances.

It is expected that the data exchanged by such microcontrollers is valuable only if it can be deciphered in real time.

If an attacker would be able to decipher the recorded encrypted data by brute force after a month, or even after a week, it is expected that the data will be useless. Otherwise, standard cryptography must be used.

"Lightweight" cryptography is not intended for something as powerful as a smartphone, but only for microcontrollers that are embedded in small appliances, e.g. sensors that transmit wirelessly the acquired data.