# What is the current security level of an algorithm?

I was reading a paper of some years ago about a cryptography and a phrase got my attention.

We want to ensure a security level of at least $$2^{80}$$

I know that $$2^{80}$$ was used as rule of thumb rule, that's probably why they wrote that sentence.

But reading this I think that $$2^{100}$$ may also be too low. Considering for example the resource that a state like US can have what is a reasonable security level?

EDIT: I'm considering only the security level for a bruteforce attack, other algorithm can have a solution that require less computational force.

• keylength.com documents what various people consider to be an appropriate security level. Commented Apr 24, 2020 at 14:25
• @SEJPM so reading from the NIST, 2**120 can be used as thumb rule for a bruteforce attack right? Commented Apr 24, 2020 at 14:50
• NIST basically says 112 bits through 2023, then transition to 128-bit, with 112 no longer being allowed by 2030 Commented Sep 21, 2020 at 17:38
• Note that the security strength is basically the time it would cost an attacker to break a scheme in the number of operations. It is usually expressed as a power of two as it is directly related to key strength for many schemes. The key strength in turn is related to the key size. So e.g. the unbroken AES scheme with a key of 128 bits has a key strength or security strength near 128 bits. However, for other schemes such as RSA the key strength is much lower than the key size as better attacks such as factorization should be considered. Commented Jun 3 at 13:15

You can read the recommendations from NIST(2020), ECRYPT-CSA(2018), and BSI(2024). They are all decently up to date and give fairly comprehensive recommendations. The report from ECRYPT in particular is probably the most comprehensible of the three and provides a good guidance for anyone doing security work.

BSI recommends a minimum security level of 120 bits for any new security systems. NIST suggests a security level of 112 bits is adequate until 2030 and at least 128 bits is recommended after that. ECRYPT suggests that a security level of 128 should be adequate for at least the next 10 years (the report was written in 2018), and a security level of 256 bits should be enough for the next 30-50 years.

So for the near future 112 bits of security should be adequate but try to reach for at least 128 bits if possible.

First of all: The security and the length of the key depends on the system you use. So e.g. RSA needs longer keys than AES-256 does, to ensure the same security.

Second: The level of security depends on the application and how secure it has to be. A important point here is: How long should it be secure. There are still security systems in use, that can be broken in days. That's however no problem when the information only has to be secure for some minutes/hours.

• My question wasn't clear enough. I was interested in a security level considering only brute force attack. Commented Apr 24, 2020 at 14:44
• "How long should it be secure" - the other thing to consider is "who does it need to be secure against?" - your kid sister, or world governments? On the other hand, unless we're extremely resource constrained, crypto that is secure against world governments is not that much more expensive than "kid sister" crypto, and so we generally opt for the former (although, if world governments are the expected adversaries, you need to worry about a lot more than just the cryptographic protocols...) Commented Apr 24, 2020 at 15:03
• It stills depends on the application, but 128 Bit up to 256 Bit is the modern common sense of being safe against brute force attacks (btw. not all crypto-systems can be broken by brute force, e.g. one time pad ) Commented Apr 24, 2020 at 15:04
• @malloc That old comment doesn't make sense, we consider the best attack against a scheme or algorithm to indicate the security strength. E.g. for RSA we should consider factorization rather than brute force. Commented Jun 3 at 13:16
• I've voted down this answer because it conflates security strength of an algorithm against the security strength of a system. The question is about the former, and the strength indicated does not change depending what kind of system it is employed in. E.g. NIST may specify 112 bits "secure enough" for real time systems, but the value of 112 doesn't change. Commented Jun 3 at 13:21

There are three costs: 1. What is the cost of encryption plus decryption by the intended recipient? 2. What is the cost of decryption by an attacker? 3. What is the value to the attacker / damage to you of decrypting a message?

You should use at least the highest security with trivial cost automatically. If 112 bit has trivial cost, why would you even look at 80 bit? Apple decided that 256 bit for all files on an iPhone with different keys for every file has trivial cost. So there is no option to reduce the strength.

It would then be worth checking if with that security, a hacker can profitably hack my bank account to get \$10,000. Probably the US government could crack it at a cost of a billion dollars, but that’s a risk I take. And for something more damaging, you would want a similar ratio of cracking cost to potential damage.

And of course don’t use the strongest encryption just for the most valuable/ sensitive data because that would have an attacker a hint what is worth attacking.

In practice, unless you are using really bad crypto, nobody will break. What attackers will do is finding ways to get your secrets without breaking the cryptography.

• "And of course don’t use the strongest encryption just for the most valuable/ sensitive data because that would have an attacker a hint what is worth attacking." I'm hoping that this is sarcasm, but since I don't like sarcasm without a hint in posts about cryptography I've downvoted the answer. I also don't like that "cost" is used confusingly and that "highest security" doesn't have an upper limit specified. Should I use Threefish with a larger key size instead of AES if the CPU cost is "trivial"? Commented Jun 5 at 11:11