This is the interesting bit that came out of IETF related to the quantum crypto project idea.
Sent from my iPhone Begin forwarded message: > From: Tero Kivinen <[email protected]> > Date: March 29, 2017 at 18:11:25 CDT > To: [email protected] > Subject: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing > > So I have proposed earlier that we should mix the ppk to SK_d, SK_pi, > and SK_pr, i.e., something like this: > > SKEYSEED = prf(Ni | Nr, g^ir) > > {SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr'} > = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr) > > If no PPK available, then > > SK_d = SK_d' > SK_pi = SK_pi' > SK_pr = SK_pr' > > If PPK is available then > > SK_d = prf(PPK, SK_d') > SK_pi = prf(PPK, SK_pi') > SK_pr = prf(PPK, SK_pr') > > This has the follolowing benefits. The SK_d modification will mean > that IKEv2 SA will gain protection against Quantum Resistance after > the IKEv2 SA irs rekeyed, as rekeyed SA will be using SK_d to derive > new keys. SK_d also used to derive the KEYMAT, meaning the Child SA > will gain protection. > > Modifying the SK_pi, and SK_pr will mean that if the PPK is wrong the > IKEv2 authentication will fail, and we will get exactly same failure > for wrong PPK than we do with wrong shared key or digital signature > failures. This means that attacker do not gain any information which > part of the authentication failed. > > I do so that in the early cases the PPKs are going to be configured > manually in the system and there is quite big propability they being > wrong, and catching the misconfigurations with proper error code is > better, than just getting the random garbage on the Child SA data. > -- > [email protected] > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
