Last month, we have identified **a minor issue** in our implementation of the BLS signature on G1 used in the newly launched fastnet network. This is an RFC compliance issue which led us to plan the launch of a new compliant quicknet network and to spin down fastnet.

The Issue

While not a security issue for drand, the problem is affecting our “hash to curve” function, used to map round numbers to a point on the elliptic curve that get signed using **threshold BLS** by the drand network. The issue relates to the upcoming Hash To Curve RFC 9380, which mandates specific “Domain Separation Tags“ (DST) for certain curves. In the BLS curve case, where we have two different groups (G1 and G2) that we can map to, the RFC recommends using different DST for both groups (it’s the point of having a DST!). Sadly, our implementation of BLS signatures was initially written to perform signatures on G2 and not on G1… (Stay tuned for an upcoming blog post about the choice of the group for BLS signatures!) The usage of a global variable in our codebase for the DST meant that both our G1 and G2 implementations were sharing the same DST. Since we don’t have “official test vectors” for BLS signatures on G1 and G2, this went unnoticed until **someone tried** to verify our signatures done on G1 with a C++ implementation and reported the issue in our Slack.

We launched our fastnet Testnet in February to try and identify any potential issues, while also allowing people to start building their applications on top of our new design featuring unchained randomness and timelock capabilities. Despite this, the issue went unnoticed in all signature verification implementations that we tried with our drand beacons (including our typescript **drand-client** codebase and two different third party Rust implementations of drand verification!). Amusingly, within weeks of this issue being identified, a second team, building their own timelock scheme on top of our new fastnet network, also identified the issue and reported it to us.

For us, the main takeaways here are:

Next Steps

This issue means that all beacons emitted for the new fastnet network that we launched on March 1st are featuring signatures that are non-compliant with the hash to curve spec, and so is the case for beacons from our testnet.

While not a security issue for our usage, using the wrong domain separator tag to map points on G1 is non-compliant with the RFC and therefore not great for future compatibility and adoption of our new network. We have **already implemented a new, RFC-compliant scheme** for drand, affectionately named bls-unchained-g1-rfc9380.

During investigations, we identified 4 main ways to solve this issue:

Given the above, The League of Entropy has voted and elected to choose the last option, using its governance process, and therefore will: