Is RFC 6979 guaranteed to prevent the reuse of nonces for different signed hashes?
$\begingroup$
$\endgroup$
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
9
No, it does not. No stateless procedure that can sign arbitrary messages can do that (that is, a procedure that doesn't record which nonces it has already generated and which does not limit the messages space it can sign to a small number, that is, no larger than the nonce space)
On the other hand, assuming reasonable assumptions on the hash functions it uses, it is no more likely to repeat a nonce than a uniformly distributed random number would.
-
$\begingroup$ What if a block cipher with a width equal to the output size of the hash function was used to encrypt the to-be-sighed hash? $\endgroup$– MelabAug 19 at 21:36
-
1$\begingroup$ @Melab: the hash function would have collisions, hence two different messages (which hash to the same value) would have the same nonce $\endgroup$– ponchoAug 19 at 21:42
-
-
$\begingroup$ How would that impact the nonce-reuse scenario which enables the calculation of the private key? Only one to-be-signed hash $h$, when encrypted with a fixed key, can produce the same value, no? $\endgroup$– MelabAug 19 at 21:54
-
1$\begingroup$ @Melab: that is a good point - using the same nonce on two different messages is not an issue if those two messages hash to the same value (and so, as far as the core ECDSA signing is concerned, they are the same message). It occurs to me that you have to be careful about the encryption mode used; it feels like it would be an exploitable weakness if the attacker could have two different hashes that generate related ciphertexts. Your suggestion of a 'wide block cipher' is good; a FPE mode set to the hash output size (or larger) would be work as well... $\endgroup$– ponchoAug 20 at 21:43