Postquantum Preshared Keys: Difference between revisions
(Created page with "asdasd") |
No edit summary |
||
| Line 1: | Line 1: | ||
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: [https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-04 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. | |||
ipsec working group at IETF is working on a long term solution: changing the IKEv2 protocol and proposing a quantum-safe algorithms for it, but predictions are that | |||
this feature will not be ready to implement and use so fast. | |||
More about this draft can be found on the following link: [https://tools.ietf.org/html/draft-tjhai-ipsecme-hybrid-qske-ikev2-00 Hybrid Quantum-Safe Key Exchange] | |||
= How is PPK represented = | |||
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'' 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 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. | |||
= Configuring a connection = | |||
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. | |||
= Code = | |||
The experimental git branch on which this feature is implemented and tested can be found [https://github.com/vukasink/libreswan/tree/ikev2 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 | |||
Revision as of 23:14, 24 August 2017
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.
ipsec working group at IETF is working on a long term solution: changing the IKEv2 protocol and proposing a quantum-safe algorithms for it, but predictions are that this feature will not be ready to implement and use so fast. More about this draft can be found on the following link: Hybrid Quantum-Safe Key Exchange
How is PPK represented
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 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 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.
Configuring a connection
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.
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