You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 in bls_signature_scheme.nim performs a subgroup check but not a check for an Infinity signature or public key. These values will return a True result.
func coreVerify[T: byte|char](
publicKey: PublicKey,
message: openarray[T],
sig_or_proof: Signature or ProofOfPossession,
domainSepTag: static string): bool =
<...comments removed...>
if not subgroupCheck(publicKey.point):
return false
let Q = hashToG2(message, domainSepTag)
# pairing(Q, xP) == pairing(R, P)
return multiPairing(
Q, publicKey.point,
sig_or_proof.point, generator1()
)
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.
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: