Hacker News Reader

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. 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. The fundamental point the paper is making is:

A) The key size & number of rounds aren't where the security issues are today 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. 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.

I find the arguments pretty compelling especially when you consider A & C.

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

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.

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

> 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.

> 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.

For the symmetric block ciphers we have a reason to be confident that we're done, that we learned all the things we needed to learn to do this properly, not just for a generation - which reducing the round count would make us less confident of.

The rationale goes like this: After all this time, the best practical attacks on the _previous_ symmetric block cipher (DES) focus on the two things its designers intentionally picked to be weaker because they saw this as appropriate. The keys are too small (56-bits) and the blocks are too short (64-bits).

Cryptanalytically, there has been not insignificant progress on DES, but after decades of focus fire it's looking in relatively good shape. Some type of Linear cryptanalysis might get you down to 2^40 DES trials after you collect 2^47 plaintexts for example. That would be unacceptable in a brand new cipher (if you got this far thinking "Maybe I should use DES?" you are a bad Hacker and should feel bad), but still falls short of what you'd need to actually do bad things in the real world. We should not expect AES to suffer a quicker death. AES has 128-bit (or 256-bit) keys and a 128-bit block length so the obvious problems are fixed.

I don't have the same good feelings about the hashes or the asymmetric crypto yet.

Des is both an example and a counterexample - the same changes that shortened its key to 56 bits also changed its S-boxes to be resistant to differential cryptanalysis. That was a previously unknown (although later separately discovered) attack vector to the public community. It's important to always think of the attacks you're describing as the best publicly known attacks.

> I don't have the same good feelings about the hashes or the asymmetric crypto yet.

You might be interested in https://electriccoin.co/blog/lessons-from-the-history-of-att... (caveat: it’s a few years old, and it might have mistakes). It’s an empirical view on the history of hash functions. The results were very interesting to me. Against collision attacks, it kind of seems like we figured out how to make hash functions secure against them in the 2000’s (compared to block ciphers, which I guess we mostly figured out in the 1970’s). Against preimage attacks, it seems like we figured out how to make hash functions secure against them as soon as we invented secure hash functions at all — in the 1990’s.

And man, the rounds we have are not so expensive. Even cheap phone SoCs tend to have hardware-accelerated crypto. Some server chips have AES-128 in the memory controller, inspired by a feature console makers wanted: https://www.crn.com/news/components-peripherals/amd-s-xbox-p...

(AES-128 happens to also be one of the algorithms he thinks has the least "extra" margin, for whatever that's worth. Bigger difference for ChaCha.)

I do have some sympathy with the idea there's less uncertainty around long-studied symmetric algos than there was long ago, so the sensible margin is smaller than it used to be. Symmetric crypto's certainly moved closer to the good kind of boring since the AES competition and e.g. thorough study of RAX ciphers and other minimal primitives.

But from another angle, we have a system that's working pretty well, including in cost and performance. Given interoperability, etc. seems like there's a high bar to mess with it in the name of making a few more super-small-scale uses of crypto possible or cheaper.

You're saying "the rounds are not very expensive" but the paper is generating 2x+ speedups. This is a paper by a cryptographer (Aumasson is an author of BLAKE and BLAKE2) and a participant in the cryptographic contests that have selected the primitives we use now, in significant part due to performance concerns.

Which is just to say, to the extent that the performance issues Aumasson is talking about don't seem relevant to you, you might just not be the audience to whom the paper is directed.

Yes, I know Aumasson's a highly respected professional and followed the contests, and am even, like I said, kinda sympathetic to the idea that keeping a big margin for unknown unknowns may make less sense than it once did.

What's the practical play here though? I guess lower-round ChaCha-Poly1305 TLS cipher suites could be worth it for users without hardware AES. I suspect even less-aggressive folks would be comfortable enough with ChaCha12 instead of 20 (e.g. Android already uses it to encrypt storage when there's no AES acceleration).

But trying to move to reduced-round variants of every already-standardized primitive would be a lot of effort to, for most applications, move symmetric crypto from one tiny amount of resource use to another (even if it's much smaller in relative terms!).

I do realize that people care a lot about performance, that there are applications either building on tiny microcontrollers or handling redonkulous data flows, and that any possible bit of flexibility could help someone. Still seems fair to ask: if the broad change in perspective Aumasson wants does happen, is it really going to change much about crypto in the wild soon?

I think the big unknown unknown would be something along the lines of a hypothetical mathematical breakthrough that renders current cryptography useless. I'm not even suggesting quantum computing. Suppose someone figures out a way to rapidly factor large numbers easily using classical computing?

Yes, we dont know how to do it now, but there have been a lot of things we didnt know how to do or was thought impossible 20, 50, 100 years ago.

I dont have any special insight to this, just saying that what was once impossible can become a daily occurance in time and with the right breakthrough.

Factoring large numbers won't have any effect on symmetric cryptography. Finite field cryptography, if you want to call it that (DH, RSA) requires the primes be big enough to generate sufficiently large finite fields for all algorithms that might factor or solve dlog to be so expensive to run you can't do it. Same with elliptic curves - the finite fields are chosen to be large enough to make the best algorithms that can solve the ecdlp impossible within our lifetime, modulo either quantum computers or a major classical speedup.

At a very high level (I'm about to take liberties with the entire field), symmetric cryptography is a permutation of bits in the input block. To make it secure we need two things: confusion and diffusion. We don't want the relationship between plaintext, key and ciphertext to be simple to describe, and every time a bit is flipped, we want approximately half the output bits to be flipped. There's actually very little mathematics involved here: you can describe AES in terms of finite fields, but there's no hard to inverse problem in place. It's simply that finite fields a) conveniently describe binary in characteristic 2 (AES uses GF(2^8) which can be represented as 8 bits, or one byte) and b) have "weird" multiplication even when using the most obvious characteristic polynomial, which AES does not. Actually I think this was mildly controversial at the time, because it implies some structure (and we generally want no evidence of structure of any kind).

Cryptanalysis, in this context, tries to find "chinks" in this confusion and diffusion. Imagine if you took two plaintexts, what happens if you start doing things like encrypting the xor of them, versus encrypting one or the other? Doing this with enough plaintext/ciphertext pairs gives us enough information to find the key being used, eventually. Or what happens if we can make linear approximations to parts of the cipher? Can we use this to take shortcuts and guess the key? Have a read of http://theamazingking.com/crypto-diff.php and the linear stuff there. This is the best we have.

tl;dr factoring large numbers, or any advance in the mathematical areas has little bearing on symmetric cryptography. What we need is a way to see structure in something that has been deliberately designed to have as little as possible. Of course, nobody knows, but I'd guess that it's more likely someone will find a speedup for the ecdlp than any meaningful improvement to block cipher cryptanalysis.

I think the point is that additional rounds are poorly representing any sort of measurable return. Maybe the thesis is poorly worded to get attention?

I don't think anything in cryptography should be taken for granted. Any sort of assumptions that were made 20 years ago should be revisited given how much the landscape is changed.

That being said, it actually DOES look like there is a call for less rounds, and I am totally projecting what I think we should be advocating for.

Isn't one of the cardinal rules of crypto "fast crypto is easily broken crypto?"

One time pad is pretty fast

No, I don't think that's one of the cardinal rules of crypto.

> less

fewer

Not long ago, we trusted RC4 and DES. We didn't laugh back in the 1980s and 1990s. But those would be crazy to use now.

We can cringe 20 years out about ECC, RSA and AES.

That's fake history. Deep crack was 1993 and RC4 was shown insecure in the Usenet thread that revealed it.

Not to mention that literally the first sentence in the paper observes that DES has never been broken through cryptanalytic attack.

Is not the solution to have crypto libraries abstract away the exact crypto algorithm used. Say it provides a collection of symmetric key algorithms without letting the users pick which algorithm is used. This way the library can update and prohibit algorithms deemed insecure and the user doesn’t have to worry about it.

Algorithm agility is a feature of most cryptographic protocols, and it is hard to do well. https://tools.ietf.org/html/rfc7696

Why is it difficult? TLS 1.3 has a much smaller set of cipher suites than previous versions. Does that help?

The reason for that is that there were way to many attacks on earlier TLS versions that used the cryptographic agility to make the victims use poor crypto. The strong crypto was never broken, but the protocol was used to make sure strong crypto never happened.

Also: if I send a sufficiently encrypted message today, that message may be captured by a malicious actor, stored and decoded later, after the cypher has been broken.

Yes, everyone understands this. That's why the paper is talking about attacks at the boundaries of what is physically possible, not in terms of what an attacker could cost-effectively do online.

People advocating putting sensitive data on blockchains in encrypted form do not understand this.

What if you have a disproportionality large public bounty on each algorithm?

FUD. Bitcoin will continue to evolve, it is not static.

But all the prior blocks are static, that's the point. If you can break the cipher used at some time t, anything that people had "stored securely" by encrypting it and putting it on the blockchain before time t is vulnerable. As our technology and understanding gets better, t might get later and later. Obviously it depends on your use case, but it's a good argument for not putting sensitive things out in public on a blockchain at all.