Hi Derek, On Wed, November 7, 2012 10:27 am, Derek Atkins wrote: > Hi, > > On Wed, November 7, 2012 1:21 pm, Johannes Merkle wrote: >> Hi David, >> >> Point compression is simply the ommission of the x-value, and for point >> expansion, functions are included in OpenSSL and >> other crypto libraries. Thus, such mistakes should only occur if someone >> decides to implement the arithmetic by itself >> but is incapable of doing it correctly (and does not perform sufficient >> testing). This seems to me a quite a case of >> carelessness and I don't think, that an RFC should be so fool-proof to >> prevent that. There are certainly much more >> complex aspects in IKE than point compression. > > You're making the assumption that an implementor is using OpenSSL or has > already implemented point compression. IMHO that is not a reasonable > assumption. Many implementations use their own crypto libraries and > therefore would have to implement these compression and expansion > functions, including all the potential errors thereto. So saying "it's > easy, it's in OpenSSL" is not, IMHO, a reassuring statement or argument.
Decompression is just a square root and a discriminator to say whether the result is y or -y. All the brainpool curves are of the form p mod 4 = 3, where p is the prime defining the curve. For such curves the square root of n would be n^((p+1)/4) mod p. This is straightforward to implement with any big number library. regards, Dan. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
