WICG/trust-token-api

Clarify redemption record with voprf draft21

colinbendell opened this issue · 2 comments

colinbendell commented

The redemption record verification does not match the functions in VOPRF Draft21 and it is unclear how it can be updated to align. The updated chrome implementation uses Draft21 for the Issuer protocol but still uses Draft7 (with P384_XMD:SHA-512_SSWU_RO_) for redemption

Context:
from ISSUER_PROTOCOL.md:

The Redeem function corresponds to the VerifyFinalize stage of the VOPRF protocol.

In Draft7, this stage is described as:

def VerifyFinalize(skS, input, output): 
  T = GG.HashToGroup(input)
  element = GG.SerializeElement(T)
  issuedElement = Evaluate(skS, [element])
 ...

Where the current redemption validation process would compare the signed issuedElement with the ECPoint W using the DST of TrustToken VOPRF Experiment V2 HashToGroup\0 and the hash sha512.

In draft21 of VOPRF, the VerifyFinalize stage has been replaced with the Finalize stage and the Evaluate function to determine the PRF result. However, the Evaluate function returns a hash of the input after signing.

colinbendell commented

This seems to be more of a bug in Chrome, as PrivacyPass Protocol (Draft 10) more clearly defines the use of the Evaluate function. The ISSUER_PROTOCOL.md is just out of date.

colinbendell commented

Re-opening because it is all very confusing. Protocol Draft10 is not updated to reflect voprf draft 21 and the structure and method of the redemption process is odd.

Compounding this is that the ECPoint W doesn't match any documentation:

  • it's encoded as Ne + Ns long instead of Ne in length (97 v 49)
  • the Evaluate() function in voprf produces a hash of Ns length, so it's unclear if the redemption request should be passing the hash output from Finalize() instead of a Point value.