The integer p specifying the finite field F_p can be found here:

https://en.bitcoin.it/wiki/Secp256k1

which is really just copied from section 2.7.1 "Recommended Parameters secp256k1" on page 15 of this document:

http://www.secg.org/collateral/sec2_final.pdf

I will verify this and then fix the wiki if I am correct.

- snip -
Also, SHA256 can create a value invalid as an ECDSA private key, "Specifically, any 256-bit number between 0x1 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is a valid private key."

- snip -

I think there is a range. I found it on the wiki: Specifically, any 256-bit number between 0x1 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is a valid private key.
- snip -

I assume you mean private keys (not private addresses, there is no such thing).  In that case:

https://en.bitcoin.it/wiki/Private_key

- snip -
Nearly every 256-bit number is a valid private key. Specifically, any 256-bit number between 0x1 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is a valid private key.
- snip -

- snip -
its because the prime number chosen for secp256k1 is just a little less then 2^256

0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is that prime number in hexadecimal.

- snip -
If you do it this way, the max address you can use is FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141

If you generate that way you will end up with keys which are not equiprobable. The difference from uniform is very small, but its a certificational weakness you should avoid.