cfrg / draft-irtf-cfrg-cpace

Other
2 stars 4 forks source link

Error in Ristretto test vectors #14

Closed sgued closed 1 year ago

sgued commented 2 years ago

Hi, While trying to implement CPace with Ristretto255, I found that the test vectors are incorrect.

       hash result: (length: 64 bytes)
         a5ce446f63a1ae6d1fee80fa67d0b4004a4b1283ec5549a462bf33a6
         c1ae06a0871f9bf48545f49b2a792eed255ac04f52758c9c60448306
         810b44e986e3dcbb
       encoded generator g: (length: 32 bytes)
         9c5712178570957204d89ac11acbef789dd076992ba361429acb2bc3
         8c71d14c

I get the same hash, but the encoded generator is different. Looking at the Sage code used to generate the test vectors, there seems to be an issue with the way one-way map is used. I think

result = self.point_class.map(string_hash)

should be replaced by:

P1 = self.point_class.map(string_hash[:self.field_size_bytes])
P2 = self.point_class.map(string_hash[self.field_size_bytes:])
result = P1+P2

This is matches the ristretto draft and the tests in draft-irtf-cfrg-voprf. When recreating the testvectors with this modification I get an encoded generator 5e25411ca1ad7c9debfd0b33ad987a95cefef2d3f15dcc8bd26415a5dfe2e15a which matches all three ristretto255 one-way map implementations I tested it with (curve25519-dalek, libsodium and ristretto255).

I think this also impacts the test vectors for MSGa, MSGb, K and ISK because they depend on the generator, for both ristretto255 and decaf448 because the code is shared.

BjoernMHaase commented 1 year ago

Yes confirmed. I have just pushed a revision where I fixed this. Thank you very much!