<p>Any Elliptic Curve could work in the BIP32 scheme. The only property of a Curve that BIP32 relies on is that a * G + b *G = (a + b mod N) * G, which is true for any Elliptic Curve. </p>

<p>Secp256k1 is a 'Koblitz' curve, which just means its choice of parameters enables very fast scalar multiplication (computing a multiple of the Generator point). </p>

<p>With that said, if a vulnerability was discovered in secp256k1, it's not like everyone could just switch over easily. That would require a major change to the Bitcoin consensus system, and require coordination of many software systems. </p>

CC BY-SA 3.0
2016-08-24T07:19:59.913Z
That's not exactly correct. BIP32 at least needs a small tweak to be usable on curves with a cofactor different from one. Ed25519 also uses a key generation scheme that forcibly sets some bits to 0 and 1, which would make BIP32 derived keys technically invalid Ed25519 keys.
Pieter Wuille
CC BY-SA 3.0
2016-08-24T12:12:32.747Z
@PieterWuille thanks. How is a cofactor greater than 1 a problem? And I wasn't aware that Ed25519 had restrictions on the keys, I'll update my answer.
morsecoder
CC BY-SA 3.0
2016-08-24T20:21:03.707Z
@StephenM347. Ed25519 isn't used for ECDSA, it is used for EDDSA.  It will be really nice to be able to generate a few billion ed25519 public keys from a xpub* extended key without knowledge of  xprv* extended keys. I'm assuming a cofactor will fix this, any idea how? Related [ed25519](http://bitcoin.stackexchange.com/questions/42437/how-to-generate-ed25519-public-key-from-private-key-using-libsodium) posting.
skaht
CC BY-SA 3.0
2016-08-24T02:48:17.583Z
2016-08-24T11:52:49.047Z
2016-08-24T11:52:49.047Z
morsecoder
<p>Does <a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki" rel="nofollow">BIP 32</a> always implicitly assume <a href="https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch04.asciidoc#generating-a-public-key" rel="nofollow">secp256k1</a> elliptic curve cryptography (ECC) is to be applied, or can BIP 32 technology also be applied to create extended public or private keys that can readily be converted to say ed25519 private/public keypairs? One of the reasons I ask is because if a mathematical or computational backdoor is ever discovered for secp256k1, can ed25519 slide right in or does BIP 32 need to be re-engineered to support ed25519?  <em>Ed25519 can also be applied to provide <a href="https://ripple.com/dev-blog/curves-with-a-twist/" rel="nofollow">Schnorr Signature</a> capabilities.</em> </p>

<bitcoin-core><cryptography><bip32-hd-wallets><math>
Is BIP 32 Technology Cryptographic Curve Agnostic?
skaht
# Is BIP 32 Technology Cryptographic Curve Agnostic?

(Asked by: username_0 on 2016-08-23)

Does [BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) always implicitly assume [secp256k1](https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch04.asciidoc#generating-a-public-key) elliptic curve cryptography (ECC) is to be applied, or can BIP 32 technology also be applied to create extended public or private keys that can readily be converted to say ed25519 private/public keypairs? One of the reasons I ask is because if a mathematical or computational backdoor is ever discovered for secp256k1, can ed25519 slide right in or does BIP 32 need to be re-engineered to support ed25519? *Ed25519 can also be applied to provide [Schnorr Signature](https://ripple.com/dev-blog/curves-with-a-twist/) capabilities.*

**Tags:** bitcoin-core, cryptography, bip32-hd-wallets, math


---

## 1 answers

### Answer by username_1 on 2016-08-24. Score: 2

Any Elliptic Curve could work in the BIP32 scheme. The only property of a Curve that BIP32 relies on is that a \* G + b \*G = (a + b mod N) \* G, which is true for any Elliptic Curve.

Secp256k1 is a 'Koblitz' curve, which just means its choice of parameters enables very fast scalar multiplication (computing a multiple of the Generator point).

With that said, if a vulnerability was discovered in secp256k1, it's not like everyone could just switch over easily. That would require a major change to the Bitcoin consensus system, and require coordination of many software systems.

> **Comments:**
> **username_2**: That's not exactly correct. BIP32 at least needs a small tweak to be usable on curves with a cofactor different from one. Ed25519 also uses a key generation scheme that forcibly sets some bits to 0 and 1, which would make BIP32 derived keys technically invalid Ed25519 keys.  
> **username_1**: @username_2 thanks. How is a cofactor greater than 1 a problem? And I wasn't aware that Ed25519 had restrictions on the keys, I'll update my answer.  
> **username_0**: @StephenM347. Ed25519 isn't used for ECDSA, it is used for EDDSA.  It will be really nice to be able to generate a few billion ed25519 public keys from a xpub* extended key without knowledge of  xprv* extended keys. I'm assuming a cofactor will fix this, any idea how? Related [ed25519](http://bitcoin.stackexchange.com/questions/42437/how-to-generate-ed25519-public-key-from-private-key-using-libsodium) posting.  

---

