-
Notifications
You must be signed in to change notification settings - Fork 11
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
[SEC] Infinity Public Key and Signature #76
Comments
mratsim
added a commit
that referenced
this issue
Oct 26, 2020
Merged
mratsim
added a commit
that referenced
this issue
Oct 26, 2020
* Update vectors to BLSv4 v1.0.0-rc0 [skip ci] * Workaround ethereum/consensus-spec-tests#22, ethereum/consensus-specs#2099 * Rework BLSv4 API ethereum/consensus-specs#2080 and address #76 #77 * Upgade Milagro vectors * Upgrade BLST backend with new API * BLST forgot to return true for publicFromSecret
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
labels: nbc-audit-2020-1, status:reported
labels: difficulty:high, severity:informational, type:documentation
This purpose of this strictly informational issue is to raise awareness that the Infinity public key is subject to current debate, may be a source of incompatibility from other (incorrect) implementations, and its handling could potentially change in a future draft of the BLS Signature specification.
Description
The
coreVerify()
function excerpted below as implemented inbls_signature_scheme.nim
performs a subgroup check but not a check for an Infinity signature or public key. These values will return aTrue
result.The desirability of detecting and rejecting an Infinity public key or signatures is hotly debated. The code matches the IETF specification which makes no mention of the Infinity (or zero) check so the code is compliant. However, this handling conflicts with the common perception of a signature "giving the recipient very strong reason to believe that the message was created by a known sender and that the message was not altered in transit". More importantly, the first comment in the discussion indicates that the
blst
code does detect this condition when utilized via the Golang bindings.Exploit Scenario
Expectations involving an Infinity public key or signature may change and/or calculations may not give consistent results across implementations.
Mitigation Recommendation
Prominently document an explicit statement on how an Infinity public key or signature are expected to be handled.
References
https://github.com/status-im/nim-blscurve/blob/da9ae49dab4cbb95b2cdaa68ecc221ee15c67a9a/blscurve/miracl/bls_signature_scheme.nim
https://github.com/supranational/blst/blob/master/bindings/go/blst.go#L267
The text was updated successfully, but these errors were encountered: