A Secure Multiple Elliptic Curves Digital Signature Algorithm for Blockchain

Most cryptocurrency systems or systems based on blockchain technology are currently using the elliptic curves digital signature algorithm (ECDSA) on the secp256k1 curve, which is susceptible to backdoors implemented by the curve creator (secp256k1). The paper proposes a multiple elliptic curves digi-tal signature algorithm (MECDSA), which allows not only for setting the number of elliptic curves according to practical security requirements, but also for editing the parameters of each elliptic curve. The performance analy-sis proves that the scheme is secure and efficient, and can avoid any back-doors implemented by curve creators. We suggest that the systems based on blockchain should operate in two elliptic curves considering the contradic-tion between security and efficiency.

💡 Research Summary

The paper addresses a growing concern in cryptocurrency and blockchain systems that rely on the elliptic‑curve digital signature algorithm (ECDSA) instantiated on the secp256k1 curve. Because secp256k1 was designed in a non‑random, highly optimized way, its parameters could conceivably contain hidden weaknesses or backdoors inserted by the curve’s creator. To mitigate this risk, the authors propose a Multiple Elliptic‑Curve Digital Signature Algorithm (MECDSA).

MECDSA allows a signer to choose any number t of elliptic curves and to define the full set of domain parameters (p, a, b, G, n, h) for each curve. For each curve E_i the signer generates a private scalar d_i and a random nonce k_i, computes the point k_i G_i = (x_{i1}, y_{i1}), and derives r_i = x_{i1} mod n_i. All r_i values are summed (mod n_i) to produce a single r value that is shared across the curves. The signature component for curve i is s_i = k_i^{-1}(e + r d_i) mod n_i, where e = H(m) is the hash of the message. The final signature is the tuple (r, s_1, …, s_t).

Verification mirrors the standard ECDSA steps on each curve: using the public key Q_i = d_i G_i, the verifier computes u_i = s_i^{-1} e mod n_i and v_i = s_i^{-1} r mod n_i, then evaluates the point u_i G_i + v_i Q_i. The x‑coordinate of each resulting point is summed; if the sum equals the transmitted r, the signature is accepted.

The security argument rests on the hardness of the elliptic‑curve discrete logarithm problem (ECDLP) for each individual curve. An attacker who wishes to recover any private key d_i must solve the ECDLP on the corresponding curve, which is believed to require exponential time. Even if a backdoor exists in one curve, the remaining honest curves still protect the overall signature because the verification equation involves all curves simultaneously. Consequently, the scheme’s security is essentially the product of the security of each chosen curve.

Performance is evaluated by counting elliptic‑curve point operations. For t‑ECDSA (repeating the single‑curve algorithm t times) the cost of signing is t point multiplications and t point additions; verification requires 2t multiplications. MECDSA reduces the number of point additions to 2t − 1 for signing and t − 1 for verification, while the number of multiplications grows to 2t for signing and 2t for verification. The signature length grows from 2 field elements (r, s) in standard ECDSA to 1 + t field elements (r plus t s_i’s). The authors argue that using two curves (t = 2) offers a practical trade‑off: the signature size roughly doubles, but the added security against a compromised curve outweighs the bandwidth cost in most blockchain contexts.

The paper also provides an appendix listing the parameters of several well‑known curves (P‑256, SM2, secp256r1, secp256k1) and suggests that users may define custom curves beyond these standards.

Critically, the manuscript does not present a formal security proof beyond the intuitive reduction to independent ECDLP instances, nor does it discuss how to ensure that user‑defined curves are free from subtle weaknesses (e.g., small subgroup attacks, anomalous curves). The lack of guidance on safe parameter generation could lead to insecure deployments. Moreover, the increase in signature size may impact block size limits and light‑client synchronization, especially in high‑throughput networks. Side‑channel resistance, key‑management complexity, and interoperability with existing wallets are also not addressed.

In conclusion, MECDSA offers an interesting architectural approach to diversify trust across multiple elliptic curves and to mitigate the risk of a single compromised curve. Its practicality hinges on careful selection of curves, standardized parameter validation, and integration of side‑channel countermeasures. If these engineering challenges are resolved, a two‑curve MECDSA could be a viable enhancement for future blockchain platforms seeking stronger assurance against hidden curve backdoors.