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

 I am completely niave to this science of randomness but my college =
lecturer
designed a program to generate true random numbers i am not aware of the =
ins
& outs of how its done basically something to do with atmospheric noise
everything is explained on his website
www.random.org
just thought i would mentions this seeing as you are getting into a =
pretty
heated debate :)
& as always have fun!
rob
----- Original Message -----
From: "Per Westermark" <pw...@ia...>
To: "Aitor Moreno" <ait...@gm...>
Cc: <dev...@li...>
Sent: Tuesday, November 09, 2004 8:09 PM
Subject: 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=3Dproject
> 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.
>
>
>
> -------------------------------------------------------
> 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=3D5588&alloc_id=3D12065&op=3Dclick
> _______________________________________________
> 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
>