[Swan-dev] GSoC: Fwd: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Paul Wouters paul at nohats.ca
Thu Mar 30 02:54:17 UTC 2017


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 <kivinen at iki.fi>
> Date: March 29, 2017 at 18:11:25 CDT
> To: ipsec at ietf.org
> 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.
> -- 
> kivinen at iki.fi
> 
> _______________________________________________
> IPsec mailing list
> IPsec at ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20170329/02e684bb/attachment.html>


More information about the Swan-dev mailing list