What curve and key length to use in ECDSA with BouncyCastle

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 the 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.

-

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.

-

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.

-