A factor of 2x+ speedup isn't "not much to be gained", but the point again is just to be more rigorous about the security margins we're trying to get.

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.

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

After differential cryptanalysis we are mostly out of ideas.

How true is this (I have no idea)? And to the extent it is, how valid would it be to draw a comparison to the security of software, saying something like "after out-of-bounds writes, we're mostly out of ideas on how to get RCE out of C programs"? There are a lot of extensions to basic differential cryptanalysis.

Seems like a tough comparison to make given the security of a cryptosystem is a lot better defined than that of a program, even in a constrained case like 'RCE in a C program'.

It might be, I don't know. In practice (that is, in carrying out cryptographic attacks on real systems), nobody ever cryptanalyzes ciphers, so I've hardly studied block cipher cryptanalysis at all; someone much smarter than me gave me a purely linear block cipher once and I didn't spot it (plus side: now I can break purely linear ciphers! make a bunch of them! put them in JWT!), so this stuff is generally over my pay grade, though I have cryptopals exercises for basic linear and differential cryptanalysis tee'd up.

But I'm just noticing how many named cryptanalytic techniques, like Boomerang, Impossible Differential, even I guess to an extent Slide, are really extensions of Matsui and Biham and Shamir. And that's true of C/C++ software too: most attacks seen in the wild are derivatives of just a couple basic techniques ("out of bound write" is obviously putting my thumb on the scale, but "buffer overrun", "integer mishandling", and "use after free" cover a pretty good fraction of all attacks on memory safety).

Which is all to say: "we've had no good ideas since differential" might not be as meaningful as it sounds? Or maybe it is. Sometimes the best way to get good information into a message board thread is to add bad information, and, in theoretical cryptography, I contribute that ably!

I don't really know either, I'm just pedentipointing out that the security of one of these things is an actual number, measurable in bits and this fact makes Aumasson's argument possible to begin with.

The 'security' of any program even in relatively constrained cases is woolier. Is a C program that can't write to executable memory at all but can allow the interpretation and execution of some language it happens to interpret vulnerable to RCE, etc. So if there is a parallel of some sort, it seems to me it could only be a narrative one.

Analysis of security of arbitrary programs is in its infancy, we can't quantify anything yet. I think the best we have is halvarflake's provable unexploitability [1] and that is very weak.

1 - https://ieeexplore.ieee.org/document/8226852

But keep in mind that other parties knew about differential cryptanalysis 15 years+ before publication.

In fairness there isn't that many people that work on cryptanalysis, at least in the public sphere.

I think there are actually rather a lot of them.

When I look at the number of papers published, the number of courses offered, professors, or companies, it doesn't seem like the cryptanalysis field is particularly big.