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 mapis 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.
Hi, While trying to implement CPace with Ristretto255, I found that the test vectors are incorrect.
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 thinkshould be replaced by:
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.