Basically, NIST FIPS 186-4 describes a standard for generating some message that will be signed by an elliptic curve private key. However, I'm having difficulty interpreting how this message should look.
To give more context, with RSA, I've been attempting to follow PKCS #1 v1.5, so I'm basically doing
pad(sha1(crypto.randomBytes(256)), which I believe creates a sufficiently random challenge of appropriate length in the case of RSA. (If I'm wrong here, please let me know that as well).
What are the discrete steps in the case of ECC? (I'm trying to follow B.5.1 Per-Message Secret Number Generation Using Extra Random Bits and B.5.2 Per-Message Secret Number Generation by Testing Candidates of the publication above).
In this method, a random number is obtained and tested to determine that it will produce a value of k in the correct range. If k is out-of-range, another random number is obtained (i.e., the process is iterated until an acceptable value of k is obtained.
So in plain English looking at the publication, it appears I do the following to create a challenge, k:
- Find the bit length N of the public key
- Generate a string of N random bits
- Convert the string of random bits to a non-negative integer c (using the method for bit-to-string conversion in the same publication)
- If c is greater than n-2, start over...
- k = c + 1
Make sure k and the inverse of k are within the limits [1, n–1].
However, there doesn't seem to be any hashing going on. In the context of RSA, I've been reading you should always hash this random bit string before signing it (and of course, we must pad it appropriately so the message is the correct size). Am I missing something in the case of ECC? (Of course, I could theoretically just send any random message to be signed, but I want to follow some standard for the challenge, and it looks like NIST is the way to go...)