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

[SEC] Infinity Public Key and Signature #76

Closed
eschorn1 opened this issue Sep 4, 2020 · 0 comments
Closed

[SEC] Infinity Public Key and Signature #76

eschorn1 opened this issue Sep 4, 2020 · 0 comments

Comments

@eschorn1
Copy link

eschorn1 commented Sep 4, 2020

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 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.

References

  1. https://github.com/status-im/nim-blscurve/blob/da9ae49dab4cbb95b2cdaa68ecc221ee15c67a9a/blscurve/miracl/bls_signature_scheme.nim

  2. https://github.com/supranational/blst/blob/master/bindings/go/blst.go#L267

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
@mratsim mratsim closed this as completed Sep 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants