Given this issue #625, it would be good to check that the implementation is compliant with the IETF draft here.
Being compliant is important, as it prevents other implementations of the node or tools from having to implement their own crypto.
Note that the audit (see this issue) has the scope of whether we are compliant.
Since the IETF is still in draft, the spec there has no test vectors. That said, previous work from @iquerejeta here does provide these.
It does not provide test vectors for the PoP or key gen (this is compliant by construction of blast; see here against the draft-6 required string). We can also consider how it was done for the other bls bindings and what this issue and work by @hjeljeli32 did.
Given this issue #625, it would be good to check that the implementation is compliant with the IETF draft here.
Being compliant is important, as it prevents other implementations of the node or tools from having to implement their own crypto.
Note that the audit (see this issue) has the scope of whether we are compliant.
Since the IETF is still in draft, the spec there has no test vectors. That said, previous work from @iquerejeta here does provide these.
It does not provide test vectors for the PoP or key gen (this is compliant by construction of blast; see here against the draft-6 required string). We can also consider how it was done for the other bls bindings and what this issue and work by @hjeljeli32 did.
FastAggregateVerifytest vector input-output-hk/bls-e2e-testvectors#1)