Conversation
| 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.
Well, not message, but PK || message, right? I mean since you blind PK || message, you have to verify PK || message...
There was a problem hiding this comment.
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."
There was a problem hiding this comment.
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.
Is there a benefit to not always doing augmentation?
Do you mean like "ever"? I.e. not only here, but everywhere else and always?
There was a problem hiding this comment.
Yeah -- it's a separate question, and one raised on the list.
There was a problem hiding this comment.
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?"
There was a problem hiding this comment.
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.
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 :-)
| - message, an octet string. | ||
|
|
||
| Outputs: | ||
| - R, a scalar in G1. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
(Also, separately agreed on the constraint for R :))
There was a problem hiding this comment.
this would only work over E1
Algebraically it's fully symmetric. I mean it does work either way.
There was a problem hiding this comment.
Sorry, I mean that the change constrained itself to one curve, not that the mechanism itself doesn't work across both.
2 participants
Opening as a draft for #37. This change sort of pins the message augmentation variant (mixing in the public key into the encoded message). I've not yet considered the interaction with the PoP variant.
As usual, all bugs are my own!
cc @dot-asm, @veorq, @zhenfeizhang, @kwantam to start