33

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?

otus
  • 32,462
  • 5
  • 75
  • 167
sashank
  • 6,234
  • 4
  • 36
  • 68

3 Answers3

43

TL;DR: no longer unconditionally.

As of 2022-06-15, the Bitcoin miners hashed at an aggregate rate of $\approx220\cdot10^{18}H/s$ according to this source, where one hash is two nested SHA-256; that is $\approx2^{93.4}$ SHA-256 per year.

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. Recent hardware advertises 510 T SHA-256/s at 11 pJ/SHA-256 (5304 W power on wall) for \$19890. It's sold out, and the planet struggles with carbon emissions.

Bitcoin mining SHA-256 hash rate per year

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, at least at the time.

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.

fgrieu
  • 149,326
  • 13
  • 324
  • 622
22

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

Thomas Pornin
  • 88,324
  • 16
  • 246
  • 315
11
  • 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.

R1w
  • 1,960
  • 4
  • 23
  • 45
NDF1
  • 430
  • 2
  • 8