How large should a seed possibility space be to generate a secure ECDSA key pair?

Question

I have a function that generates a random 16 character length (upper + lower case letters plus numbers) seed password:

const crypto = require('crypto');

function generateRandomString() {
  const charset = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";
  const length = 16;

  const randomBytes = crypto.randomBytes(length);
  let randomString = '';

  for (let i = 0; i < length; i++) {
    const randomIndex = randomBytes[i] % charset.length;
    randomString += charset.charAt(randomIndex);
  }

  return randomString;
}

// Example usage:
const randomString = generateRandomString();
console.log(randomString);

This random string is then used as a seed to generate an ECDSA key pair.

What worries me is that the range of seed (62^16) approx is 4.7 *10^28 which is considerably less than the 256bit input needed to securely generate an ECDSA key according to my reading.

Whilst I can use an algo to increase the size of the seed input to the required 256bit input needed to generate the ECDSA key, wouldn't the reduced possibility space of the input hinder the safety of the key pair?

Answer 1

It is possible to simply calculate the amount of possibilities and then take the $\log_2$ to get the number of bits that you are using. In this case that means $\log_2(62^{16}) \approx 95$.

However, that is assuming that there is no bias in the chosen values. If you choose a value of 0..255 and you then take the modulus using 62 then there is an obvious bias for the first 8 values. This is why most runtimes come with a specific function to get an unbiased value in a (zero-based) range from a random number generator. That said, the bias will however make little difference in the distribution of the passwords nor the achieved security strength (in bits).

In principle there is no requirement of having 256 bits of randomness for a 255 or 256 bit ECC key. Those keys have a security strength of about 128 bits. So having 128 bits of "seed" could be enough, if well applied. 95 bits is however considerably less than 112 bits that are commonly thought of as the minimal size for legacy applications / real time information. Nobody is going to crack 95 bits anytime soon, but I would definitely not recommend this for high security applications.

"wouldn't the reduced possibility space of the input hinder the safety of the key pair?" uh, yes, by definition. If you want to have more possibilities then you either need to extend your alphabet or the size of the generated "seed". Otherwise the security will keep stuck at around 95 bits.