Should the seed of CSPRNG produce the same random number? Assume we are designing a CSPRNG to be used in encryption like that used for ECC-based cryptography.

Is it required that the seed always produces the same random number always? Or should it be  designed to produce different numbers, making it even more secure?
The seed is the source of entropy for any CSPRNG. A CSPRNG is a pseudo random number generator. The "pseudo" part in the name explicitly means that it solely depends on entropy delivered from outside the algorithm using one or more seeds. So a CSPRNG, by definition, cannot be designed to produce "different numbers", as the outcome solely depends on the seeding of the algorithm.

Maybe the term "deterministic random bit generator" or DRBG better catches this meaning - most CSPRNG implementations do also primarily output pseudo-random bits rather than pseudo-random (ranged) numbers.



Now CSPRNG implementations in many runtimes depend on seeding by the operating system. Such seeding may even take place if a user provides a seed themselves. Basically such systems treat the seed as an additional source of entropy, making the next retrieved values depend on both the entropy sources, by mixing them into the state.

Furthermore, CSPRNG algorithms or algorithm implementations may be configured (explicitly or implicitly) to perform re-seeding after a certain amount of bits or calls. In that case the CSPRNG performs a callback to the system that provides the (initial) seed to retrieve additional seeds, which are then mixed into the state. A user may usually also call a method to add seeds or fire a request to re-seeding.

Often CSPRNG's are not explicitly required to return the same random bits if the amount of bits are different between calls. Even if the CSPRNG is in the same state, asking for 8 bits and then 16 bits may result in different values than asking for 16 bits and then 8 bits.

CSPRNG's may also change their implementation slightly, for instance they may generate numbers in a range using several different methods.

All this makes using a CSPRNG of a runtime system very dangerous if you expect to having it generate the same sequence for the same seed, and using a CSPRNG for such purposes it a huge red flag within any design - unless the CSPRNG is explicitly designed for such purpose.



If you do need a predictable stream then you are better off using a KDF (for relatively small output), a XOF such as SHAKE-128 or SHAKE-256 or indeed a stream cipher. Beware though that crypto-systems such as EC may also use the bits in different ways, so if those systems change implementation, you'd still get different results.

Generally, however, a well seeded CSPRNG is all you need to implement a cryptosystem that requires randomness.