Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First cut at blind BLS. #45

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
129 changes: 128 additions & 1 deletion draft-irtf-cfrg-bls-signature.md
Original file line number Diff line number Diff line change
Expand Up @@ -700,6 +700,25 @@ Procedure:
5. return VALID
~~~

## CoreEvaluate {#coreevaluate}

The CoreEvaluate algorithm multiplies the secret key SK by a point Q to
produce another point Z.

~~~
Z = CoreEvaluate(SK, Q)

Inputs:
- SK, a secret integer such that 1 <= SK < r.
- Q, a point

Outputs:
- Z, a public key encoded as an octet string.

Procedure:
1. return SK * Q
~~~

## CoreSign {#coresign}

The CoreSign algorithm computes a signature from SK, a secret key,
Expand All @@ -717,7 +736,7 @@ Outputs:

Procedure:
1. Q = hash_to_point(message)
2. R = SK * Q
2. R = CoreEvaluate(SK, Q)
3. signature = point_to_signature(R)
4. return signature
~~~
Expand Down Expand Up @@ -1083,6 +1102,114 @@ Procedure:
6. return CoreVerify(PK, message, signature)
~~~

# Interactive BLS Signatures {#interactive-bls}

This section describes an private, interactive protocol between signer (server)
and verifier (client) for computing the BLS signature variants in {{schemes}}.
At a high level, the signer and verifier interact to compute a blind signature
protocol yielding `signature = Sign(SK, message)`, where `msg` is the private
message to be signed, and `SK` is the server's private key. In this protocol,
the signer learns nothing of `message`, whereas the verifier learns `signature`
and nothing of `SK`.

This protocol roughly runs as follows:

~~~
Verifier(PK, message) Signer(SK)
-------------------------------------------------------
blind_msg, R = Blind(PK, message)

blind_msg
---------->

blind_sig = BlindSign(SK, blind_msg)

blind_sig
<----------

signature = Finalize(PK, message, R, blind_sig)
~~~

Upon completion, correctness requires that clients can verify signature `signature`
over private input message `message` using the server public key `PK` by invoking
the Verify routine. The finalization function performs that check before returning
the signature.

## Blind {#proto-blind}

The Blind function takes as input the signer public key `PK` and message to sign
`message` and produces a blinded message and blind inverse.

~~~
signature = Blind(PK, message)

Inputs:
- PK, a public key in the format output by SkToPk.
- message, an octet string.

Outputs:
- R, a scalar in G1.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "in G1" mean? That blind signatures make sense only over E1? If so, then it's arguably not optimal spot for such statement. And if not, then it's a number less than r irregardless the curve. BTW, should one specify it as 1 < R < r? More specifically "more than 1" to ensure that 1/R != R?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I was assuming that this would only work over E1, though maybe that constraint is not strictly necessary?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Also, separately agreed on the constraint for R :))

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this would only work over E1

Algebraically it's fully symmetric. I mean it does work either way.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I mean that the change constrained itself to one curve, not that the mechanism itself doesn't work across both.

- blinded_msg, an octet string.

Procedure:
1. R = G1.RandomScalar()
2. T = hash_to_point(PK || message)
3. blinded_msg = point_to_signature(R * T)
4. return R, blinded_msg
~~~

## BlindSign {#proto-sign}

The BlindSign function invokes CoreEvaluate directly without modification.
Signers SHOULD perform a membership check on the input blind message Q before
the result is passed to CoreEvaluate.

<!-- What is the best way to invoke a membership test here? -->

~~~
signature = BlindSign(blinded_msg)

Inputs:
- blind_message, an octet string.

Outputs:
- blind_sig, an octet string.

Procedure:
1. Q = signature_to_point(blinded_message)
2. Z = CoreEvaluate(SK, Q)
3. blind_sig = point_to_signature(Z)
4. return blind_sig
~~~

## Finalize {#proto-finalize}

The Finalize function unblinds the signer's blind signature, verifies
the corresponding signature, and outputs the resulting signature if valid.
Otherwise, it raises an error. Verifiers SHOULD perform a membership check
on the input blind signature Y before the result is combined with the blind
inverse (R\_inv).

~~~
signature = Finalize(message, PK, R, blind_sig)

Inputs:
- message, an octet string.
- PK, a public key in the format output by SkToPk.
- R, blind inverse output from Blind.
- blind_sig, an octet string.

Outputs:
- blind_sig, an octet string.

Procedure:
1. Y = signature_to_point(blind_sig)
2. R_inv = R^-1
3. signature = point_to_signature(R_inv * Y)
4. if CoreVerify(PK, message, signature), return signature
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, not message, but PK || message, right? I mean since you blind PK || message, you have to verify PK || message...

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On tangential note. PK || message spells message-augmentation and question if it should be reflected in DST. Well, question is also "what would be the [recommended] DST."

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, good catch! I was questioning why'd even both with the basic mode while writing this. Is there a benefit to not always doing augmentation?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a benefit to not always doing augmentation?

Do you mean like "ever"? I.e. not only here, but everywhere else and always?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah -- it's a separate question, and one raised on the list.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's a separate question

I'm not very good at reading cues, is it "it was a distraction, forget about it," or "any thoughts?"

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, sorry :) I mean, what do you think about dropping basic mode altogether and always augmenting the message? (We might want to just have this discussion on the list?)

Copy link

@dot-asm dot-asm Aug 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what do you think about dropping basic mode altogether and always augmenting the message?

I can't think it. Well, I can think of these two things separately but not as one or two interdependent. I mean one can discuss omission of the Basic scheme, but it doesn't actually translate to "always augment." Because at least you need a non-augmented sign for PoP. Or shall we discuss removing even PoP? But then this asks for the question "what's criteria for inclusion/omission"? Note that this can be turned even against this PR. Indeed, why this blind signature scheme? ;-)

As for the referred message. In my mind it effectively asks why doesn't the draft describe a specific application? Well, I can't speak for the draft authors, but it appears to me that it was the original intent. That is to be application-agnostic, and rather provide a kind of a foundation for specific applications. I mean In other words, the correct question would be rather "where are the application specifications?" and not "why doesn't this draft describe one/mine?" I might be wrong of course, as, again, I don't claim to know the original intent or its evolution :-)

5. raise "invalid signature" error
~~~

# Ciphersuites {#ciphersuites}

This section defines the format for a BLS ciphersuite.
Expand Down