[CFRG] Re: "Holder-blind" BBS Signatures?

[Emil Lundberg <[e-mail]>]

Thanks Greg! I've now had a look at PR #13, and it looks like it still
requires the Prover to directly know all the message scalars: the `messages`
parameter to `BlindProofGen`
<https://github.com/cfrg/draft-irtf-cfrg-bbs-blind-signatures/blob/758ac593a71e62d8c0efef22981a1ba61eda12e1/draft-irtf-cfrg-bbs-blind-signatures.md?plain=1#L450-L451>
is still a vector of all the messages as octet strings. The DPK in
BBS-Schnorr and BBS-BLS (from the "DBAC Paper") would need to be provided
separately as a point commitment rather than as a scalar.

I see you also started a new discussion thread in GitHub issue #20
<https://github.com/cfrg/draft-irtf-cfrg-bbs-blind-signatures/issues/20#issuecomment-4604607514>
about
what modifications would be needed to support the "DBAC Paper" scheme(s). I
agree that these extensions would require a new BBS construction that is
not backwards compatible with the draft-irtf-cfrg-bbs-signatures-10 API:
BBS.ProofGen requires direct knowledge of all message scalars, and
BBS.ProofVerify has no provision for the separate DPK proof introduced in
the "DBAC Paper" (which is needed since the DPK proof can't use the same
challenge as the other attribute proofs, as discussed in my previous
message).

I will update my implementation to align with PR #13 and try prototyping
what adjustments are needed to support BBS-Schnorr, and I'd be happy to
help sketch out a draft of what that could then look like as a CFRG draft
(likely forked from Blind BBS). Please expect some delay on that, though,
as I'm going on 3 weeks of vacation starting next week (sorry about the bad
timing).

Emil Lundberg

Staff Engineer | Yubico <http://www.yubico.com/>




Den tors 28 maj 2026 kl 19:33 skrev Greg Bernstein <
[e-mail]>:

> Hi Emil, for Blind BBS signatures we recently had some discussions with
> Dr. Lehman’s team concerning their Vision: A Modular Framework for
> Anonymous Credential Systems <https://eprint.iacr.org/2025/1981> paper.
> This paper adds a “Committed Disclosure” interface to BBS. See Section
> 3.1 of ZKP/MMS Spec
> <https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/blob/main/docs/technical-specifications/ts14-zkps-from-mms.md>.
> Vasilis recently added the PR Add extension commits
> <https://github.com/cfrg/draft-irtf-cfrg-bbs-blind-signatures/pull/13> to
> support this functionality. Might this help?
>
> We very much would like to see hardware support, if possible, for what
> some of us call “anonymous holder binding”. We can open an issue at
> https://github.com/cfrg/draft-irtf-cfrg-bbs-blind-signatures to work
> through design alternatives if you like.
>
> Cheers Greg B.
>
> On 5/28/26 05:31, Emil Lundberg wrote:
>
> Hi CFRG,
>
> I've recently been evaluating whether the "The BBS Signature Scheme"
> <https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-10.html> [1]
> or "Blind BBS Signatures"
> <https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-blind-signatures-02.html> [2]
> drafts are compatible with hardware-bound holder binding keys. In
> particular, I've been collaborating with Dr. Anja Lehmann and was hoping to
> realize the "BBS-Schnorr" scheme she and her colleagues propose in "Device-Bound
> Anonymous Credentials With(out) Trusted Hardware"
> <https://eprint.iacr.org/2025/1995> [3] for use in applications like EUDI.
>
> Unfortunately I've found that neither of the above two CFRG constructions
> seems compatible with hardware-bound holder binding keys. My hope was that
> a holder binding private key could be one of the blind messages in "Blind
> BBS Signatures", but this fails in a couple of ways:
>
> - `BlindProofGen` internally forwards to `BBS.CoreProofGen`, which
> requires passing *all* the message scalars as arguments. This is not
> possible if some of the message scalars are hardware-bound private keys
> that the holder does not have direct knowledge of.
> - Even if we could somehow create presentation proofs by some other
> procedure, there still seems to be no way to make such a proof compatible
> with `BlindProofVerify`. The proof verification needs to reconstruct the T2
> computed in `BBS.ProofInit`. That T2 is built from the random nonce scalars
> `m~` from the Schnorr NIZK proofs of each message, and then
> `BBS.ProofChallengeCalculate` hashes over T2 to compute the Schnorr NIZK
> challenge, and *all* message proofs need to use the same challenge. A
> hardware-bound key can't reveal its random nonce `m~` (since that would
> enable private key recovery) for us to compute T2 from it, and we can't
> compute T2 before the hardware element samples its `m~` (because then that
> `m~` can't be mixed into T2), so I don't see any way that "Blind BBS
> Signatures" could be compatible with hardware-bound keys as is. I suppose
> this is why Dr. Lehmann's BBS-Schnorr proposal instead decouples the device
> binding proof from the rest of the BBS message proofs and makes it a
> separate proof of possession with its own challenge value.
>
> Is there interest in CFRG in developing some "holder-blind" BBS
> construction that could be compatible with hardware-bound private keys? I
> would like to work on one based on Dr. Lehmann's BBS-Schnorr proposal.
> Unless there is some other better way to do this?
>
> I imagine this as an extension from "Blind BBS Signatures", which would
> add a third set of "holder-blind" messages. It would probably need to
> define similar but distinct variants of all 6 Commit, CommitVerify, Sign,
> Verify, ProofGen and ProofVerify procedures that are not backwards
> compatible with "Blind BBS Signatures" (except maybe with zero holder-blind
> messages). It would also define a distinct `api_id` and thus generate its
> own three sets of generators for the three kinds of messages.
>
> BBS-Schnorr as constructed in Dr. Lehmann's proposal has exactly 1
> "holder-blind" message (dpk) and no signer-blind messages, but I suspect it
> should be fairly straightforward to combine it with "Blind BBS Signatures"
> and generalize it to any number of holder-blind messages.
>
> Finally, Dr. Lehmann's proposal also includes a BBS-BLS scheme using a BLS
> signature instead of a Schnorr signature for the holder binding. I haven't
> gotten to working on that yet, but I would like a "holder-blind" BBS
> construction to also be compatible with this kind of holder binding proof.
>
> [1]:
> https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-10.html
> [2]:
> https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-blind-signatures-02.html
> [3]: https://eprint.iacr.org/2025/1995
>
> Cheers!
>
> Emil Lundberg
>
> Staff Engineer | Yubico <http://www.yubico.com/>
>
>
>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> --
> ------------------------------
>
> Dr. Greg M. Bernstein, https://www.grotto-networking.com
> &#8203;
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>