2

How reasonable would it be to speak TLS over the secp256k1 curve? My initial experiments show that OpenSSL supports it (albeit with special flags, see below): Running an OpenSSL client against an OpenSSL server (or some random node.js server that I found) negotiates the suite ECDHE-ECDSA-AES128-GCM-SHA256 and establishes a regular TLS 1.2 session.

On the other hand, neither curl nor browsers appear to like that particular curve. (Although that is not necessary for my use case.)

The reason I'm using secp256k1 is because there is a nice algorithm to derive new keys from an existing key (BIP 32). Those keys cannot be correlated with each other, which is a big plus in peer-to-peer scenarios.

Now my question is: Is it reasonable to use an uncommon curve like secp256k1 for TLS? Or alternatively, is there a secure mechanism to derive a private key for another (more common?) curve from a secp256k1 private key?

The flags I mentioned above: -curves "X25519:P-256:P-521:P-384:secp256k1"

Edit: My question is less about theoretical weaknesses of secp256k1, but rather what kinds of practical problems to expect.

larsrh
  • 121
  • 5
  • 1
    I don't see any reason why using that curve would be unreasonable or why it would pose any practical problems; the outward interface for prime or binary curves doesn't differ all that much (unless you're directly specifying the domain parameters of course). – Maarten Bodewes Jul 31 '19 at 13:09

2 Answers2

2

BIP32 uses secp256k1 because BIPs are for bitcoin and bitcoin uses secp256k1. (I feel like Buffy 1.01: "[the reason I'm here now is] because now is when we came here".) The same approach(es) would work for any elliptic curve, with obvious substitutions for ser256 and parse256, and for serp if using a non-Weierstrass form like X25519.

But TLS in practice requires certificates for authentication keys (or kRSA, no longer recommended and in 1.3 no longer supported) and certificates don't mix well with rapidly or dynamically creating keys, via BIP32 or any other means, regardless of the curve(s) used. ('In practice' because there is an RFC for using raw keys, but I've never seen an implementation, certainly not in OpenSSL.)

PS: nodejs builtin 'tls' is OpenSSL, compiled into node[.exe] underneath. You can get alternative (pure-JS) crypto including ECC, but I haven't seen pure-JS TLS.

dave_thompson_085
  • 6,319
  • 1
  • 21
  • 23
  • It's not obvious how to securely adapt BIP32 for other curves. In this paper the authors argue that the initial attempt is indeed insecure. I don't consider this researched enough to just implement it for another curve. – larsrh Jul 30 '19 at 06:09
0

After some prototype implementations, here is what I learned:

  • This is possible. OpenSSL and Java support it, which is good enough for my use case.
  • Client certificates work without problems.
  • It requires some configuration effort (in particular for OpenSSL).
  • It is not supported by TLS 1.3, only by 1.2. If that's good enough, then there should be no problem.
larsrh
  • 121
  • 5