Unfortunately, this solution isn't statistically viable:
Multiplying with a constant will limit the range of possible result; for example using 91234567890 or 99234567890 means you will always get a "pseudo-random" number divisible by 10 (or seen in a diffrent way, that ends with 0). In other words, the resulting "pseudo-random" number will always be a multiple of the prime factors of the constant.

A way around this would be to multiply 2 pseudo-random numbers together. This would already be better although I beleive that would also be statistically biased:
Half natural numbers are odd, half are even.
When multiplicating, the only way to obtain an odd number is to multiply two odd numbers.
So, the odds of obtaining an odd number when multipling two random numbers (each with 50% chance of returning an odd number) would yeild only a 25% chance, while it should be 50%...

This might not mean much at first look, but it can be crucial when carefully observed: just take a look at TCP ISN (Initial Sequence Number) prediction for example:
Good point but it's also worth noting that rand and srand are both inherently *unsafe* for generating random numbers for things such as crypto keys ie. anything that you don't want someone to be able to guess. These two functions both use a very predictable method of picking a seed to generate the random number. It is better to generate random numbers using a large number of different variables that make the end result hard to guess. For example you could write a function to generate random numbers based on lots of different values that change frequently and unpredictably such as: current pid * number of currently open files * bytes memory free * thread group id ....