17

I'm developing a client/server system in Java which is not interacting with third-party software, so I don't have to worry about compatibility.

At a certain point, I need the client and server to exchange a digitally signed value. I thought to use ECDSA, but I'm not sure what curve and what key length should I use. I'm mostly worried about the security rather than the computational time or the length of the signature.

I'm using BouncyCastle for security-related operations, so the curve and key length must be supported by it. Here you can find a list of curves supported by BouncyCastle.

Do you have any advice?

R1w
  • 1,952
  • 4
  • 20
  • 45
Marcello
  • 347
  • 1
  • 2
  • 5

2 Answers2

17

SafeCurves lists some ways to compare the security of elliptic curves. Their security criteria are split to "ECDLP security" and "ECC security". Failing the former basically means "there is no way to use this curve securely in general" while the latter "it is difficult to implement this curve securely".

None of the (few) BouncyCastle-supported curves that have been looked at on SafeCurves pass all the criteria. Some fail the "rigidity" ECDLP criteria, which means that there is no way to show that the parameters haven't been chosen so there is a backdoor. If you fear that e.g. NSA has backdoored ECC, you should avoid those curves.

The one that does best is brainpoolp384t1. If passes all the ECDLP criteria as well as having twist security. That means it is the easiest to correctly implement. The other Brainpool curve they've looked at, brainpoolp256t1, also passes all the ECDLP criteria and so can be implemented securely. Without knowing anything about BouncyCastle's implementation, it is impossible for me to know whether the former curve has an advantage or even if both are in fact broken.

Regarding key length, there are various recommendations by different parties. They mostly agree that 256 bits is enough through at least 2030. So either of the two Brainpool curves I mentioned above would fit the bill. 384 bits is enough for Top Secret according to NSA.

In short, then, brainpoolp384t1 would be a conservative choice, since you don't care about computational time or space usage. That's not to say any of the others are bad choices, or that some other curve (e.g. one of the 512-bit Brainpool curves) isn't even better.

otus
  • 32,132
  • 5
  • 70
  • 165
  • Unfortunately, it looks like SafeCurves hasn't been updated since January 2017. That is an eternity in the world of crypto. What curves are good to use nowadays? – Yitz May 25 '20 at 15:16
  • Here is a recent article about SafeCurves that put things into a more modern perspective: https://satoshinichi.gitlab.io/b/safecurves-scare.html – Yitz May 25 '20 at 16:46
3

You may probably use any curve you like, depending on your special requirements (environment, computational aspects, ...) and the curves implemented by your library (see otus answer refering to some concrete security findings related to specific elliptic curves, and how sensible they are to certain attacks). The reason why the curves are pre-computed, is because it is much harder to set up an EC crypto system than one based on a "standard" cyclic group with integer elements rather than points on a curve (the actual reason is that it's time-consuming to compute the order of a curve).

Even though the outer parameters of the curve are public domain ($a, b, p, order(E), P$) there are not enough ink-atoms in the universe to store all points of a curve (given the number of points on the curve is large enough - see "security levels" below). This means, that you don't need to be worried, that one curve may be less secure than another because someone might have precomputed and stored all the points, which would render security nil.

For the key-length the parameter "size" published on the bouncycastle page probably refers to the minimum size in bits of the hash output, which is a the same time the order of the cyclic group generated by the chosen generator point $P$. You can call this your key size.

Today (in 2014) in ECDSA the security level of a 192 bit key is 96 bits, and a 512 bit key provides a security level of 256 bit.

A security level of $n$ bit means that the best known attack for that algorithm at that point in time requires $2^n$ steps. Since research is ongoing the selection of a security level is a trade off between efficiency and the belief that the best known attack is not the actual best attack (to come). In any case it is a function of time.

mwhs
  • 345
  • 5
  • 9
  • Are you sure 512bits? I think it should be 521bits. As an evidence, Invalid ECDSA key length: valid lengths are 256, 384 or 521 bits output from OpenSSH when I type wrong length for ecdsa. – pah8J Dec 29 '18 at 03:30
  • @pah8J The 512 bit key is a theoretical length that is put in relation to the security level. A 521 bit key will give a slightly higher level. The reason OpenSSH probably uses a key length of 521 bits is that in their implementation they failed to find a good candidate for a prime which is just a bit smaller than 512 bits. Some ECDSA curves for instance also have a fixed key length, the option will be ignored. In any case don't be worried about 512 or 521 bits. – mwhs Jan 15 '19 at 05:04
  • @pah8J The 521 bits is actually a recommended finite field according to FIPS 186-2 when it comes to implementing ECs in software. You can read about it here: https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#cite_note-25 – mwhs Jan 15 '19 at 05:11