What is a good and bulletproof private key for ECC curves?

Question

I am quite new to cryptography low-level mathematic details, though had worked in the crypto area for 2.5 years before. So if I am wrong about any of below part, please correct me without a facepalm gesture ;)

There are already some discussion about this along with questions about what is a valid private key per say, but none of those answers is convincing. At least I don't agree with their arguments that any valid private key is a good key.

e.g.

EdDSA (Ed25519) is any random number sufficient for a good private key? Yes .... answered Oct 28 '17 at 9:03 Frank Denis

Are all possible EC private keys valid? @Fozi: 1 is neither better or worse than 0x3b6ddba1f4b325cee4505084bc507d2019e86539f8d4be027004b69f9aa0bc74, as long as they have equal probability of occurring, namely 1/n or about ∼1/2256, so that the adversary has no better probability of success by guessing one or the other first. Note that the probability of getting either one of them individually is negligible, just like any other possible secret scalar. – Squeamish Ossifrage Sep 11 '17 at 18:28

Here is my argument:

AFAIK, a public key is calculated by multiplying n times of generator point G, where n is a random number generated as private key.

The notion is pub = n * G

Then for any known curve, I can calculate a million public keys as a rainbow-alike table, where n ranges from 1 to 1,000,000. That would take only 32 MiB space in case of a 256-bit curve. If somebody use any value in that range to generate a public key, I can easily nail it by comparing it to the table. In practice, test vectors for a given curve normally starts from n = 1, 2, 3, ... e.g. https://crypto.stackexchange.com/a/21206/95843

In a wilder scale, someone can store even a 1TiB or 1PiB(oh money!) this type of table. So in that sense, any private key less than 2^20 or even 2^50 is not good!

Now from above deduction the lower bound of private key is settled. But is there a Upper bound? Or any valid number above the lower bound is good and bullet proof enough?

Answer 1

What's so special about the first 1 million keys? Isn't there also a small rainbow table containing keys in the range 1M to 2M, and a small rainbow table containing keys in the range 2M to 3M, and a small rainbow table containing keys in the range 842347283958M to 842347283959M, etc etc?

The same logic that makes you concerned about small keys (less than 1M) can also make you equally concerned about keys in any range! No matter which key I have, there is indeed a small rainbow table out there somewhere that could allow someone to easily break my key. But an attacker would have to know which of the $2^{236}$ of the possible rainbow tables (ranges of keys) to try!

I think it's a mistake to think of a particular range of keys (from 0 to 1M, for example) as being problematic in a special way. If the lowest range of keys are especially bad, then the key generation process should avoid them. But then the next lowest range of keys become bad by the same logic, so you should avoid them too. This chain of logic concludes with no safe keys to choose from.

Answer 2

The question is correct that any private key less than 2⁵⁰ can be found from the public key, and the method that it describes would be practicable. However

• There are much better methods, that can find a key less than k² with effort proportional to k (e.g. Pollard'd rho), and little memory, with sizable probability. Thus 2⁵⁰ operations are enough to find a key less than 2¹⁰⁰ with sizable probability.
• 2⁵⁰ is a small number for a number of operations to break crypto. In the 1970's, the NSA agreed that DES has 2⁵⁶ keys, because they knew they could break that if necessary. By 2000, the baseline for security was 2⁸⁰. The modern baseline might be 2⁹⁶, and practice for new systems is in the order of 2¹²⁸ or more. That's before squaring to account for the attacks above.

is there a Upper bound?

Yes. For every Elliptic Curve-based signature method and curve, there is a prescribed set for private keys. For ECDSA, it's the interval [1, n-1] where n is the order of the generator (not the n in the question). The value of n depends on the curve. For curve secp256k1, n is a little below 2²⁵⁶. Thus the expected effort to find the private key by the public key using Pollard's rho (or any other known method) is in the order of 2¹²⁸ operations (additions on the Elliptic Curve), or more.

If the upper bound was exceeded, the private key would be rejected by compliant software. If it was not rejected, and the software was working correctly from a mathematical standpoint, and for signature systems where the private key is directly what multiplies the generator to form the public key (as in the question and ECDSA), the key would work as if it was reduced modulo n (the order of the generator), both for generating the public key, and signing.

Rules for private key generation depend on the signature system; e.g. Ed25519 specifies a space for the private key that's much larger than n, in order to improve resistance to some attacks (but not to finding a private key generating valid signature).

---

Removing possible keys in a manner known to the adversary decreases security, because the adversary has less keys to test. It's tolerable to remove a few possible keys. It's not desirable in any way.

The usual/recommended/best way to select a private key is uniformly at random in the set of valid private keys values. It's tolerable to exclude some values (like small values as in the question), but that's only as long as only a small fraction of the values are rejected. E.g. for ECDSA on secp256k1 it would be OK to reject private keys less than 2¹⁹², because that removes only a minuscule proportion about 2^-64 (0.000000000000000005%) of the keyspace. But that's also pointless, because it's so improbable one of the excluded key is generated. And increasing the lower bound so that this proportion becomes non-negligible will non-negligibly reduce our choice of keys, allowing a specially designed key search algorithm to find it easier than for a uniformly random choice.

An ECDSA private key on secp256k1 can be generated by rolling an hex dice 64 times (if the first 23 throws all yield the same value, question the dice and stop). Faithfully use the 64 results, in big-endian order. The outcome is a valid private key (the test we did insures the outcome is in the appropriate interval).