# RFC 6979 - Why not simply hash the message & the private key for deterministic ECDSA?

Why go through the trouble of using the HMAC_DRBG process, instead of simply hashing [message | private key] to calculate $k$ for deterministic ECDSA?

If the resulting $k$ or the signature is invalid, then a known byte value can be appended to the input, and re-hashed, until an acceptable result is achieved: k=h([message|privateKey|0x00 … 0x00])

As many 0x00 bytes as the number of iterations it takes.

Am I missing an inherent weakness here?

Edit: If the hash function output length is smaller than the curve order, multiple hash outputs (produced by appending a known byte, similar to what was described above) can be concatenated as necessary: k=[ h([message|privateKey]) | h([message|privateKey|0x00]) ... ] Once you have enough output, you can then truncate it to match the curve order bit length.

And if the resulting $k$ or the signature is no good, then restart with the known byte appended: k=[ h([message|privateKey|0x00]) | h([message|privateKey|0x00 0x00]) ... ]

And so on, until an acceptable $k$ is produced.

• It decouples the output length of the hash function from the required length of k. I would have said it was to provide security even in the presence of a collision in the hash function, but I don't think it does. – Michael Nov 30 '14 at 9:54
• Thanks Michael. I added the necessary info to the question. As for the collisions, I don't see them being an issue. – thera Nov 30 '14 at 12:30
• How would you handle the case when the order of generator is of larger bit size than your hash function digest (e.g. SHA-256 and P-521) ? – Ruggero Nov 30 '14 at 19:23
• That was Michael's point as well I believe. I initially had thought you would just restrict the usage to curves smaller than the hash size, but it would also be feasible to just do the iteration I described and keep appending until enough output is available to match the curve order bit length. – thera Nov 30 '14 at 21:06
• Or you could use a sponge based hash like SHA3 that can have an arbitrary output length. – John Meacham Nov 30 '14 at 22:02