0
$\begingroup$

Many cryptocurrencies use Secp256k1.

Every cryptocurrency library comes with its own redundant implementation of Secp256k1, ECDSA, RIPEMD160, and SHA256. So, there can be some inconsistencies across implementations.

What if some library generates a private key using a different curve than Secp256k1? For example, one with less security, or even a backdoor. Choosing different points, etc.

Then they share only the public key with blockchain, of course. Is it possible that such a thing would work? Can some public key appear valid for Secp256k1, but in fact use another elliptic curve?

I just came across many open source cryptocurrency libraries where they generate private keys and everyone is using custom implementations of these. So I should at least compare source code and look for some specific set of constants.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

The Bitcoin network expects secp256k1 when adding something to its blockchain. If you use another curve, it naturally will not produce a valid secp256k1 public key capable of validating the secp256k1 signatures and will be rejected by the network. If some client uses a bugged or even backdoored version of the curve, the client will simply not be able to add anything to the blockchain. This would only become a risk if a significant portion of the network ended up using this same bad library, effectively resulting in a fork of the core client and an entirely new, separate protocol.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Yes, that is the basic blockchain knowledge. I'm asking from point of cryptography if someone can create their own elliptic curve, that would appear as valid for secp256k1, but also contain some hidden properties in private key. Public key would appear as secp256k1 valid. $\endgroup$
    – Lukáš Cyberluke Satin
    Commented Feb 19, 2019 at 10:54
  • 1
    $\begingroup$ @LukášCyberlukeSatin No, you cannot create a public key that differs from secp256k1 but also functions correctly when operated on as a key using the secp256k1 curve (i.e. "appear valid"). $\endgroup$
    – forest
    Commented Feb 19, 2019 at 10:56
  • $\begingroup$ Ok, so that means if someone would have buggy implementation, it would generate invalid signature. There is no space for collision of compressed form of base point G in the curve. Because I know all these stuff on paper looks bulletproof, but the problem is someone make "more unified" implementation and it can be also used somehow creatively, which creates some form of exploit. That's how all security holes are mostly created. $\endgroup$
    – Lukáš Cyberluke Satin
    Commented Feb 19, 2019 at 11:04
  • 2
    $\begingroup$ @Lukáš Cyberluke Satin: nevertheless, there are ways to make exploitable software that is compatible with correct one; e.g. has a signature verification code that accepts some signatures with a certain hidden characteristic, when it should not. $\endgroup$
    – fgrieu ♦
    Commented Feb 19, 2019 at 18:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.