Merge bitcoin-core/secp256k1#1064: Modulo-reduce msg32 inside RFC6979…

… nonce fn to match spec. Fixes #1063

45f37b6 Modulo-reduce msg32 inside RFC6979 nonce fn to match spec. Fixes #1063. (Paul Miller)

Pull request description:

ACKs for top commit:
  siv2r:
    ACK 45f37b6. The diff looks good. It reduces `msg32` to modulo curve order for rfc6979 nonce generation. All tests passed on my machine with `make check`.
  sipa:
    utACK 45f37b6
  real-or-random:
    ACK 45f37b6

Tree-SHA512: 4c36784b2d6f2983bc0c3f380ff59cd9f2bd1822b98116d70964cd15183742fcc1f2ccde225a76dd30d946b3678b2cf29caff018efc07f40a200ee85843b39dd

src/secp256k1.c

@@ -423,16 +423,20 @@ static int nonce_function_rfc6979(unsigned char *nonce32, const unsigned char *m
    unsigned int offset = 0;
    secp256k1_rfc6979_hmac_sha256 rng;
    unsigned int i;
+   secp256k1_scalar msg;
+   unsigned char msgmod32[32];
+   secp256k1_scalar_set_b32(&msg, msg32, NULL);
+   secp256k1_scalar_get_b32(msgmod32, &msg);
    /* We feed a byte array to the PRNG as input, consisting of:
-    * - the private key (32 bytes) and message (32 bytes), see RFC 6979 3.2d.
+    * - the private key (32 bytes) and reduced message (32 bytes), see RFC 6979 3.2d.
     * - optionally 32 extra bytes of data, see RFC 6979 3.6 Additional Data.
     * - optionally 16 extra bytes with the algorithm name.
     * Because the arguments have distinct fixed lengths it is not possible for
     *  different argument mixtures to emulate each other and result in the same
     *  nonces.
     */
    buffer_append(keydata, &offset, key32, 32);
-   buffer_append(keydata, &offset, msg32, 32);
+   buffer_append(keydata, &offset, msgmod32, 32);
    if (data != NULL) {
        buffer_append(keydata, &offset, data, 32);
    }