Should quantum computers become available in the future that offer a bit-width and processing speed sufficient for breaking encryption, the Diffie-Hellman key agreement in IPSec is primarily threatened. For if this can be broken, transmissions recorded earlier can also be decrypted retroactively. Therefore, protection against future attacks via quantum computers is already important today.
In contrast, no attack possibility with quantum computers on symmetric encryption methods such as AES or authentication via pre-shared key is known.
![[Caution]](../images/admon/caution.png) | Caution |
|---|---|
Authentication via pre-shared key in IKEv2 takes place in conjunction with the Diffie-Hellman key agreement. It is therefore not protected against attacks via quantum computers. |
Completely new asymmetric encryption methods, called Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), have been developed that withstand attacks with quantum computers. However, the use of their mathematical concepts for cryptography is new and has not yet been intensively checked for vulnerabilities by cryptologists over decades. In these methods, there is therefore a higher risk that a new vulnerability will be found than in classic asymmetric methods.
Another disadvantage of these new encryption methods is that comparatively large amounts of data must be transmitted for negotiation. This means a slower connection establishment and a higher sensitivity to transmission errors.
A common solution is therefore to combine classic asymmetric authentication and key agreement with a pre-shared key. To overcome the protection, both methods would then have to be cracked. At the same time, the additional pre-shared key requires hardly any additional data transmission or computing time.
This method is called Post-Quantum Pre-Shared Key (PPK) and is an optional extension in IKEv2 that is supported by the Intra2net system.
In addition to the PPK itself, a "PPK ID" must always be configured. This must be stored identically on both sides and be unique for the connection. Each connection should be secured with its own and not multiple-used PPK.
The PPK itself should be generated using a random number generator to ensure sufficient entropy. The corresponding button in the Intra2net system interface is a suitable option for this purpose.
The PPK must not be intercepted or recorded by unauthorized persons during configuration. Therefore, be sure to transmit it only through sufficiently secure channels and do not use unencrypted email or telephone, for example.