Hacker News Reader

Comment by ebiederm | Hacker News Reader

I am not up to speed on these new algorithms. I still remember there was a light weight cryptography algorithm a few years ago championed by the NSA that had a subtle (possibly deliberate) flaw in it.

When dealing with cryptography it is always necessary to remember cryptography is developed and operates in an adversarial environment.

View on HN

Speck? To my knowledge there aren't any serious flaws despite a lot of public cryptanalysis. I think what sank Speck was that it came out a few years after after the Dual_EC_DRBG fiasco and nobody was ready to trust an NSA developed cipher yet - which is fair enough. The NSA burned their credibility for decades with Dual_EC_DRBG.

Speck uses less resources to implement and is faster when I have tested it to compared ASCON.

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

I mean, yeah, but also Simon and Speck aren't as good as the new generation of low-footprint designs like Ascon and Xoodyak. We know more about how to do these things now than we did 15 years ago.

In what ways is it better? Security margin or something? I thought Speck has held up pretty well to cryptanalysis (unlike you I'm not in the security field so maybe I'm wrong).

I quite liked the remarkable simplicity of Speck. Performance was better than Ascon in my limited testing. It seems like it should be smaller on-die or in bytes of code, and with possibly lower power consumption. And round key generation was possible to compute on-the-fly (reusing the round code!) for truly tiny processors.

Makes sense! Also, how does Speck fare in power analysis side channel attacks vs Ascon? My understanding was that was also one of the NIST criteria.

I am way out of my depth both on power consumption and leakage, but presumable Ascon does better on both counts than Chapoly.

Realy ChaCha seems trivially implementable without leaking anything.

Reply on news.ycombinator.com