Many designer claimed that their cryptography scheme has 80-bit security. So how to calculate the time of attcking this 80-bit security cryptography scheme, such as 80-bit security RSA using a kind of CPU?
Asked
Active
Viewed 1,667 times
1 Answers
5
The question largely boils down to:
What does $n$-bit security means in practice for a given value of $n$?
TL;DR: as secure as a good symmetric cipher with an $n$-bit key.
There's not a single more precise definition, even if we restrict to attackers using classical computers (rather than quantum computers), as this answer does.
One generally accepted meaning is that the number of "steps" to break the system is believed to be $2^n$; or more precisely that the probability to break the system with $s$ "steps" is not known to be more than $s\,2^{-n}$ by any method for any $s$. However "steps" and "break" are not precisely defined.
In theory of symmetric encryption,"step" is typically taken as one execution of the cipher with a new key. This way, an ideal cipher with a key of $n$ bits has $n$-bit security, under brute force key search. When we move to practice, attackers are not bound to brute force key search, and the definition of a "step" has to become a number of sub-steps comparable in number and computational cost to the sub-steps required for one execution of the cipher with a new key for a plaintext the size of the key. With this definition, a practical cipher with a key of $n$ bits has at most $n$-bit security, and aims at that ideal.
When we move to hashes, the definition of a step could become a number of sub-steps comparable in number and computational cost to the sub-steps required for hashing a new message the size of the hash output.
One of many problems with the above is that there is no agreement about if we should count or not the cost of memory and memory accesses in the computational cost. The safe thing from a user's perspective is not to count it, but that can be be of paramount importance for an attacker.
The definition of "steps" becomes even more murky when it comes to asymmetric cryptography like RSA. In theory, "steps" might be one computation in the algebraic structure used for the cryptosystem; like, for RSA, one evaluation of modular multiplication $(a,b)\mapsto a\,b\bmod N$ for arbitrary integer $a$ and $b$ in $[0,N)$, where $N$ is the public modulus. But there are problems moving this to practice, in particular for RSA: the best known attack is to factor the public modulus $N$ using the GNFS algorithm, which computational cost is dominated by operations having little similarity with modular multiplication, and of practical cost dominated by memory and accesses to memory. Which puts use back to the vague definition in the TL;DR.
how to calculate the time of attacking this 80-bit security cryptography scheme, such as 80-bit security RSA using a kind of CPU?
"80-bit security RSA" is not to be understood as RSA with a 80-bit public modulus $N$, which is terminally insecure. If we had the size of $N$, we could estimate the difficulty based on that and previous experience (see this and its links). But we do not, and there is no consensus on the size of $N$ for RSA with 80-bit security: 1024-bit is often cited, but depending on hypothesis, and who you ask, that's grossly too much or too little. Thus the best is to ignore that we are talking about RSA, and get back to: as much time as needed to break a good symmetric cipher with a 80-bit key.
Which brings us to: $$\text{Time}=\frac{2^n\times k\times p}{\text{Frequency}\times\text{Number-of-CPUs}}$$ where $n$ is the security level in bits, $k$ is an estimation of the number of CPU cycles to evaluate a good cipher using an ultra-optimized algorithm, and $p$ is the residual probability of success of an adversary. Depending on perspective we might take $k=1$ (which saves examining the particulars), $k=32$ (because that's still less than in the best attacks against good ciphers using a general-purpose computer), or much more. Depending on perspective, we can take $p=1$ (most prudent from a legitimate user's perspective), $p=1/2$ (yielding the expected time in the case of a block cipher), or a smaller $p$ if we want a security margin¹.
For example, with $n=80$, $k=1$, $p=1/1000\approx2^{-10}$, $\text{Frequency}=4\text{GHz}\approx2^{32}\text{s}^{-1}$, $\text{Number-of-CPUs}=1000\approx2^{10}$, we get $\text{Time}\approx2^{80-10-32-10}\text{s}=2^{28}\text{s}$, that is about 8 years. In other words, our 1000 CPUs have only a very small probability of success against 80-bit symmetric crypto, until they become technically obsolete.
On the other hand, 1000 CPUs is a tiny fraction of worldwide CPUs, and bitcoin mining conclusively shows that 80-bit crypto is no longer enough against adversaries with the capabilities to design ASICs, build them in massive quantities, and sustain the energy costs for their operation; see this.
¹ The $p$ term in the formula is the most prudent from a legitimate user's perspective, but it causes $\text{Time}$ to be underestimated in many attack scenario. For example, in collision search, the correct term would be more like $\sqrt p$.
fgrieu
- 149,326
- 13
- 324
- 622