For reasonable security, EC private keys are typically 256-bits. Shorter EC private keys are not sufficiently secure. However, shorter symmetric keys (128-bits, for example) are comparably secure.
I have a case where I need to regenerate an EC private key (that can be constructed by a special method) with as little stored information as possible. Fewer than 128-bits is not possible without compromising security against an exhaustive search.
I'm curious if I can use the following method:
Generate a random 128-bit value. This is the value I would store to recreate the private key.
Use a 256-bit hash, say SHA256, of the random value as the private key. (I have a method to do this that doesn't bias any keys over any others.)
The corresponding public key would be made public.
Thus, I can regenerate the private key from the 128-bit value. It seems to me that the private key and 128-bit value should be just as secure as using a random 256-bit value for the private key and storing that. Exhaustive search is clearly impractical, and the properties of the EC key shouldn't be capable of being walked backwards either from the public key or through the hash. In principle, the EC search space is halved, but it doesn't seem like there would be any practical way to take advantage of this.
Is there anything I'm missing? Is there any reason this wouldn't be just as secure as storing the full 256-bit key? Assume the public key and the algorithm are known to potential adversaries. The adversary's goal is to get the private key. It seems to me that this is obviously as secure as the underlying algorithms, but I know enough not to trust myself.