Re: [Dev-C++] true random numbers.

Except that it doesn't add any randomnes since time() returns a very well
known value all the calls, and you are using a random number generator
with a well known sequence.

Don't forget that it is very easy to check 2^32 seed values to find a
suitable start seed. By knowing within a reasonable time span when the
random numbers are generated, few random steps need to be tested with few
stepped times to continue to follow this "random" chain.

By constantly reseed the rand() function, you may also create local
sequence loops, where the current time() call will result in a seed value
already used before.

In short, the concept doesn't hold under cryptographic analysis.

This is a reason why for example Intel has added random number generation
to some of their chipsets, and why most operating systems are using their
internal state changes to fill large buffers with entropy data.

You might look into information such as:
- number of tcp packets sent on primary network interface
- the product of all PID of all currently running tasks
- number of available bytes on the user disk partition
- number of microseconds needed for a user to enter a password
- contents of an area of the graphics memory
- ...

and then combine all this information into the seed entrophy of a high-end
random generator - definitely not the one available in the standard RTL.

And unless you are really, really, _really_ sure about the quality of your
entrophy you should be careful about restarting the random generator.

Believe me, the first thing peoples tries when unrolling an encryption is
to check how key generation is affected by current PID or time values. In
your case it is enough to start the application mutliple times from the
same start time to produce identical random sequences. The jitter within
the second will change number of identical random numbers until the system
ticks to the next second. However, this is trivial to catch and compensate
for since it is just a +/- 1 error in the time during transition from one
second to the next.

If you produce huge number of random numbers, the sequence generated with
the same time will be long - easy to catch. If you produce your numbers
within a very long time interval, the time steps will affect more but then
the numbers are so few that is still trivial to follow the sequence.

/Per W

On Tue, 9 Nov 2004, Aitor Moreno wrote:

> > I would assume your first rand() call always produces the same result,
> > i.e. that you seed the random number generator with a constant multiplied
> > with the current time.
>
> Yes, the first rand() always produces the same result... but
> multiplyed by a different value of current time, we can obtain a
> different seed to further random values
>
> Let suppose two different executions E1 and E2:
>
> srand( (unsigned)time( NULL ) *rand()/RAND_MAX );
>
> the first call of rand() is the same in execution 1 and 2. But the
> srand is seeded with different values  N1 and M1. (due to different
> times)
>
> Then we obtain a random number RN1 and RN2 that will be different.
>
> Then we re-seed the sequence again
> srand( (unsigned)time( NULL ) *rand()/RAND_MAX );
> both values in the mulplitication are different so, we are seeding
> again with two different seeds....
>
> And so on... Every time you need a random value.. the sequece is
> re-seeded with current time and the next existing random value..
>
> I think it is a easy way in order to complicate the analysis....
>
>
> > No much differene from the all-time "favorite" of
> > using process PID multiplied with time(). A large number of applications
> > have done this for generating session keys or similar. A short analysis
> > makes this approach obvious and an attacker may then find out a very small
> > range of possible seed values when trying to recreate the random sequence
> > used. Don't forget that most of the programs in the world are built using
> > a small set of runtime libraries. The runtime libraries are created using
> > an even smaller set of standard pseudo-random number generators.
>
> I dont think that this is perfect... but I believe that this can
> minimize the risk, seeing that you only get a single number of a
> sequence (you are reseeding it continously)
>
> > When just generating some semirandomnes for "fun" in an application, this
> > doesn't much matter.
>
> I agree...
>
> > However, as soon as the random sequences are used for
> > some soft of security, the seed becomes very important, and it might also
> > be an idea to think about the sequence, since max 2^32 sequences may be
> > created, which is very easily scanned.
> >
>
> Of course.... the pseudo random algorithms are becoming a proper
> science.... in fact, a way for atack secure systems like RSA is with
> atacks to the builtin pseudo ramdom algorithms... so you can reduce
> dramatically the range of possible keys.. for example.
>
> Bye!
>
> --
> Aitor Moreno
>    ait...@gm...
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>