top of page

The critical risk of quantum computing in DevSecOps

Quantum computing has emerged as a promising field with the potential to revolutionize the way we process and store information. As we have explained in previous articles, while classical computing relies on conventional bits that can represent either a 0 or a 1, quantum computing uses qubits, which can represent 0, 1, or a superposition of both states simultaneously.

This highly parallel processing capability and the ability to perform complex calculations in record time make quantum computing an exciting technology to explore and leverage in various fields, including development and security in computing, such as DevSecOps. However, it can not only be harnessed to develop new technologies but also used to break existing technologies, such as all the public key cryptography that protects the Internet today. In other words, we are facing a critical risk.

The most widely used algorithm on the Internet to secure communications is RSA, and it will fall prey to quantum computing, just like other current algorithms that serve the same function.

From an optimistic perspective, rapid progress in the field of quantum computing suggests that we might be closer than we think to having machines powerful enough to break RSA encryption. The Shor's algorithm has already demonstrated that, in theory, a quantum computer can efficiently factor large numbers, which is the cornerstone of RSA security. Furthermore, advancements in technologies like qubit control, quantum error correction, and quantum coherence are overcoming some of the technical barriers that have so far limited the scalability of quantum computers.

Companies and governments worldwide are heavily investing in this technology, further accelerating its development. Some experts argue that we could have quantum computers capable of breaking RSA within just a decade. Additionally, there are research groups claiming to have found ways to apply the Shor's algorithm, which enables the breaking of RSA, using only a few thousand qubits, whereas it was previously believed to require several million, thus potentially being broken within a few years.

On the other hand, while there is great optimism surrounding advances in quantum computing, some experts take a pessimistic view regarding the ability to break RSA encryption in the near future. This is because they believe that the series of obstacles that still need to be overcome are significant.

Although theoretically a sufficiently large quantum computer could execute the Shor's algorithm to factor large numbers (the basis of RSA security), building such a machine with the current technology is far from feasible, as they do not trust the claims made by the aforementioned research groups. Furthermore, the problems of quantum coherence, error correction, and scalability are enormous challenges that need to be addressed.

In cybersecurity, risk is always mitigated – in fact, "paranoia is our profession." Therefore, we do not play roulette with optimistic or pessimistic outcomes. Instead, action is taken to mitigate the risk. The most concerning attack is known as "Harvest Now, Decrypt Later," which is a tactic used in the context of cryptography and information security, especially in relation to the emerging threat of quantum computing. This approach involves an attacker collecting and storing as much encrypted data as possible now, even if they currently lack the capacity to decrypt it.

They will then wait until the technology (such as quantum computing) advances enough to make the decryption of that data feasible. This is particularly worrisome for sensitive data that will still be valuable or harmful if exposed in the future, even if that future is years or even decades away. This tactic highlights the need to prepare for the threat of quantum computing now, rather than waiting until it can already break existing encryption. Some examples of data that remain valuable after a certain time are:

  • Credit card expiration dates: average time: 3 to 5 years. It can be over 10 years.

  • Medical history: the patient's lifetime.

  • Industrial secrets: generations.

  • Military records: up to 40 years for maximum secrecy.

  • Source code: depends on the company. Some make it open-source, while others keep it undisclosed "forever."

To address this, in DevSecOps, multiple strategies can be used to prevent the "harvest now, decrypt later" attack and the theft of an organization's code when it travels over the Internet, such as sending it to a version repository like GitHub.

Develop exclusively on an internal network

Keeping sensitive and encrypted information on a local network without transmitting it over the Internet can be an effective strategy to prevent the "Harvest Now, Decrypt Later" attack.

This approach limits the exposure of encrypted data to potential adversaries who may be collecting information to decrypt in the future when quantum computing becomes viable. By keeping this data within a local and controlled network, the amount of encrypted data an adversary can collect is reduced. An adversary would need to gain physical access to the local network or compromise a device within it to access the data.

While this approach doesn't completely eliminate the threat, it can significantly reduce the risk of a "Harvest Now, Decrypt Later" attack. In the context of remote work becoming common after the pandemic, keeping information solely within a local network can present significant challenges. Remote access to data has become a necessity for many companies, involving the transmission of information over the Internet.

If the data is only maintained on a local network, employees working from home may have difficulty accessing the information they need to perform their tasks. Additionally, if remote access to the local network is allowed, it can introduce new security risks. A compromised remote device can serve as an entry point to attack the local network. Thus, the challenge lies in balancing the need for remote access with information protection.

Transmit encrypted code with AES-256

It is entirely possible to transmit source code to the version controller exclusively encrypted with AES-256, a symmetric encryption algorithm considered resistant to quantum attacks. This would ensure that the source code is protected during transmission, which is particularly relevant in the current context of increased remote work and code storage in the cloud.

However, this approach poses a significant challenge: managing encryption keys. Since the AES algorithm is a symmetric encryption, both the client and the server require the same key to encrypt and decrypt the data. This key cannot be securely sent over the Internet as it could be intercepted by an adversary.

Therefore, the AES-256 key must be manually configured on each client and the server. This process can be laborious and requires careful handling to ensure that the keys are not exposed during configuration.

Additionally, key rotation and the need for a robust key management policy must be considered to maintain long-term security. Despite these challenges, this approach can provide an additional layer of security to protect source code in an evolving environment.

Use post-quantum cryptography algorithms

To secure the transmission of source code in a post-quantum context, post-quantum cryptography algorithms can be adopted. These algorithms are designed to be secure even against attacks from quantum computers. Post-quantum digital signature algorithms, such as those based on lattices or multivariate systems, can be used to authenticate the transmissions.

This ensures that the source code originates from a trusted source and has not been altered during transmission. It is important to note that the adoption of post-quantum cryptography requires a deep understanding of these new algorithms and how they integrate with existing systems.

It is also necessary to consider that these algorithms are newer and have not been as widely studied as classical algorithms like RSA or ECC, so new vulnerabilities may arise as more research is conducted.

In conclusion, it is possible to mitigate the risk of quantum computing in DevSecOps. However, it is crucial to seek the guidance of an expert in quantum computing and cryptography when implementing any related measures.

8 views0 comments


bottom of page