How do I generate a challenge for elliptic curve signing using NIST standards? 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...)
I believe you're misunderstanding how ECDSA works.

When you sign a message with RSA, you pad out the message somehow; some padding methods are determanistic, and some are randomized.  However, once you get this padded message, you present it to the underlying RSA private operation, which is entirely determanistic.

However, ECDSA isn't like that.  Instead, the ECDSA private operation selects a value k; this value k is not the message being signed, instead it's a random value (and there are known attacks that can occur if it's biased; that's why FIPS 186 goes into such detail about exactly how you do it - if you ignore their advice without knowing what you're doing, well, there be dragons here).

Now, once you have the value k, you can take the message (actually, the hash of the message), and then present that to the ECDSA signature operation to generate the signature.

So, with ECDSA, there is a hash involved; however it's the message that is hashed, not k.