Tests have been added to ensure that #114 was just a documentation issue and revealed that the MIRACL backend (not used in production) could actually deserialize an invalid secret key > r.
Furthermore, for defensive programming reason, an extra precondition check in publicFromSecret has been added to recheck that the input respects 0 < SK < r. That check should never fail.
This fixes #114 and https://github.com/status-im/nimbus-eth2/issues/2695
Overview
In BLSCurve, preconditions checks for:
are done at deserialization time.
https://github.com/status-im/nim-blscurve/blob/50dbaba38fbe451cf8620e433fe0fdffe2c215f0/blscurve/blst/bls_sig_io.nim#L149-L168 https://github.com/status-im/nim-blscurve/blob/50dbaba38fbe451cf8620e433fe0fdffe2c215f0/blscurve/blst/bls_sig_io.nim#L81-L99
This means that procedures that rely on those types, like
publicFromSecret
can assume that those preconditions are already respected. This has been clarified in a dedicated document https://github.com/status-im/nim-blscurve/blob/9b7366cdc7df14c87930c3ed0243ab551a5daf56/docs/bls_types_guarantees.mdTests have been added to ensure that #114 was just a documentation issue and revealed that the MIRACL backend (not used in production) could actually deserialize an invalid secret key > r.
Furthermore, for defensive programming reason, an extra precondition check in
publicFromSecret
has been added to recheck that the input respects0 < SK < r
. That check should never fail.