12

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.

Community
  • 1
thera
  • 346
  • 2
  • 8
  • 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 09: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
  • Definitely. Though that may be bit too limiting – thera Nov 30 '14 at 23:04

1 Answers1

12

Deterministic signatures are safe in the random oracle model. Using HMAC_DRBG allowed me to rely on existing research on the safety of that construction and how close it comes to a "true" random oracle. If I had used any other "handmade" construction, then I would have had to provide extensive analysis on why it is secure. Being naturally lazy, I chose HMAC_DRBG.

Moreover, this use of HMAC_DRBG makes the end result more "convincing" -- and a large part of specifying a cryptographic algorithm as a RFC is to get other people to use it.

(If I had been aware of its existence at that time, I might have considered HKDF instead of HMAC_DRBG, but that does not matter much in practice.)

Community
  • 1
Thomas Pornin
  • 86,974
  • 16
  • 242
  • 314
  • 1
    Is prof Bernstein providing any "extensive analysis" on why it is secure his deterministic nonce derivation in EdDSA ? – Ruggero Mar 11 '15 at 13:50
  • 1
    In their article, the EdDSA authors mostly say that: "Standard PRF hypotheses imply that this pseudorandom session key r is indistinguishable from a truly random string generated independently for each M, so there is no loss of security". This is a bit too terse to be called "extensive analysis" but it makes sense. For more analysis, you may read the Leurent & Nguyen article cited from RFC 6979 (under the reference "LN2009"); that article includes some analysis and pointers. – Thomas Pornin Mar 11 '15 at 14:34