2x+ speedup would assume that all you do is just doing encryption/decryption while in most cases crypto would use only a small percentage of cpu time anyways. So if - let's say 1% of cpu time is spent on crypto, then that 2x gain translates to .5% overall speedup. On the other hand I do understand that this % varies a lot depending on what software/system you look at
I assume we all understand that in this thread, when we talk about performance increases, we mean of the ciphers themselves. "Crypto performance doesn't matter" is a coherent argument, if you want to make it, but if crypto performance does matter, a 2x boost is obviously material.
"We could have doubled the speed of this hash if we had been more rigorous about security margins" seems clearly to be a powerful claim. Especially since performance is in reality a pretty huge part of how we choose the cipher designs we standardize.
>"Crypto performance doesn't matter"
the argument I was trying to make is more in the sense "is it worth to take (even a minimal) risk optimizing performance given that this very performance gain is not (that) important overall"
That being said, I do understand that there are a lot of areas where performance/energy budget is tight and this actually makes a (huge) difference
Encryption is about 33% CPU at 100Gbit/s TLS https://2019.eurobsdcon.org/slides/Kernel%20TLS%20and%20TLS%... though at that speed memory bandwidth is more of a constraint
Can you say more about what you believe the "debate" about key size and number of rounds to be? A pretty important point Aumasson seems to be trying to make here is that the reduced-round analytic results against ciphers are arguments in favor of their fundamental strength, not signs that they're teetering on a precipice of insecurity.