-
Notifications
You must be signed in to change notification settings - Fork 16
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
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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, | ||
|
@@ -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 | ||
~~~ | ||
|
@@ -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. | ||
- 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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, not There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On tangential note. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Do you mean like "ever"? I.e. not only here, but everywhere else and always? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah -- it's a separate question, and one raised on the list. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I'm not very good at reading cues, is it "it was a distraction, forget about it," or "any thoughts?" There was a problem hiding this comment. Choose a reason for hiding this commentThe 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?) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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. |
||
5. raise "invalid signature" error | ||
~~~ | ||
|
||
# Ciphersuites {#ciphersuites} | ||
|
||
This section defines the format for a BLS ciphersuite. | ||
|
There was a problem hiding this comment.
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 as1 < R < r
? More specifically "more than 1" to ensure that1/R
!=R
?There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 :))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Algebraically it's fully symmetric. I mean it does work either way.
There was a problem hiding this comment.
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.