> -----Original Message----- > From: IPsec [mailto:[email protected]] On Behalf Of Paul Wouters > Sent: Friday, January 15, 2016 10:18 AM > To: Tero Kivinen > Cc: [email protected] WG > Subject: Re: [IPsec] SLOTH & IKEv2 > > > > Also this attack do require that the user use the groups with small > > subgroups, like groups 22-24 (and their previous paper the authors of > > this paper said that curve25519 has one small subgroup with size of 8, > > see page 9 of [1]) so they can make the g^xy' same as g^x'y by forcing > > both ends to use same small subgroup and trying so many times that the > > g^xy' and g^x'y happened to be same. If the size of subgroup is less > > than then there is good change that will happen with few tries. > > I did not know curve25519 also has that problem :/
Actually, if you implement curve25519 as specified in irtf-cfrg-curves draft, you don't have that problem With that curve, each side selects private x, y values which are a multiple of 8 (as specified in the irtf-cfrg-curves draft, see section 5) Because of that, if someone passes you an element of the size-8 subgoup, you'll always generate the identity element (aka the netural element aka the point at infinity) for that curve And, the draft requires you to check for that value (and reject it if it occurs); see section 6.1 The check for the all-zero value results from the fact that the X25519 function produces that value if it operates on an input corresponding to a point with order dividing the co-factor, h, of the curve. This check is cheap and so MUST always be carried out. The check may be performed by ORing all the bytes together and checking whether the result is zero as this eliminates standard side-channels in software implementations. Hence, if Curve25519 is implemented as stated in the draft, the problem doesn't occur; if someone introduces such a low-order point, the connection will fail. > > > I would recommend that we make sure our SPIs are unpredicatable and > > random instead of only being unique > > See my above concern about an attacker depleting the entropy pool. > > > , and that we always do small > > subgroup checks regardless whether we reuse the private Diffie-Hellman > > values or not for those groups that have small subgroups (22-24, > > curve25519). > > We should, as NIST already requires it anyway. > > I am curious though why people re-use DH values. Is that really still needed > on busy servers? This has never been in freeswan, openswan or libreswan > and we have never heard people complain (and yes we do have big > deployment servers too, but not on shitty 1995 hardware :) > > 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
