> The point this paper is trying to make is that we should be using safety margins based on knowledge rather than perpetuating the numerology that's been in-place to-date.

Exactly. The point is that a fair A/B speed comparison between competing ciphers should be normalizing both A and B to equivalent security margins. Instead, its been up to each individual cipher designer as to how many extra rounds should be used.

That said, I think the paper's point would be clearer if they had written down a complete table of "equivalent margin rounds" holding each of the standards constant. Ie, how many rounds does ChaCha need to have equivalent margin to AES-128 at its specified number of rounds?

> Exactly. The point is that a fair A/B speed comparison between competing ciphers should be normalizing both A and B to equivalent security margins

Assuming that A and B have received an equal amount of cryptanalytic attention and the "best publicly known" attacks represent equal amounts of effort/progress against the algorithm.

In practice, we need to overspecify algorithms initially, not knowing what the next 10-50 years of attacks will look like. Maybe 15 years in you go "woops, could have used fewer rounds-- we're holding up much better than I thought," but at that point the parameters are standard and...

Are you suggesting it's going to look a lot different from the previous 45 years? Because the previous 45 years suggest pretty strongly that we do in fact know how to design a block cipher.

Public knowledge of differential cryptanalysis is younger than 45 years, and was known to NSA 20+ years before its public "discovery" (and known to IBM 15 years before).

Multiple finalists in the AES competition (which selected Rijndael) had significant weaknesses found in the decade since, despite receiving relatively little attention (MARS, Serpent).

Which weaknesses are you referring to? Let's look at them the same way this paper looks at attacks on AES and Blake2.

A) debatable

B) very,very debatable, especially this piece: "understand the space well-enough"

C) I tend to agree, but then (especially with hardware-supported crypto) there is not much to be gained by reducing the number of rounds

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.

> The point this paper is trying to make is that we should be using safety margins based on knowledge rather than perpetuating the numerology that's been in-place to-date.

Yes, but we should also understand that additional computing, in most situations, is really cheap, and that compromised cryptography in wide use is inordinately expensive.

> The very same argument you're making here can be made regarding switching to 512-bit keys. And heck, why not 1024-bit keys too.

We know we need at least like 80 bits to start to be safe against brute force. 128-256 bits are reasonable "round number" sizes that have a keyspace in large multiple of this.

> A) The key size & number of rounds aren't where the security issues are today

They're a key part of the security of the thing we're actually talking about (the cryptographic algorithm) and excessive key size and number of rounds has often rendered actual algorithmic weaknesses unexploitable in the past.

> B) We have a sufficient margin of error and understand the space well-enough that we're likely OK to use existing symmetric encryption with fewer rounds & smaller key lengths.

Maybe. And again, why?

> C) If you're a target of an attack the encryption keys are unlikely to present a significant challenge as attackers will choose easier alternate vectors.

You could use this argument to make every single bit of the security stack (equally) weak.

>We know we need at least like 80 bits to start to be safe against brute force.

you could imagine a cipher with a computational/memory[0] intensity so high that the brute force attack could be practically infeasible even at lower key-sizes. I am not advocating using smaller keys, just pointing out that there is more to brute-force resistance that simply just the key-length number. (That is probably the numerology the GP was referring to)

[0]Since memory intensity instead of pure computational intensity seems to be employed by some hashing alghorithms I wonder is that would be possible block ciphers as well. The way I understand this, it makes ASIC/FPGA brute-forcing a lot harder/expensive

> you could imagine a cipher with a computational/memory[0] intensity so high that the brute force attack could be practically infeasible even at lower key-sizes. I am not advocating using smaller keys, just pointing out that there is more to brute-force resistance that simply just the key-length number.

In general, this is a dumb trade to make, because more key bits are cheap and that computation costs every user.

Things like what you describe exist-- where initial key scheduling does key stretching, etc.

> Since memory intensity instead of pure computational intensity seems to be employed by some hashing alghorithms I wonder is that would be possible block ciphers as well. The way I understand this, it makes ASIC/FPGA brute-forcing a lot harder/expensive

Anything is possible, but this often does more to hurt low-resource users than brute force also.

>but this often does more to hurt low-resource users than brute force also.

1MB memory usage would not hurt most of the low-resource users while having 1MB memory for each of the millions of computational units in a brute-force rig would hurt the attacker a lot more. I assume that it is relatively easy to have a huge number of brute-force cracking units in a simple GPU/FPGA/ASIC rig but if each of them would additionally need lets say 1MB of RAM that would present a serious problem for the constructor of such rig.

I do get that AES will happily run on a 20-year old smart-card simplified cpu without a problem while my fictional 1meg-requiring cipher would be problematic, but then again it's 2019 and 1MB is not that of a problem for the least powerful smartphones or even embedded systems.

> but then again it's 2019 and 1MB is not that of a problem for the least powerful smartphones or even embedded systems.

1MB means you basically obliterate caches and torture memory bandwidth every time you want to encrypt a tiny block. But ignoring that...

Low cost microcontrollers with 4k or 8k of RAM total are still used in embedded systems and often have hardware AES built in. Even things like ESP32 are often considered relatively big and have 520k of ram.

There are applications and services that have a million or more connected sockets with encryption at a time. This would represent a terabyte of RAM just for this 1MB block cipher scratchpad.

If one were to just use a megabyte during key scheduling or something-- that's feasible, I guess, but it still locks out a lot of the embedded world.

True but also to remember that vendors build the chips the industry demands. So if they need to provide 1MB they will - it will just mean a larger BOM unless the chip package needs to grow. The size is going to be the biggest bottleneck there.

You fixated on one bit of the argument, but if you want to discuss that: Memory on logic processes is expensive. That's why SRAM is precious on microcontrollers. Also, already the largest memory sizes require much larger than typical packages.

A microcontroller with a few megabytes of RAM to support several crypto sessions with this cipher is going to be a big cost multiple over current micros.

>C) If you're a target of an attack the encryption keys are unlikely to present a significant challenge as attackers will choose easier alternate vectors.

Absolutely true and none need look further than how the best of the best (NSA/Equation Group) handle such hurdles....they install malware on the computer to grab your keystrokes. Though I think if you have mission critical data you would be wise to never connect your machine with encrypted data to a network, ever. You need to have two machines. One which stores the encrypted data, custom built with trusted hardware. No wifi, no bluetooth, no USB, no cd rom etc.

There are other novel means to leap air gaps. I remember from a few years ago a technique using ultrasonic by, IIRC, spinning a harddrive at certain intervals and listening in from a standard PC mic.

Also, a stripped down computer like you describe is going to be of marginal utility. How do you get the sensitive data in or out? Transcribe by hand? Might as well write your secrets in a code on a piece of paper and lock it in a vault.

Airgapping by removing CD/USB/network, you arent really increasing security. Youre just freezing the machine in a point in time with no security updates or other useful means of actually handling sensitive materials. One could argue this actually makes it easier to exploit given sufficient physical access.

Also, NSA using keyloggers doesn't make them best of the best (not that they arent good at what they do, just saying key loggers is a small barrier and very common and easy to use - easy enough I was using them as a kid in the 80s). They may have superior ways of achieving it, such as supply chain attacks, but key loggers have been around pretty much since computers have existed.