Postquantum Preshared Keys
Introduction
Postquantum Preshared Keys (PPK) are used for deriving encryption and decryption keys in IKEv2 that are safe against quantum computer attacks.
The PPKs are proposed by IETF draft which describes this feature and how it should be used. The latest version of the draft can be found on the following link: PPK Draft
PPKs are already efficient and simple solution for protecting traffic against quantum computer attacks, and most importantly they are ready to use right now.
Implementation
For allowing usage of connection that use PPK in libreswan the following things were done:
- The values 40960 and 40961 were picked as private use numbers for PPK_SUPPORT and PPK_IDENTITY Notify messages, respectively.
- Changes were made in source files (programs/pluto/ikev2_*.c) where IKEv2 is implemented.
- New test cases were added. You can find them in ikev2-ppk-* folders in testing/pluto/
Configuring a PPK and connection in libreswan
Each PPK has its own PPK_ID - a unique string that represents that PPK. This way, the peers can agree on which PPK to use, by comparing the PPK_ID of that key. This is convenient because PPK_ID should be much shorter than the actual PPK.
In libreswan PPK are stored in secrets file just as other keys (preshared keys, RSA keys, ...)
Two types of PPK are supported: static and dynamic.
1. Static PPK is represented with two strings separated by spaces. The first string is PPK_ID and the second one PPK. The keyword for .secrets file in libreswan in PPKS.
e.g. 10.1.0.1 10.2.0.1 : PPKS "lsw1" "very_long_string_that_is_a_postquantum_preshared_key"
2. Dynamic PPK (work in progress) is represented with two strings separated by spaces. The first string is PPK_ID and the second one is a path to another file which the PPKs will be taken from. This file should also have only two strings in it. The first one would be offset and the second one a long string that will be used as a one-time pad. Each time when a PPK should be loaded into the libreswan, the string of fixed length will be taken from a second string with an offset from first string. After this PPK has been used, libreswan overrides that part of a string with zeros (0x30) and updates the offset to offset+PPK size. This way each time two peers establishing an IPSEC tunnel will use a different PPK for it. note: Dynamic PPK feature is not finished.
The option for connection configuration is ppk. The accepted values are never/no, propose/yes and insist.
Using IKEv2 is necessary for the usage of PPKs.
Source code
The experimental git branch on which this feature is implemented and tested can be found here. The main developer of this feature is Vukasin Karadzic, and this has been done as a summer project under the mentorship of Paul Wouters and Tuomo Soini.
For any questions, found bugs or suggestions feel free to contact him on vukasin.karadzic@gmail.com