<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2014-08-30T15:00:17.760Z
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?
Nate Eldredge
CC BY-SA 3.0
2014-08-30T15:01:50.713Z
Are ecdsa keys containing lots of zeros vulnerable to some attack more efficient than brute force?
Nate Eldredge
CC BY-SA 3.0
2014-08-30T23:14:55.017Z
@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.
David Schwartz
CC BY-SA 3.0
2014-09-01T09:52:53.967Z
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.
Peter
CC BY-SA 3.0
2014-09-01T19:41:00.667Z
@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.
David Schwartz
CC BY-SA 3.0
2014-08-29T17:26:02.910Z
2014-08-29T19:35:57.177Z
2014-08-29T19:35:57.177Z
David Schwartz
<p>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.</p>

CC BY-SA 3.0
2014-08-28T16:22:54.050Z
We'd have to know what algorithm you're using to produce the private key.
David Schwartz
CC BY-SA 3.0
2014-08-29T07:36:29.950Z
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.
Peter
CC BY-SA 3.0
2014-08-29T17:24:37.883Z
Oh, you mean actually putting zeroes in the private key?! No, that's completely unsafe.
David Schwartz
<private-key><random>
Is it correct that more than 160 bits of input data for producing a private key are superfluous?
Peter
# Is it correct that more than 160 bits of input data for producing a private key are superfluous?

(Asked by: username_0 on 2014-08-28)

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.

**Tags:** private-key, random

> **Comments:**
> **username_1**: We'd have to know what algorithm you're using to produce the private key.  
> **username_0**: 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.  
> **username_1**: Oh, you mean actually putting zeroes in the private key?! No, that's completely unsafe.  

---

## 1 answers

### Answer by username_1 on 2014-08-29. Score: 4

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.

> **Comments:**
> **username_2**: 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?  
> **username_2**: Are ecdsa keys containing lots of zeros vulnerable to some attack more efficient than brute force?  
> **username_1**: @username_2 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.  
> **username_0**: 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.  
> **username_1**: @username_0 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.  

---

