selectiveIndexes with blind signatures

[JonasNiestroj]

We are currently implementing the Data Integrity BBS Cryptosuites and are trying to combine it with the BBS blind signatures feature.
While implementing that a question popped to our minds.

In the ProofGen function we use the selectiveIndexes to define which messages we want to disclose.
If we now want to verify this proof on the verifier site we need to use other indexes because we have at least one additional message (the secret_prover_blind. Could be also more, depends on how many messages you committed). So every index needs to be adjusted to be able to verify this proof. How is this working?

In the blind signature specification we see that the ProofGen function returns the adjusted indexes but we don't see how that adjusted indexes are sent to the verifier.

Do i miss something to solve my problem?

[Wind4Greg]

Hi @JonasNiestroj, in the current blind BBS draft we are returned the following: (proof, disclosed_msgs, disclosed_idxs) = BlindProofGen(PK, signature, ...). Where the disclosed_idxs are the "adjusted indexes" from blind BBS. Are you saying that in Create Disclosed Data, specifically step 10.2 (and perhaps 10.3) that I didn't properly handle the adjusted indexes from blind BBS in the processing?

That could be. I didn't produce test vectors yet and that's where I tend to catch such oversights. Or do you mean something else?

Best Regards
Greg

[bit-jniestroj]

Hey @Wind4Greg,
Maybe i missed something or understood it wrong. In 3.3.3 section 10.2) we are calling the ProofGen for the blind signature. There we should get back the new disclosed_idxs. What i dont understand is what we should do with these indexes. Shouldn't the output of this function change the value of selectiveIndexes (that we defined in 8))?

Otherwise the verifier wouldn't get the blinded indexes and only get the selectiveIndexes that were calculated before.
I would expect that in 10.2) there would be something like "change the selectiveIndexes to the output of the ProofGen function"

Thank you for your help and regards
Jonas

[Wind4Greg]

Hi @JonasNiestroj, I might have spoken a bit too soon. I need to walk through the procedure with a test vector. In step 8 we deal with indexes relative to the non-mandatory statements. In step 10.2 or 10.3 we may be offsetting the BBS related indexes. In step 14 we produce the label map... Then we need to look at the corresponding verification procedure to make sure everything is interpreted correctly at the JSON-LD layer and BBS layer. Over at the BBS side (blind and pseudonym) making sure all the indexes are lined up correctly takes some work too.

I'm starting on the test vectors today. As usual I'll be making all the code public at https://github.com/Wind4Greg/ECDSA-SD-TestVectors/tree/main/BBS.

Best Regards Greg

[JonasNiestroj]

Hey @Wind4Greg , perfect. Thank you very much. If i can help you anywhere don't hesitate to contact me.

Kind regards
Jonas

[Wind4Greg]

Hi @JonasNiestroj walked through initial test vector generation for the Anonymous Holder Binding and Pseudonym with Hidden Pid cases. Looking carefully at indexes and how they are used. Working derived verification in parallel.

Things are kind of subtle, but not difficult. The adjusted selected indexes are only used in the BBS proof verification procedure, while the adjusted mandatory indexes are used directly with the nquads. The adjusted mandatory indexes are not affected by the Blind BBS adjustment. Hence we need to pass along the modified selective indexes produced by blind BBS proof gen but leave the mandatory indexes alone. Also derived proof validation needs to use the same BBS api_id as used in signing and proof gen.

My rough (but running) test vector generation code can be found: https://github.com/Wind4Greg/ECDSA-SD-TestVectors/tree/optional-features/BBS. Note that we are refining the APIs on the BBS side too. I'll work through the set of test vectors for the Pseudonym with Issuer known Pid and then modify the procedures in the specification.

Cheers Greg

[msporny]

PR #158 has been merged to address this issue; closing.