3
$\begingroup$

I read SafeCurves it indicates Secp256k1 is not SafeCurve by their standards but bitcoin and ETH use it in their blockchain.

I researched more and figured out that using Secp256k1 ECDSA(singing algorithm not encrypting) is safe and has no problem, since those laking standards are not important in ECDSA but are in ECIES

so my questions are :

  1. how much Unsafe is using secp256k1 for ECIES and what dangers/weakness it exposes /what attack it makes possible

  2. should I avoid secp256k1 completely(for ECIES) or I can use in some circumstances

  3. what cures are safe for ECIES (since Curve25519 is only implemented for ECDSA)

$\endgroup$
3
$\begingroup$

How much Unsafe is using secp256k1 for ECIES and what dangers/weakness it exposes /what attack it makes possible?

Let's have a look through the "failures" that secp256k1 achieves according to SafeCurves.

  • ECDLP: "disc": This means that the curve has a specific value to be small. As the website indicates this is not inherently bad or exploitable, it just means a (minor?) speedup is possible for the brute-force search. Because a large value is "safer" here a curve has to achieve that.
  • ECC: "ladder": This means that a naturally fast and side-channel resistant scalar multiplication algorithm isn't possible for this curve. However side-channel resistant implementation is still possible (though it requires a bit more care).
  • ECC: "complete": This means you have to do a case-distinction if you want to add two points $P,Q$ (in theory making side-channel resistant implementations harder). However this is irrelevant in practise given that the case distinction for secp256k1 is "$Q=-P$" or "$Q=P$" or "$Q\neq \pm P$" and for any sane scalar multiplication algorithm we can in fact predict which case will happen at any point with 100% accurcacy, so the fact that there is a case distinction doesn't matter.
  • ECC: "ind": This means that if you are given a string you can efficiently decide whether you're looking at a random string or a random point on the curve. This most likely won't matter to you unless you have some super fancy protocol that relies on this property, but things like ECDSA and ECDH / ECIES are not included in this.

Should I avoid secp256k1 completely or I can use in some circumstances?

For "standard" use-cases, i.e. ECDH / ECIES / ECDSA and similar "simple" applications you can use secp256k1 just like Curve25519 assuming you have a secure implementation. The only place where you can't is when you need the indistinguishability property, but that seems to not be the case here.

What cures are safe for ECIES (since Curve25519 is only implemented for ECDSA)?

Curve25519 should be usable for ECIES given that ECIES is essentially "do a ECDH key exchange with a fixed public key and then hash to shared secret to be used as a symmetric key" and the standardized version of Curve25519 for Diffie-Hellman is also sometimes called X25519.

| improve this answer | |
$\endgroup$
  • $\begingroup$ From the end of the discriminants page: but it is also conceivable that curves with large |D| are much easier to break. $\endgroup$ – kelalaka Mar 14 at 17:13
  • $\begingroup$ great answer, thanks a lot $\endgroup$ – emaditaj Mar 14 at 18:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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