Security Level

Here’s some good news for you: we are about to end the flood of newly introduced terms. We just need to explain one more term. It is the security level.

From the executive point of view, this term (and the quantity it represents) is currently the data security design key element.

In simple terms, security level is a probability that an attacker will manage to break our defense. To give you an idea, the actual numbers are very small, in case of state-of-the-art ciphers like RSA or AES, the reported level is approximately 10-200.

There is no point in speculating whether it is 10-150 or 10-250, though such arguments can be occasionally heard in the competition. The security level (in contrast to the theoretical security level of cipher itself) is not a constant quantity in time, not even in its technical aspect. Several factors work against the used cipher:

  • New discoveries in the cryptography theory may result in more sophisticated attacks on the cipher
  • More powerful, high-performance computers are introduced every year, and while their number grows simultaneously worldwide, the total computing power of various netbot networks controlled by potential attackers is rising as well
  • when we consider how many operations a single computer can perform within a second, it is obvious that a solution protecting us from a brute force attack for a period of several days or months may succumb if the attack lasts several years..
  • Major discoveries of hardware based on new functional principles are in the air, the most often discussed ones are optical, massively parallel processors which could increase the cryptology performance by far more than “mere” 10200.

Because of that, some cryptographers, paraphrasing a half-life, use the term half-break describing an estimated future moment when a specific cipher or data security will cease to provide protection to a significant amount of common applications.

To apply the security level, we need to determine a target figure which we still consider “acceptable” and then design data security in a way that will allow us to reach either this figure or an even better (lower) figure in the system.

Which figure is “acceptable”? There is no universal answer to this question, only strictly individual, case by case answers, based on the judgment and accountability of the respective IT system manager (or sometimes, without a deeper thought, copied from the table figures of a system slipped to the respective manager by a supplier – in this case, however, we can no longer speak about accountability).

In general, it is obvious that the system data character, their quantity, and “attractiveness” to potential attackers matter. For an accountant keeping crescent roll sale records, 10-10 may be excessive while in the banking system, 10-55 (an approximate level of abandoned DES standard due to being broken) not enough.

In short, the most important lesson we have learned is that none of the currently available solutions can guarantee protection against data breach or manipulation. It can only guarantee that such breaking probability is lower than a specific number provided by the supplier or the system designer. And also to remember that such probability grows over time.

Let us conclude with some good news: a functional sample of an entirely new data security design that can guarantee ruling out a brute force attack was successfully verified last year (2014). We will discuss its properties and potential in the final chapter of this series.