Too Much Crypto [pdf]
eprint.iacr.org
eprint.iacr.org
First, it seems extreme hubris to think that something can't ever be broken before the human race disappears. There are plenty of algorithms that have been broken over the years, and there is no mathematical proof that the current set are unbreakable. Sure, the algorithms they listed aren't broken yet, but that's a carefully crafted list. In any case, "not broken yet" is a far cry from "unbreakable".
Another problem is that if a crypto algorithm is broken, there's a significant risk that the users of the algorithm will not be informed until possibly decades later. Many countries dedicate serious resources to attack, and would want to exploit those advantages if they could find them.
Finally, if a major algorithm (e.g., AES) was broken, it would take many years (probably more than 10) to replace it. The reality is that software systems are often hard to upgrade. Yes, that's a problem, but ignoring reality doesn't make it go away.
The only solution we know of is to have large margins.
In the physical engineering world, where we have far better understanding (due to physical models), smart engineers include significant margins when designing things. In the crypto area, where we do not have good models showing that something cannot be broken and the impact of failure is large, it is wise to have much bigger margins.
I agree that sometimes cryptographers incorrectly ignore other attacks. And no matter what, impractical attacks are - by definition - impractical. But I think it's wise to assume that attacks will get better, and we cannot reasonably predict how much better they'll get over the years. Past performance is no guarantee of future results. Margins also increase the likelihood of a break being partial, giving people time to switch to another algorithm.
In special cases, maybe the margin doesn't need to be so big. But nobody likes dealing with special cases.
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.
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
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.
"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.
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
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!
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.
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?
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...
Multiple finalists in the AES competition (which selected Rijndael) had significant weaknesses found in the decade since, despite receiving relatively little attention (MARS, Serpent).
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.
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
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.
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.
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.
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.
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.
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.
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?"
fewer
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.
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.
(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.
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.
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?
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.
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.
We can cringe 20 years out about ECC, RSA and AES.
According to the Bitcoin node on my computer, there have been ≈ 2^92.4 executions of the sha-2 compression function used for Bitcoin so far, exactly the sort of embarrassingly parallel memory-less task that the author speculates about.
So the author's example of a obviously secure attack resistance level has already been exceeded just by bitcoin mining by a factor of thousands.
> For example, “zero-sum distinguishers” [4],arguably the most contrived and meaningless type of attack ever, are about finding a set of input values whose output values sum to zero.
I realize that the author is making fun of his own prior work, but I think he exaggerates the uselessness of such an attack. Finding a set of inputs to a hash function such that the hashes sum to zero (or other specific values) can be directly turned into attacks on cryptographic systems that use those hashes. In particular, attacks like that can lead to total breaks in things like threshold signature protocols and blind signing.
When cryptographic primitives have surprising structured properties there often seems to be a greater fool hiding right around the corner waiting to build a system that almost magically is broken by the structured property. :)
> just by bitcoin mining
like the bitcoin network is a small hobby project in someones basement. The bitcoin network has the same annual energy footprint as the country of Austria. The truth is that even with a purely hypothetical 2^100 attack on AES-128 the NSA wouldn't be able to crack a single key even if all of their funds would go directly into paying for electricity.
Expenditures on the mining are bounded on the upper end by the income, which sets a current ceiling at about $13 million USD per day. In practice actual expenditures are a fraction of that upper bound, since the hardware still needs to be paid for an it wouldn't be worth doing without a profit.
Bitcoin's energy usage level (even the high upper bound) of expenditure is within the estimates of the NSA's budget (10.8billion usd/yr est in 2013).
The Manhattan Project had an estimated cost of $23 billion (2018) dollars.
If we take the article's target of 2^80 operations (for a one in a million against a 2^100 expected attack), and assume those operations are as efficient as bitcoin miners do sha256(sha256()) -- 0.075J/billion ops. And then we assume you pay 2.5cts per KWH for power (an industrially available rate in low power cost areas of the US) --- that attack would cost $629648 in power. I bet the US has single munitions that cost almost much.
The article is just simply mistaken about the intractability, the current existence of computation at a scale it claimed would take ten thousand years shows it nicely-- it doesn't matter that the computation has indeed, been pretty costly.
This makes another argument for setting parameters conservatively: order of magnitude errors in attack costs are less likely to be fatal if you do!
Well yeah, the article might be wrong about how untractable it is, but that doesn't mean it is tractable. Even when taking the minimum annual electricity consumption of the Bitcoin network (41.31TWH/yr) and assuming the Bitcoin network did all those hashes in the last year and assuming that a 2^100 attack on AES-128 exists (which it doesn't), you'll still need an absurd amount of energy just to crack a single key.
> setting parameters conservatively
My argument is that for almost all applications key lengths of 128 bits are pretty conservative. AES-128 will not be the weak link in your application, bad usage of cryptography, memory leaks, use-after-free vulnerabilities, users just doing stupid things, 0-days in your operating system of choice are all easier to exploit than cracking a single AES-128 key.
That said, you probably shouldn't use AES-128 if your threat model includes a intelligence agency 50 years into the future. In that case AES-256 will not help you either.
AES: 11 instead of 14 for AES-256;
Blake2: 8 instead of 12 for Blake2b (IIRC, Blake's rounds are derived from Chacha);
Chacha: 8 rounds instead of 20.
SHA-3: 10 rounds instead of 24 (Keccak).
(§5.3, "How many rounds?")
I'm not any kind of cryptographer, just an engineer who sometimes interacts with cryptographic algorithms, so I cannot comment on the specific recommendations.
On Chacha8 vs 20, see this tweet from DJB (2018): https://twitter.com/hashbreaker/status/1023969586696388613
Yep. There was discussion about this among NIST, the Keccak team, and the other cryptographers contributing to SHA-3. The consensus was that because NIST had been involved in the Dual_EC_DRBG backdoor, that their credibility was dangerously low and that they couldn’t standardize anything that ill-informed people could misconstrue as “weakening” SHA-3, even if the actual cryptographers involved thought it would still be secure. So in one sense, you can chalk up the unnecessary computational cost of SHA-3 as collateral damage from the Dual_EC_DRBG backdoor.
The paper is describing what cryptographers have been doing the past 5ish years at least (see various CAESAR contest entries, the forms of Masked Even-Mansour that use 4 or 6 rounds of BLAKE2b permutation, etc.), but maybe encouraging them to push more in that direction.
http://eprint.iacr.org/2016/1188.pdf https://keccak.team/files/Keyakv2-doc2.2.pdf https://keccak.team/files/Ketjev2-doc2.0.pdf
But... I have a 64Mhz embedded device doing 10,000 ChaCha20-poly1305 encryption operations per second on 64 bytes of data and 64 of “add” in the AEAD MAC. Small packet, but those numbers are crazy.
Chacha is FAST considering it doesn’t need the same special hardware that AES does.
I guess I get the idea of not doing extra work and at a global scale it might add up. But I won’t move my rounds down from existing standard unless I needed to.
I just figured out the other day that if I turn the POE off at our offices from 12am to 5am, it saves us $500 a year and a little durability on the switches. It's not processing, but I guarantee it's a larger difference for us than dropping rounds out of encryption.
No cryptosystem available today gives me confidence I have that.
Confidence is subjective; personally I would gladly hedge my entire net worth against ChaCha20 ever being broken.
Or are you claiming that there's a risk in the future someone will find how to predict what output true random generators produced when they generated the key?
Some hashing algorithms get broken, and we can never be sure whether a particular one is completely safe against attacks.
Now, to mitigate risks, one could use a composition of multiple hash functions, e.g. always apply SHA-1, then SHA-2 on data. Computation would be more expensive, but if one of the hashes gets cracked, data would still be safe as long as there at least one un-cracked hash function in the chain.
Do people actually do this?
A very generic take would be that depending on the system, it may be able to be done securely, but with all crypto there be dragons.
For example, let’s say you have two hashes H1 and H2 and want to use the double hash to prove existence of a file in history. Publish the hash to a blockchain or something.
So the file is hashed H1(H2(file)). In what ways could you break this if one of the hash functions is broken?
The first way is if you want to dispute the validity of what file was hashed. If we assume they later publish the file and you have a second-preimage attack on the hash.
You can create a different file where H2(file) = H2(newFile), and because H1 is deterministic, this second file verifies. It’s now no longer clear which is the true file. While a single hash function also fails under this attack, you increase your exposure to possible attacks by introducing a second one.
If you have control over the verification procedure you can imagine a similar attack with only a break in H2 by not even using H1 to generate the output.
[1]: https://blog.cryptographyengineering.com/2012/02/02/multiple...
Some package systems store multiple secure hashes and pick one at random to verify.
Must be the first time I see someone with a family name referenced only by given name in an academic paper. It really shows how well-known Wilcox-O'Hearn is in crypto circles.
The whole point of password derivation functions is to be slow, not fast. It’s just a matter of how slow is too slow.
For a reference, Django currently uses 260k iterations or something like that.