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

There are already good random number generators with immensely much better
randomnes and immensely much longer sequences making them evilishly hard
to follow.

With a good entrophy to seed them - some of which I discussed in my
previous mail - even a quite simle application can use good cryptographic
strength random numbers.

Why invent an octagonal wheel when there are already true round wheels
available out there on the net?

Let's play a bit with the time() function - even if repeated a large
number of times - doesn't create hardly any entrophy. Let's say you get 10
bits of entrophy for the first call (i.e. a random time within a start
window of 15 minutes). Each following call add an entrophy close to zero.
Let's say that you call time() on average every 60 seconds (2^6
alternatives), which might give you 6 bits of entrophy. To get 256 bits of
entrophy (a very lousy entrophy for encryption seed), you then need 40
calls within a 40 minute interval... For real entrophy, you should
probably have at least 1024 or 2048 bits, which in this case translates to
a smapling interval of 150 to 300 minutes.

Let's then look a bit closer at the above alternative. You have still not
specified how you should manage to make the individual "random" delays
between each time() sample. If this isn't true random (which it can't be
since you haven't even managed to get a real seed yet) and instead
generated by calls to rand() (which is using a known algorithm and have a
very short sequence) then your 6 bits of entrophy for each 60 second
window actually gets multiplied by 0, i.e. you are still at your initial
10 bits of entrophy from the 15-minute uncertainty of when the first call
was made.

A large number of people have tried your approach in a number of variants.
Every one of them who have had their results stressed have fallen through,
i.e. the "randomnes" has been quickly shot to pieces.

We are not talking about world-class cryptographic analysis to pick the
above methods to pieces. More like a suitable programming exercise for
project Euler:
  http://www.mathschallenge.net/index.php?section=project
or maybe a home exercise for some courses at the university.

- There are no ways to just algorithmically create randomnes.
- There are good random number generators available freely.
- For most environments, entrophy can be picked up from the system.

Why then bother to try and do something that can't be done? Instead fix
good random generator from the net. Fix reasonably good entrophy from the
system. Mix together and use. Takes less time than even thinking about
inventing some smart methods for "garbling" the rand() sequence.

time(), srand(), rand() etc are _only_ for selecting which attack a moster
should use, what color a screen saver should display etc. They can not be
used for anything where random quality or preditability (or actually lack
of) is important.

With time() you get a few bits, but you have to look somewhere else to
collect the rest of the bits to use. In an interactive environment, the
user is a great source of entrophy. Else, you really have to dig in and
look under every stone there is. Only remember that repeating the same
operation twice doesn't double the entrophy. Most of the time it doesn't
give a single bit extra...

I don't write this to be difficult. It's just that there must be
absolutely no misconception that rand() and time() may be used for
cryptography or other fields where good random numbers and entrophy
are needed.

Note: more comments inlined below.

/Per W

On Tue, 9 Nov 2004, Aitor Moreno wrote:

> Yes.. I agree with you. Since time() doesn't generate true random
> numbers, with this EASY approach, better results are achieved... do
> you agree with me?

See comments above - no extra entrophy added.

> >
> Yes, of course this can happen.... but this introduces a noise in the
> resulting sequence.

Not noise - as in randomnes. It only adds predictability, i.e. "hooks"
that may be used to figure out what extra code you are using to garble the
rand() function.

> >
> Obviously... it is like trying to encrypt a java applet.... it is
> impossible, but with all the known techniques, you can make the attack
> more difficult, only for those attacks that know how to do it....
>
> With this easy approach, you can add a real noise to the resulting
> sequence that makes the analysis more difficult... or isn't it??

As I mentioned above: A lot of people have tried obfuscation. I don't know
about anyone who have managed to survive a real hack attempt.

> >
> And if it is small set of random numbers, with the proposed function,
> reseeding the sequence, and the interval between successive numbers is
> not trivial....
> do you think that is harder or easier to perform the analysis?

You need a random generator to make this strategy work. Then, you still
receive entrophy in a real slow way. And in the end, rand() in itself is
too bad to be helped by good entrophy

> >
> and if it is used only for choose a random color for my background ?
>
> I know what you are comment... and all it is true... the true random
> numbers are difficult to obtain...  And, like the topic was "true
> random numbers", I have to agree with that, because I think in the
> same way .
>
> But, a good approach for easy applications can be the proposed one in
> the first post or in the second one....
>
> In all cryptographic books it is used to appear a chapter about this ...

A good approach for easy applications that are not limited to selecting
the background color of a window is to pick the code available in these
chapters of the cryptographic books, or to just google for a download
site. Any other design decision either fails or requires extensive
statistics and cryptographics knowledge and may still backfire.