# Is 80 bits of key size considered safe against brute force attacks?

I came across the KATAN family of ciphers for small domain input blocks. They cipher arbitrary block lengths: 32, 48 and 64, but their key size is 80 bits only.

Is 80 bits of key size considered safe against brute force attacks with current state of the art processors?

• This question appears to be off-topic because the crux of the question is opinion, because what you consider safe is different from someone else. And the nature of the question is not related to cryptography regardless - this is simply calculating the cost of an attack, basic math. – orlp Feb 3 '14 at 14:55
• I suggest reading up on the cipher itself to find out what the design goal was. The usage of 80 bit keys does not mean much at all, especially does it not mean that an attack has complexity $2^{80}$. Considering brute forcing this keyspace, it's probably at the border of current technology: If you have access to a supercomputer network and a couple of weeks or months time, it's probably possible. – tylo Feb 3 '14 at 15:32
• I think the question is fine, and can be answered rationally. I gave it a try. – fgrieu Feb 3 '14 at 17:46

TL;DR: no longer unconditionally.

As of 25 September 2018, the Bitcoin miners hashed at an aggregate rate of $$\approx60 \cdot10^{18}H/s$$ according to this source, where one hash is two nested SHA-256; that is $$\approx2^{91.6}$$ SHA-256 per year. That's been bitcoin's "peak hash" so far.

Here is this data redrawn in SHA-256 per year with a $$\log_2$$ vertical scale, to facilitate comparison with key size in bits. I believe the notable growth in 2010-2011 was the rise of GPUs, while the 2013-2014 period corresponds to an increased use of ASICs. Nowadays, bitcoin mining is mostly performed using highly specialized ASICs, some reportedly using 16nm technology and having represented a sizable market for silicon foundries.

Thus 80 bit of security can not blindly be said good enough today. 80-bit may be very safe, or clearly not enough, depending on a variety of factors;

• Value of the target
• Time frame during which a break makes sense
• How easier (or harder) it is to check a key compared to SHA-256, due to
• Possibility of multi-target attacks, where the attacker's goal is to find any one in several target keys, and they manage to make the cost of testing a candidate key against all target keys mostly independent of their number. That's sometime straightforward (e.g. when a ciphertext block for the same known plaintext block is available block-enciphered under all the target keys).

Addition: I second everything in Thomas Pornin's answer (Feb. 2014), except perhaps "Right now, 80 bits still seem quite sturdy" which is only valid in some contexts, including the context of the question.

In the context intended for KATAN (really low-end devices such as RFID tags), an expectable consequence of key recovery is to be able to clone one single RFID tag. Recovering the key is likely feasible at far lower cost than brute force, by side channel attack or micro-probing, regardless of key size (even though testing a KATAN key requires significantly less work than performing one SHA-256). So right now (Nov. 2015), 80 bits of key is not a major weakness for an individual RFID tag key on rational economic grounds (if we discount the irrationally devastating effect of the announce of any break, and the more rational desire to not have to argue on key size if such break occurs). 80 bits would not be enough for the master key from which the RFID tag keys are derived, or some other uses of KATAN.

• Comments are not for extended discussion; this conversation has been moved to chat. – e-sushi Apr 15 '18 at 13:22
• I believe the Bitcoin mining rates may not actually represent full SHA-256 calculations. I recall being directed to a technique common in Bitcoin mining ASICs that use fast approximate adders that create a sort of "fuzzy SHA-256" that may or may not be correct. The reduced size of the adders makes mining faster overall since more can be crammed into a single chip, but it does mean that it's not actually computing a full two SHA-256 hashes per block. – forest Mar 8 '19 at 10:28
• @Squeamish Ossifrage: incorporated your suggestions. This comment will eventually vanish. – fgrieu Mar 8 '19 at 11:41
• @forest: yes I remember seeing this technique proposed in a blog. But its main selling point is that most of the time it computes SHA256d exactly, thus even if that technique was used extensively, it would not sizably change things for the purpose of this answer. Further, the possible savings are relatively low, and the same article mentions that using the technique has drawbacks in a bitcoin context. I thus doubt that the technique is used in ASICs, other than involuntarily thru overclocking. – fgrieu Mar 8 '19 at 11:42
• @SqueamishOssifrage: I'm the one confused. What about try 28.2? – fgrieu Mar 8 '19 at 16:17

A key size of 80 bits is the historical limit of infeasibility; that's what was used in the 1990s as a rule of thumb. That's the reason why Skipjack used an 80-bit key, and SHA-1 offers a 160-bit output. Various people have also estimated that a 1024-bit RSA, DH or DSA key offers an "80-bit equivalent" protection (see this site).

One of the most optimistic formulations of Moore's Law is that every three years, we can put four times as many transistors in a given silicon area, and clock it twice as fast. For crypto-cracking jobs, this would translate to one extra bit per year. In that sense, the "80 bits" of 1994 would be "100 bits" nowadays. However, this view of the "law" is really unrealistic and is not verified in the later years (transistor density has kept one rising, but clock frequency is stalling).

The current public record in symmetric key cracking is a 64-bit keys. The people at distributed.net have launched a 72-bit attempt; after 4000 days (almost 11 years !) they explored 3% of the key space. Right now, 80 bits still seem quite sturdy; going to 128 bits is overkill, but we do it nonetheless to have a large "security margin" (a rather irrational reason) and for aesthetic reasons (a very irrational reason, but hey, "128" is a power of two, and powers of two look good).

• Acutally the version of Moore's Law for raw computing power still holds. The raw computing power still grows exponentially when you take many-core architectures. It can be also seen in the HPC peak performance. The bruteforce attacks can be carried out perfectly parallel, so you can take advantage of it. It actually might slow down a bit in near future, because there is trouble of powering this computing power. Needed power also grows exponentially (with a different factor but still), power sources and cooling have trouble keeping up. – luk32 Feb 3 '14 at 18:49
• Moore's law is only interesting if you consider attacking a cipher on a single computer, or a single computing center with a fixed amount of space. But today you can just order raw computing power , e.g. in the Amazon cloud, and then it just comes down to how willing you are to spend the according money. Intelligence agencies (and probably organized crime, too) have their own computing centers and no one knows what they are actually capable of. – tylo Feb 7 '14 at 12:27
• @luk32, "you can easily put 2 cores next to each other" isn't actually that easy. Cache access is made slower, more fragmented, and overall less circuitry is available for each individual core (or the circuitry must shrink to accommodate the needed space). It is actually far easier to just purchase a second GPU or a second computer and attack the problem in parallel. Moore's law provides limited insight into large server farms dedicated to this task, or large FPGAs dedicated to attacking these problems. – kurtzbot Jul 30 '14 at 18:58
• Bitcoin's hashrate has been doubling every 3 months and it is the most powerful human computer by a far margin so the situation is clearly much worse than what you say. – MaiaVictor Mar 5 '17 at 1:28
• @tylo: Why do you distinguish intelligence agencies from organized crime ? Seems kinda silly given what we have learned since JFK was blown away. – William Hird Jun 14 '19 at 14:28
• It depends on how long you want to keep your data safe for. Do you want the secret safe for 1 week, the rest of your life or forever? Will you get in trouble, put in prison or be killed if that secret is revealed to the wrong person?
• It also depends on who you want to keep the data safe from. Do you want your data protected from nation state-level adversaries e.g. US, UK, China, Russia?
• Do you want to consider adversaries that could have viable quantum computers already in secret or very soon in the future <5 years?

Let's assume we want to protect the data from a certain agency with a massive black budget ($10,800,000,000 USD per year) and whose mission is to obtain and decrypt the world's communications. Let's also assume they've got viable quantum computers, we know they have been trying to build one and who at one point was about 20 years ahead of academia in the field of cryptography. If they don't have one just yet, they will do in the next <5 years so you need to consider if you want your data to secret for longer than that. An important thing to note is that when assessing the security against a brute force search, an attacker does not need to perform the full number of attempts. Let's say you have a 128-bit key, that's $$2^{128}$$ search operations. That's the worst-case scenario. If they find the right key after $$2^{64}$$ operations or $$2^{72}$$ operations then they can stop there, they've cracked your data. There is probably some statistical analysis that could be used to figure out the probability of finding a key faster than brute force search in a certain keyspace. Also, remember that there are attacks against various algorithms that can lower the number of brute force searches required. You are hoping an 80-bit key will be secure, which is considered by some to be around the current limits of capability when it comes to adversaries with the top regular supercomputers in the world (taking into effect supercomputers with GPUs and CPUs with AES-NI instructions). In a worst-case scenario, this can be cracked in $$2^{40}$$ time on a quantum computer using the current best quantum search algorithm which is Grover's algorithm. Security of $$2^{40}$$ is not secure at all. Given a 128 bit key which is considered by some to be overkill when it comes to adversaries with normal supercomputers, this can be cracked in $$2^{64}$$ time on a quantum computer which is still not secure at all. If we move up to a 192-bit key this will take $$2^{96}$$ time with a quantum computer. Probably the bare minimum security margin nowadays and it might protect your data for a few more years. If we move up to a 256-bit key this will take $$2^{128}$$ time with a quantum computer. If we assume $$2^{80}$$ is within reach of the top supercomputers in the world and with Moore's law they gain an extra 1 bit of processing power per year, then this will be safe until about the year 2062. You might still be alive by then, and you might still want your secret protected. The established totalitarian government might forcibly remove you from your retirement home and throw you in prison because you sent a mere 256-bit encrypted message to your friend talking about going on an anti-government rally back in 2013. Do you want to risk it? Your next option is going higher than 256 bits to stop them from cracking your data in your lifetime, then you can rest in peace. With the Threefish algorithm you can have a 512 bit or 1024 bit key. For a 512 bit key that gives at least $$2^{256}$$ security against a quantum computer. They'll be there until about the year 2190 working away on that one. You better hope they don't capture you, put you in cryosleep then wake you up again when they've decrypted it just to have proof and punish you. What about if you never, ever want them to find out the real data? What if you're tired of government sock puppets estimating "safe" levels of key bits and "safe" algorithms for you to use? What about if you want the ability to give them any number of fake keys under duress and still have it decrypt to something plausible so you won't get in trouble? Well, then you should use a one-time pad. They can try every key and have it reveal every plausible plaintext but still not know exactly what the real data is. This is the reason spies, militaries and governments use it - plausible deniability. Just don't use a backdoored or potentially dodgy random number generator like Intel's RDRAND. Use proper TRNG. • I disagree with "If they don't have one (useful Quantum Computer) just yet, they will do in the next <5 years". I'm ready to bet that there's on our planet no such agency (pun intended) that will get a quantum computer doing anything useful to cryptanalysis in the next 8 years. The leaked document makes it clear that it remains a research subject (thus doubtful) to determine if a useful QC can be built. – fgrieu Feb 7 '14 at 13:06 • By the account of Don Coppersmith, Differential Cryptanalysis (which motivates your "20 years ahead of academia") was known to academia by 1989, and to IBM in 1974. Any reference to that agency knowing it by 1969 or earlier? Whatever the offset, I attribute it to a general advance of military cryptography before 1990. For what we know, academia has largely caught-up on a theoretical standpoint (clearly not on the standpoint of brute force, and likely not for interception and other technological attacks). – fgrieu Feb 7 '14 at 17:17 • When or how a secret national surveillance agency (pun intended) with a$10.8B pa. black budget will or will not have a QC is just speculation and hearsay really. There's no way to know what their secret quantum computing capabilities at Oak Ridge or Ft. Meade really are. Guessing is pointless. The point is that they are storing all data. Encrypted data is flagged and if they can't decrypt it immediately they store it until they can. So when they do have a QC, your data will be decrypted eventually if using small key lengths. – NDF1 Feb 7 '14 at 22:40
• See Bruce Schneier's quote "It took the academic community two decades to figure out that the NSA "tweaks" actually improved the security of DES. This means that back in the '70s, the National Security Agency was two decades ahead of the state of the art." NSA knew about differential cryptanalysis in the 70s and IBM who were assisting NSA at the time with security clearance. – NDF1 Feb 7 '14 at 22:50
• Your butlast comment makes a good argument for using wide session keys when things need to be kept secret for a long time, together with a cryptosystem giving forward secrecy: that insures that future breaks of long term keys (by quantum computer if we trust your intuition, or just by some compromise of the system holding them if you ask me) won't allow to decipher past intercepts. – fgrieu Feb 9 '14 at 17:45