Life cycles and cryptography

We subconsciously suspect connections with the age of equipment, its reliability and general security. On the other hand, it is difficult to imagine the above problem in the field of cryptography and to accept these development impacts. I was wondering how it is even possible to consider the mentioned life cycles, what impact they have on security, or what relationships there are between the life cycles of cryptography and other applications or services. The goal is to understand the motivations to maintain the current solution, the impacts of extension on technological debt and to what extent the approach using cryptoagility can solve the mentioned problems. This article series tries to summarize the causes that hinder regular and, most importantly, rapid change of cryptography, as well as to provide an overview of the reasons. If we know the reasons for these problems, we are able to consider them and make appropriate decisions.

Zombie apocalypse

Currently, most systems are subject to security-based management. The reason is the huge increase in risks arising from vulnerabilities or irregularities found. But this is also related to the support section. In the event of unavailability of warranty or post-warranty support, devices become zombies. The biggest problem from a security perspective is the zombie apocalypse, when unserviceable but functional devices become "undead". In other words, devices that are neither completely alive nor dead only create a security risk. These zombies, i.e. systems without any support or service, have the only solution in case of a problem. And that is to replace them with other components, i.e. devices with support. Typical examples of these zombie devices are old routers, access points, printers or other similar devices. But it can also be outdated systems, unsupported applications, the management of which creates additional costs. These devices or applications are still functional, but contain a large number of security errors. For a potential attacker, they are a godsend because they do not address current security threats or trends.

Impacts of life cycles

Why are life cycles important? They allow planning for equipment replacement and, to some extent, have the ability to describe the type of equipment involved. At the same time, it raises an interesting question whether the motivation to manage these life cycles is currently appropriate to the current situation. The rapid development of cybercrime brings threats that were not considered when these systems were designed. Inappropriate motivation for life cycle management thus brings increased costs for system architecture with the aim of protecting systems that are not even possible to protect. A reactive approach always lags behind the efforts of attackers. But what do the cycles actually look like in individual areas? How can they be divided?

Even from such a rough approximation, a simple outcome can be seen. Each application area has different life cycle models driven by different operational requirements, often based on completely different philosophical principles. Therefore, it is often precisely this view of systems that is at the core of problems and misunderstandings during implementation, problems with costs, security, and as a result can threaten human health and lives. It is not possible to expect requirements corresponding to current systems from systems that are one human generation old (about 30 years). It is also not possible to demand a radical replacement of systems that are installed in hundreds of thousands to millions and have a complex ecosystem linked to them as a solution to the problems. In some cases, such an approach is equivalent to economic suicide; the costs of rapid replacement would ruin the budget of even strong economies. Life cycles do not only concern hardware and software. There are also life cycles for information, users, processes. Or for key material and, of course, cryptography. However, the above-mentioned qualities and motivations are not entirely easy to translate into the areas mentioned.

The battle of armor and caliber

In the case of the sets of cryptology and cryptanalysis, I like to recall a similar battle in history. The battle of armor and caliber. Evolution proceeded quite simply here too. The stronger the armor, the heavier and faster the bullet had to be. If it was not faster, it had to be even heavier. In this battle, leaps appeared. Whether it was longer bullets (penetrators), subcaliber projectiles (penetrator and sabot), cumulative warheads (accelerating the flow of high-temperature and high-velocity exhaust gases in the terminal phase), explosively formed bullets, and currently the use of warheads attacking from another direction, where the armor is not as strong. Such a parallel is perhaps even more accurate than others, because it contains leaps, better technological changes in development.

There was also a development in cryptography and cryptanalysis. The gradual replacement of coding with encryption, the use of passwords, the use of mathematical procedures up to the present. These cycles are gradually accelerating, weaknesses in old algorithms or protocols are found, and these error-ridden components are subsequently replaced with other, more modern ones. Quantum computers bring threats that we are already familiar with to some extent. The ability to find the key and decrypt asymmetric (Shor) or symmetric (Grover) algorithms, or the search for collisions equivalent to the birthday attack (BHT algorithm as an acronym for Brassard-Høyer-Tapp). Currently, there is again a leap forward in technology. Fortunately, we already have other technologies capable of overcoming the advantage of quantum computers on the attacker's side. But such a situation leads to the question of what are the life cycles of cryptography? How can the technical and moral lifespan be described, what is the owner's motivation for change?

Cryptography attacks

Cryptologists work with several types of attacks. With the appropriate knowledge, these can be used as a signaling of the life cycle state. Unfortunately, without knowing the context, this information can be misleading.

• A cryptographic attack is evidence of the weakness of an algorithm, which draws attention to possible problems. At the moment, the algorithm is still secure. This situation can be considered one of the signals of the beginning of the end of its moral lifespan. Unfortunately, this is a weak indication. An example of this is a subtle change in the security equivalent of an algorithm from 256 bits to 255.8 bits. A state actor is currently able to attack an algorithm with a security equivalent of 80b with all its might. But apparently no one is yet able to attack an algorithm with a security equivalent of 128b. Therefore, this type of attack has no practical impact and has no effect on the lifespan.
• A theoretical attack describes a situation where we are theoretically2 able (an individual, an organization, or a state) to build a system that would attack such an algorithm. This situation can be considered a warning and a significantly stronger signal of the approaching end of moral lifespan.
• A practical attack is a specific procedure that can break the algorithm. At this time, this is not a signal of the end of moral lifespan, but the end of the technical lifespan of the algorithm. An immediate replacement is needed.

Thanks to a practical attack with real costs, it is possible to define the end of technical lifespan. The algorithm can serve until such an attack occurs. Here it is necessary to be careful about the economic side of the problem, although in some cases economics goes to the side. However, moral lifespan has a much bigger problem with the definition. Fortunately, a simplification is possible here too, using standardization institutions as knowledge brokers. These institutions employ personnel who have the professional and technical knowledge needed to assess the properties of an algorithm. The end of moral viability therefore occurs when an algorithm ceases to be recommended, even though it is not broken.

The biggest problem in this case is also support. This is provided by both standardization institutions with their recommendations and implementations in libraries providing the calculations needed for cryptographic operations. If the standardization institution is considered decisive for the end of moral viability, it is possible to consider only software or hardware implementation for the end of support. In such a case, the end of support in libraries is equivalent to the end of support for algorithms. This analysis is not entirely without errors, but it allows for a basic orientation. But how to work with the motivations that drive exchanges within life cycles? What is driving these changes?

Abilities of individual actors to attack cryptography:

To be continued next time

The continuation of the life cycles will explain the motivations for cryptography management, the cryptography life cycle, and cryptographic debt. The last part will then address the measurement of cryptographic debt and the implications for managing and servicing this debt. This overview does not cover the life cycle of cryptographic material, nor the issue of migrating to quantum-resistant cryptography. These topics are covered in other articles.

Autor článku:

Jan Dušátko

Jan Dušátko has been working with computers and computer security for almost a quarter of a century. In the field of cryptography, he has cooperated with leading experts such as Vlastimil Klíma or Tomáš Rosa. Currently he works as a security consultant, his main focus is on topics related to cryptography, security, e-mail communication and Linux systems.