dev-cpp-users

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

[Rob L. <rob...@nt...>]

 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
>

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

[Roger F. <ra...@ha...>]

Aloha from Honolulu,
   My browser (Mozilla) reports that it can't find that web site.  I 
also tried pasting http// ahead of the www, but got the same 
non-result.  Having followed this debate I'm curious.  I hope you can 
post a better URL.
Mahalo (Thank You),
Roger Furer

Rob Lawless wrote:

>  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 <http://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... 
> <mailto:pw...@ia...>>
> To: "Aitor Moreno" <ait...@gm... <mailto:ait...@gm...>>
> Cc: <dev...@li... 
> <mailto: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=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.
> >
> >
> >
> > -------------------------------------------------------
> > 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 
> <http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click>
> > _______________________________________________
> > Dev-cpp-users mailing list
> > Dev...@li... 
> <mailto:Dev...@li...>
> > TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> >

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

[Per W. <pw...@ia...>]

Try again. www.random.org is working!

/Per W

On Tue, 9 Nov 2004, Roger Furer wrote:

> Aloha from Honolulu,
>    My browser (Mozilla) reports that it can't find that web site.  I
> also tried pasting http// ahead of the www, but got the same
> non-result.  Having followed this debate I'm curious.  I hope you can
> post a better URL.
> Mahalo (Thank You),
> Roger Furer
>
> Rob Lawless wrote:
>
> >  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 <http://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...
> > <mailto:pw...@ia...>>
> > To: "Aitor Moreno" <ait...@gm... <mailto:ait...@gm...>>
> > Cc: <dev...@li...
> > <mailto: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=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.
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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
> > <http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click>
> > > _______________________________________________
> > > Dev-cpp-users mailing list
> > > Dev...@li...
> > <mailto:Dev...@li...>
> > > TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> > > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> > >
>
>
>
>
>
> -------------------------------------------------------
> 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
>