> On 14 Jan 2016, at 11:00 PM, ipsec-requ...@ietf.org wrote: > > Send IPsec mailing list submissions to > ipsec@ietf.org > > 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 > ipsec-requ...@ietf.org > > You can reach the person managing the list at > ipsec-ow...@ietf.org > > 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 <p...@nohats.ca> > To: "Scott Fluhrer (sfluhrer)" <sfluh...@cisco.com> > Cc: "ipsec@ietf.org" <ipsec@ietf.org> > Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum > resistance > Message-ID: <alpine.lfd.2.20.1601141126130.24...@bofh.nohats.ca> > 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 <dschin...@apple.com> > To: Yoav Nir <ynir.i...@gmail.com> > Cc: "ipsec@ietf.org WG" <ipsec@ietf.org> > Subject: Re: [IPsec] meeting at IETF-95 ? > Message-ID: <4a3ba7c8-3aca-4250-8464-23cc89f10...@apple.com> > Content-Type: text/plain; charset=us-ascii > > + 1 > > David > > >> On Jan 13, 2016, at 14:51, Yoav Nir <ynir.i...@gmail.com> 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 <p...@nohats.ca> 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 >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > ------------------------------ > > End of IPsec Digest, Vol 141, Issue 16 > ************************************** _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
