

The threat landscape for encryption looks different from the one facing other security solutions. The protection often stands alone, and weaknesses can be hard to spot. So what is it that actually threatens encryption?
The difference becomes clear if you compare it with how IT security is otherwise built. In an IT system, security is normally built in layers. Firewalls, intrusion detection, logging and monitoring work together, and if one layer fails, another can catch the attack. An encrypted message that has been sent cannot be recalled. A firewall that doesn't hold up against a new kind of threat can be replaced, and the damage stops there.
– If I've encrypted something and sent it out, and it then turns out the encryption wasn't good, I can change the device, the mechanism or the algorithm. But what I sent out is already out there, says Jens.
A message that cannot be broken today may be breakable in two years, or in ten. Anyone collecting encrypted traffic now can simply wait for the methods to catch up. The approach is usually called harvest now, decrypt later: gather ciphertext today, decrypt it when the methods exist. The protection therefore has to be right from the start.
An attack that leaves no trace
A cryptosystem that has been broken looks exactly as though it were working normally.
– If a cryptosystem isn't up to standard, and someone is sitting there reading what I've sent out, I'll never know. There's nothing to indicate that the system has been broken, says Jens.
An intrusion into an IT system, by contrast, is noticed sooner or later. Information disappears, systems stop working, and the activity leaves traces in the logs. A clear example of the difference is the Second World War, when the Allies could read German traffic encrypted with Enigma without Germany realising it. The machines did exactly what they were supposed to do, but the system was not secure enough. The rest was down to how it was used: repeated key settings, predictable phrasings and carelessly chosen keys.
Four surfaces to attack
The threat landscape can be divided up according to what an attacker is actually aiming at.
The first is the method, that is, the algorithm or the cryptosystem itself. Here the protection is comparatively strong today. Open algorithms that are scrutinised by independent experts, tested in several rounds and adopted as standards make it difficult to hide mathematical weaknesses. Much of the standardisation work is driven by NIST, the US National Institute of Standards and Technology.
The second is the implementation. The right algorithm can be implemented wrongly. A product can use an approved method and still contain flaws in its design, its hardware or its code. That is why cryptographic products are scrutinised considerably more closely than most other IT products.
The third is key management. Keys are created, distributed, used and destroyed, often in processes that sit partly outside the system itself and that require human handling. There is room there for both mistakes and carelessness.
The fourth is operational use. A system used in the wrong way can become breakable even if everything else is correct. Enigma is an example of how the surfaces connect: the weakness in the design only became usable in combination with how the machines were handled.
Backdoors
Beyond unintentional faults there is a category of threat that is particularly associated with cryptography: deliberately built-in weaknesses.
Perhaps the best-known example is Crypto AG, the Swiss cryptography company that sold equipment to much of the world for decades while being owned by American and West German intelligence. Customers believed they were protecting their communications. In practice they were handing them over. The company has Swedish roots. Crypto AG grew out of Boris Hagelin's cipher machine manufacturing in Stockholm, AB Cryptoteknik. Hagelin moved to Switzerland in 1948 and founded Crypto AG four years later.
Backdoors do not have to be planted in a product, though. They can be planted in the standard. According to the Snowden documents, the American intelligence agency NSA placed people in standardisation work in order to push through a standard that contained a weakness, without the other participants realising.
One documented case is the random number generator Dual EC DRBG, which is based on elliptic curves and was standardised by NIST in 2006. The generator uses two fixed points on the curve, and anyone who knows the relationship between them can predict the numbers to come after seeing a small amount of output. As early as 2007, researchers showed that such a backdoor was constructible. The algorithm nevertheless remained the default in one of the most widely used cryptographic libraries on the market, which meant that anyone who did not actively choose something else got it thrown in. After the Snowden documents in 2013, NIST advised against the algorithm within days, and in 2015 it was formally removed from the standard. The case also illustrates a general problem in modern cryptology. Very few people have the expertise to judge whether a cryptosystem is actually secure, while a great many people depend on that judgement being right.
– It's both neatly done and fairly brutal. You take part in a standardisation committee with the opposite purpose to the one the committee is there for, and nobody notices, says Jens.
Backdoors being hard to detect has to do with the complexity of modern cryptosystems. They contain a great deal of electronics and often hundreds of thousands of lines of code. That is one of the reasons most countries regulate how cryptosystems may be used to protect national security, and place particular requirements on cryptography suppliers, including on security-vetted personnel and on scrutiny of the products.
Compared with the past, the centre of gravity has shifted.
– Historically we had weak methods, but there was usually nothing wrong with the device itself. Enigma did do what it was supposed to. Today it's almost the other way round. We have a good grasp of the methods, but less of a grasp of these complex devices, says Jens.
Quantum computers
The single biggest coming threat to today's cryptosystems is quantum computers.
An ordinary computer works with bits that are either one or zero. A quantum computer works with qubits, which can be in both states at once. This relies on quantum physical properties that only persist as long as the particles are completely isolated from their surroundings, which for most of today's platforms requires a vacuum and temperatures close to absolute zero. That is why quantum computers are extremely difficult to build.
Quantum computers exist today, but not at a size and stability sufficient to break encryption. The design principles, however, are known.
The threat applies above all to the asymmetric algorithms, which are used for key exchange in most systems. If the key exchange is broken, the attacker has the key, and with it the content.
Since the quantum computers do not yet exist, it is reasonable to ask why upgrades should be made today. The answer lies in the time dimension.
– If you have a secret, you have to think about how long it needs to stay secret. If it's the identity of an intelligence officer, say, it may need to stay classified for life. If you send it with a cryptosystem that isn't quantum-resistant, and a quantum computer comes along later, the information can be broken while it is still sensitive, says Jens.
Researchers in the field tend to talk about a sufficiently powerful quantum computer existing in ten to fifteen years. Information that needs to be protected for longer than that therefore needs post-quantum protection today.
The standards are in place. NIST finalised the first algorithms for post-quantum encryption in August 2024, with a further algorithm selected in 2025 to broaden the mathematical basis. Work on introducing them into existing systems is under way, and extensive.
The threat landscape for encryption has always been moving. Someone builds a system, someone else finds a way to break it, and a new system takes over. What changes is not the principle, but what resources and what time horizon the attacker has.
Want to know more about Sweden's history in cryptology?
Read our article about Sweden and cryptology.
Click here to read the article
About Jens
Jens Bohlin has been CEO of Tutus since 2009 and has a long background in cryptology and information security. He has previously worked as a technical cryptologist at both MUST, the Swedish Military Intelligence and Security Service, and FRA, the Swedish National Defence Radio Establishment, as well as at the Ministry for Foreign Affairs on questions of encryption and secure systems. Jens trained as an engineer and holds a Master of Science in Engineering in computer science.
More about Tutus
Get to know Tutus and the people behind our products and solutions.
Contact us
