# Is it correct that more than 160 bits of input data for producing a private key are superfluous?

If this is true, when I make a 64 character hexadecimal private key I need only provide randomness for the first 40 characters (40 x 4 bits per character = 160). The remaining 24 characters can be zeros.

• We'd have to know what algorithm you're using to produce the private key. Aug 28 '14 at 16:22
• A deck of shuffled cards. There are four suits (hearts, clubs diamonds, spades) so two cards drawn from the top allow 16 permutations of suit combination; each one of the sixteen permutations corresponds to a hexadecimal digit. After eight hexadecimal characters have been determined, I reshuffle the pack before determining the next eight characters. To date I have done this to produce all 64 characters, but need I only produce 40 in this way? The problem is more theoretical than practical as producing the remaining 12 characters by cards is not much work. Aug 29 '14 at 7:36
• Oh, you mean actually putting zeroes in the private key?! No, that's completely unsafe. Aug 29 '14 at 17:24

No, that's not correct at all. If someone knew that your private key contained 96 zero bits, their search space would be drastically reduced. 256-bit private keys are used because they are the minimum considered sufficient to provide the level of ECDSA security required. 160-bits can be used in the hash function because hash functions get more security per bit than ECDSA does.

You could, however, use 160-bits as a seed to generate a 256-bit ECDSA private key. For example, you could use a SHA-256 hash of a 160-bit seed as your private key with no loss of security. You can even go down to 128-bits with no significant loss of security.

• I don't understand why the two cases are different. In each case the search space is of size 2^160, isn't it? In your recommended algorithm the brute-force attacker has to know to perform an extra SHA256 on each trial, but if this is to provide more than security by obscurity, we must assume she does know that. What am I missing? Aug 30 '14 at 15:00
• Are ecdsa keys containing lots of zeros vulnerable to some attack more efficient than brute force? Aug 30 '14 at 15:01
• @NateEldredge You're missing that the attack would be deriving the private key from the combination of the public key and many bits of the private key. To provide comparable security to a 160-bit hash, an ECDSA private key must have about 256 unknown bits. Aug 30 '14 at 23:14
• If I understand all this correctly then the data input, on which a 256 has is to be performed CAN be only 128-160 bits, but if I make a 64 character hexadecimal private key then I need all the 64 characters to be determined randomly. Sep 1 '14 at 9:52
• @Peter Correct. You don't want to have any pattern to the data that might make it easier to brute force the private key from the public key. Patterns hidden behind cryptographically-secure hash functions can't be exploited, at least so far as we know. Sep 1 '14 at 19:41