Scott C Moonen writes: > Tero, what you propose seems the right way to go in principle, but I > suspect we are solving a problem that doesn't exist. Is there any crypto > library or device that exposes the y coordinate for use in the ECDH > secret? It seems pretty well established that the x coordinate serves as > the ECDH secret. Moreover, since the y coordinate provides only one more > bit of independent information, it's actually misleading to use it.
At least in our crypto library it would be possible to get both of them out if we wanted. I checked our implementation and currently it seems to return only x, but that was changed July 2009 after this dicussion started on the list. Before that the code was modified in 2007 to follow RFC4753, and the original code was written in 2001. This means that all our implementations we have released between 2007-2009 are using the orignal RFC4753 version, thus nobody will be interoperable with those. > I seriously doubt there is any implementation that does not implement the > intent of the erratum, if only because there are immense practical > barriers to implementing the RFC as written. Given that, I think the > practical result of what you propose will actually be more confusion and a > longer period of time before all implementations (as well as all > standards/profiles) are able to re-stabilize to the new ECDH landscape. > The practical cost of making this change is greater than the practical > benefit it buys. There are as all our QuickSec implementations with versions 4.4 - 5.0 do include the original RFC 4753 code, and only the latest QuickSec 5.1 was modified to include errata. (I just now noticed this myself). Note, that none of our customers have complained to us that we are not compatible with other vendor's product using groups 19-21, so that either means nobody uses those groups, or some of those other vendors have also implemented RFC4753 without errata... > On the other hand, if there is such an implementation, then we probably do > need to do something like what you propose. As we need to do something on those versions anyway, I rather make patch that will fix them to follow the new RFC, and also change the group numbers to match new group numbers for those old versions, as then customers using those versions will not break their own interoperability with old versions (it is ok, if they decide to select some other Diffie-Hellman group as old versions do not support new numbers, but it is not ok for the implementations to get MAC failures when trying to use those groups). -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec