[CFRG] Re: Implementation review of "Blind BBS Signatures" (draft-irtf-cfrg-bbs-blind-signatures-02)

[Greg Bernstein <[e-mail]>]

Thanks Emil. And thanks for the PRs on the drafts. We will try to get an 
update out in a week or two.

Best Regards

Greg B.
On 5/27/26 05:21, Emil Lundberg wrote:

> One more thing I noticed now:
>
> Substantive but editorial issues:
> - In "Test Vectors", the "Generators" and "Blind Generators" sections 
> spell the attribute generators `H_0 ... H_9` and `J_0 ... J_9` while 
> both draft-irtf-cfrg-bbs-signatures-10 
> <https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-10.html#name-message-generators-2> 
> and the rest of draft-irtf-cfrg-bbs-blind-signatures-02 spells them 
> `H_1 ... H_10` and `J_1 ... J_10`.
>
> Emil Lundberg
>
> Staff Engineer | Yubico <http://www.yubico.com/>
>
>
>
>
> Den tis 26 maj 2026 kl 22:28 skrev Emil Lundberg <[e-mail]>:
>
>     Hi,
>
>     I've recently been implementing "Blind BBS Signatures"
>     (draft-irtf-cfrg-bbs-blind-signatures-02)
>     <https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-blind-signatures-02.html>
>     [1] and would like to share some issues I found.
>
>     Interoperability issues:
>
>     - In `FinalizeBlindSign`, the statement `3. if L <= 0 or M <=0,
>     return INVALID` fails for the BLS12-381-SHA-256 signature test
>     vector "valid no prover committed messages, no signer messages
>     signature"
>     <https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-blind-signatures-02.html#name-valid-no-prover-committed-m>
>     [3]. This should presumably be `if L < 0 or M < 0`?
>
>     - In `FinalizeBlindSign`, the description of `blind_generators`
>     states it defaults to empty array, but the procedure requires that
>     `M > 0` which fails if `blind_generators` is empty. (This is
>     obviously related to the previous issue)
>
>     - In `BlindProofGen`, something seems to be wrong when
>     `secret_prover_blind` is null. I have not been able to reproduce
>     nor verify the proof test vector "9.1.5.8. valid all prover
>     committed messages and signer messages revealed proof"
>     <https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-blind-signatures-02.html#name-valid-all-prover-committed-m> [2].
>
>         It seems to me like either the `prepare_parameters` call needs
>     to return one fewer generator (because it skips returning
>     `secret_prover_blind` as a message scalar), or the
>     `secret_prover_blind` generator needs to be omitted from
>     `generators` before passing it to `BBS.CoreProofGen`, but it may
>     also be something else. I haven't found a way to match the test
>     vectors, so I'm not sure what correction is needed.
>
>     - In `prepare_parameters`, the description of
>     `secret_prover_blind` states it defaults to zero, but the
>     procedure checks `3. if secret_prover_blind != NONE;`. It can't be
>     "NONE" at this point if it defaults to zero. Perhaps this should
>     be `if secret_prover_blind != 0;`, but I'm not sure that's correct
>     either. (This is related to the previous issue)
>
>     - I have been able to verify the `signature` of all of the
>     "Signature Test Vectors", but not reproduce any of the `signature`
>     values. My `BlindSign` outputs verify correctly with my
>     `VerifyBlindSign` implementation, and my `BlindSign`
>     implementation produces the same `B` and `domain` values shown as
>     "Trace:" in the test vectors, so the only reason I can imagine for
>     failing to reproduce the signatures is that there is some
>     difference between how my `FinalizeBlindSign` implementation
>     hashes to `e` and how the test vectors hash to `e`.
>
>     - In general I think there are too many optional parameters,
>     especially in the internal procedures. I don't think the defaults
>     seem particularly useful, which weighs poorly against the very
>     real opportunity for misalignments (see the `secret_prover_blind`
>     issue above) and misinterpretations that defaults introduce. (I
>     gave a similar critique of optional parameters in
>     draft-irtf-cfrg-bbs-signatures-08
>     <https://mailarchive.ietf.org/arch/msg/cfrg/2XuK5BoAy-WjKWjzWM3O19Vry6g/>
>     earlier).
>
>
>     Substantive but editorial issues:
>
>     - In the return statement of the `Commit` procedure, the
>     `committed_message_scalars` and `blind_generators` arguments are
>     in reverse order compared to the `CoreCommit` procedure definition.
>     - In `BlindProofVerify`, descriptions of
>     `disclosed_committed_messages` and `disclosed_committed_indexes`
>     are missing.
>     - In `CoreCommit`, the "Outputs:" definition is missing.
>     - In `CoreCommit`, `1. M = length(committed_messages)` references
>     a variable `committed_messages` which does not exist. Should
>     probably be `committed_scalars`?
>     - In `prepare_parameters`, descriptions of `generators_number` and
>     `blind_generators_number` are missing.
>     - In `calculate_blind_challenge`, the "Outputs:" definition is
>     missing.
>     - In the "Blind Generators" subsection of "Test Vectors", `Q1`
>     should probably be `Q2` (`Q_2`)? Q_1 is consistently used in the
>     procedures to denote non-blind generators.
>     - In "Signature Test Vectors" for BLS12-381-SHA-256, "valid no
>     prover committed messages, multiple signer messages signature",
>     the "Trace:" appears to have mislabeled the `B` value as `domain
>     =`. I don't know what the value labeled `B =` is, either.
>     - Section "9.1.5.8. valid all prover committed messages and signer
>     messages revealed proof" has the same title as "9.1.5.1. valid all
>     prover committed messages and signer messages revealed proof"
>     which does not seem to accurately describe the test vector values
>     in 9.1.5.8 (not all signer messages are revealed).
>     - In test vectors with arrays of multiple values (for example
>     `committedMessages`), the formatting is very poor and it's easy to
>     miss trailing empty octet strings. Ideally, values that fit on one
>     line should not be line-wrapped and each value should be delimited
>     clearly so that empty octet strings are clearly visible. For
>     example, consider using CDDL syntax
>     <https://www.rfc-editor.org/info/rfc8610/> [5]
>     (`h'5982967821da3c5983496214df36aa5e58de6fa25314af4cf4c00400779f08c3'`)
>     for test vector values (this allows internal whitespace, and would
>     also enable disambiguating octet strings and hex-encoded large
>     integers, among other things).
>     - A few more obvious or unambiguous errors, I have opened pull
>     requests on GitHub to fix these: #14
>     <https://github.com/cfrg/draft-irtf-cfrg-bbs-blind-signatures/pull/14>,
>     #15
>     <https://github.com/cfrg/draft-irtf-cfrg-bbs-blind-signatures/pull/15>,
>     #16
>     <https://github.com/cfrg/draft-irtf-cfrg-bbs-blind-signatures/pull/16>,
>     #17
>     <https://github.com/cfrg/draft-irtf-cfrg-bbs-blind-signatures/pull/17>,
>     #18
>     <https://github.com/cfrg/draft-irtf-cfrg-bbs-blind-signatures/pull/18>,
>     #19
>     <https://github.com/cfrg/draft-irtf-cfrg-bbs-blind-signatures/pull/19>.
>
>     Subjective style comments:
>
>     - The `Commit` procedure seems like it's part of the "public"
>     interface, so it seems like it shouldn't expose `api_id` as a free
>     parameter (instead letting it be fixed by the ciphersuite, like
>     `BlindSign` etc.)?
>     - The `deserialize_and_validate_commit` procedure seems more like
>     an "internal" procedure, so it should perhaps be under "Core
>     Operations" or "Utilities"? Its current position alongside
>     `Commit` makes it seem equally "public".
>     - In the "Test Vectors" section, this document has the subsections
>     in the order [SHA-256, SHAKE-256] while
>     draft-irtf-cfrg-bbs-signatures-10 has them in opposite order. This
>     may be an opportunity for confusion.
>     - In the "Generators" subsection of "Test Vectors", perhaps it's
>     worth pointing out that `P1` is the same `P1` as in
>     draft-irtf-cfrg-bbs-signatures-10 but `Q1` is NOT the same (since
>     it's generated by a different `api_id`)?
>     - In the "Blind Generators" subsection of "Test Vectors", does P1
>     need to be repeated from the preceding "Generators" section? Also
>     it doesn't quite seem at home in either section since it's
>     generated by its own separate DSTs in `create_generators`.
>     - In the "Test Vectors" section, it's not always obvious which
>     values are inputs and which are outputs:
>         - In "Commitment", the position of `proverBlind` alongside
>     `committedMessages` makes it look like `proverBlind` is an input.
>     - In the "Proof Test Vectors" section, the listings of
>     `revealedMessages` and `revealedCommittedMessages` are a bit
>     misleading, since the test needs to repeat _all_ the `messages`
>     and `committedMessages` from "Signature Test Vectors". Consider
>     instead repeating (or explicitly refering back to) `messages` and
>     `committedMessages` and explicitly listing `disclosed_indexes` and
>     `disclosed_commitment_indexes` as separate values.
>     - In the "Proof Test Vectors" section, `commitmentWithProof` and
>     `proverBlind` seem like unnecessary inputs (they are already
>     covered by the signature)?
>     - In the "Test Vectors" section, variables are spelled differently
>     than they are elsewhere. This is not a big problem, but it makes
>     it harder to search for the values throughout and between
>     documents if they are not consistently spelled:
>         - `Q1` is consistently spelled `Q_1` elsewhere in both this
>     document and in draft-irtf-cfrg-bbs-signatures-10
>         - `committedMessages` is spelled `committed_messages` elsewhere
>         - `proverBlind` is spelled `secret_prover_blind` elsewhere
>         - `commitmentWithProof` is spelled `commitment_with_proof`
>     elsewhere
>         - `s_tilde` and `m_tildes` are spelled `s~` and `m~` (`m~_i`)
>     elsewhere
>         - `secretKey` and `publicKey` are spelled `SK` and `PK` elsewhere
>         - `signerPublicKey` is spelled `PK` elsewhere
>         - `presentationHeader` is spelled `presentation_header` elsewhere
>         - `revealedMessages` is spelled `disclosed_messages` elsewhere
>         - `revealedCommittedMessages` is spelled
>     `disclosed_committed_messages` elsewhere
>         - `r_1`, `r_2`, `e_tilde`, `r1_tilde` and `r3_tilde` are
>     spelled `r1`, `r2`, `e~`, `r1~` and `r3~` in
>     draft-irtf-cfrg-bbs-signatures-10 (though not in its test vectors
>     section, hmm...)
>         - `m_tilde_scalars` is spelled `m~` (`m~_i`) elsewhere
>         - In the "Commitment" subsections, `seed` and `dst` are
>     spelled differently from `SEED` and `DST` in
>     draft-irtf-cfrg-bbs-signatures-10
>     - In the "Commitment" subsections of "Test Vectors", perhaps it
>     would be appropriate to reference section "8.1. Mocked Random
>     Scalars" of draft-irtf-cfrg-bbs-signatures
>     <https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-10.html#name-mocked-random-scalars> [4]
>     for what `seed` and `dst` should be used for?
>
>     Thank you for your consideration and for your work on the draft!
>     Please let me know if I can help in some way.
>
>     [1]:
>     https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-blind-signatures-02.html
>     [2]:
>     https://www.ietf.org/archive/id/dhttps://www.rfc-editor.org/info/rfc8610/https://www.rfc-editor.org/info/rfc8610/raft-irtf-cfrg-bbs-blind-signatures-02.html#name-valid-all-prover-committed-m
>     <https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-blind-signatures-02.html#name-valid-all-prover-committed-m>
>     [3]: https://www.ietf.o"valid no prover committed messages, no
>     signer messages
>     signature"rg/archive/id/draft-irtf-cfrg-bbs-blind-signatures-02.html#name-valid-no-prover-committed-m
>     <https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-blind-signatures-02.html#name-valid-no-prover-committed-m>
>     [4]:
>     https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-10.html#name-mocked-random-scalars
>     [5]: https://www.rfc-editor.org/info/rfc8610/
>
>     Emil Lundberg
>
>     Staff Engineer | Yubico <http://www.yubico.com/>
>
>
>
> _______________________________________________
> CFRG mailing list [e-mail]
> To unsubscribe send an email [e-mail]
-- 
------------------------------------------------------------------------

Dr. Greg M. Bernstein, https://www.grotto-networking.com

&#8203;