> On 14 Jan 2016, at 11:00 PM, [email protected] wrote: > > Send IPsec mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/ipsec > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of IPsec digest..." > > > Today's Topics: > > 1. Re: NIST question concerning IKEv2 and quantum resistance > (Paul Wouters) > 2. Re: meeting at IETF-95 ? (David Schinazi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 14 Jan 2016 11:28:00 -0500 (EST) > From: Paul Wouters <[email protected]> > To: "Scott Fluhrer (sfluhrer)" <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum > resistance > Message-ID: <[email protected]> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On Thu, 14 Jan 2016, Scott Fluhrer (sfluhrer) wrote: > >>> Is it possible to use the already negotiated IKEv2 prf inside the modified >>> crypto formulas? >>> In this case they would look like: >>> >>> SKEYSEED = prf(prf(ppk, Ni) | prf(ppk, Nr), g^ir) >>> (SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr) = >>> prf+(SKEYSEED, prf(ppk, Ni) | prf(ppk, Nr) | SPIi | SPIr) >>> >>> and so on. I'm not a cryptographer, but it seems to me that this is safe, >>> isn't >>> it? >>> In this case no additional negotiation is required since prf is negotiated >>> in >>> IKEv2 anyway and thus we would have algorithm agility in KDF for free. >> >> I like this -- I'm stealing this idea. > > Note that using a hash of a hash is frowned upon. See the latest SLOTH > on TLS for an example of a collision attack that used the fact that a > hashed message got hashed again (unlike IKE which hashes only the data)
imho, the level of weakness would depend on the selected hash algorithms and the input’s number space. for instance, if the number space for the input is huge, and the size of 1st vs. 2nd hash reduces significantly, plus the (pseudo) randomness of the hashes reduces then it would be a bad direction, I’d think. [not a cryptographer] > > Paul > > > > ------------------------------ > > Message: 2 > Date: Thu, 14 Jan 2016 09:16:16 -0800 > From: David Schinazi <[email protected]> > To: Yoav Nir <[email protected]> > Cc: "[email protected] WG" <[email protected]> > Subject: Re: [IPsec] meeting at IETF-95 ? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > + 1 > > David > > >> On Jan 13, 2016, at 14:51, Yoav Nir <[email protected]> wrote: >> >> I believe around that time CFRG and TLS will be done with the signatures >> document and rfc4492bis respectively, so we could proceed and finish >> draft-ietf-ipsecme-safecurves. >> >> So count me as a +1 as well. >> >>> On 12 Jan 2016, at 4:56 PM, Paul Wouters <[email protected]> wrote: >>> >>> >>> I hope we are scheduling a meeting for IETF-95. Last time we did not >>> meet and ended up meeting in the hallway. This time there are more >>> drafts being suggested and worked on. >>> >>> Paul >>> >>> _______________________________________________ >>> IPsec mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ >> IPsec mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipsec > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > > > ------------------------------ > > End of IPsec Digest, Vol 141, Issue 16 > ************************************** _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
