Re: Good random number source in oracle

I quote "you can use the low end of the systdate squared and then modified further". By low end I assumed that you mean taking the last set of digits.

Let's look at what happens if you take the part of sysdate after the decimal:
1) Assuming you are testing 100 possibilities / second, to check all the available possibilities would take you 10 days. If start with the most likely times to change your password, you can get a match faster.

2) Because of the way the randomiser is seeded, you can break the work down over several machines, each investigating a set of times. And because you are testing a fixed algorithm, you can store the possible results in a table, and have them available for analysis later. At 1000 possiblities per second the total is 86.4M lines in the table, which is easily within the Oracle range.

"Steve Long" <steven.long_at_erols.com> wrote in message news:9c4fo5$8s7$1_at_bob.news.rcn.net...
> why are you assuming truncation? try reading the post in its entirety and
> without reading into it.
>
> "Ian Ledzion" <ian.ledzion_at_lgxbow.com> wrote in message
> news:9c3ppp$fp5$1_at_rex.ip-plus.net...
> > Using milliseconds would mean that a cracker just has to run through
 1000
> > possible permutations. Squaring the number would still mean 1000
> > permutations. In my view true randomness cannot exist withing a
 computer
 as
> > the systems are rule-based.
> >
> > A thought: try downloading files from SETI_at_home and sequences out of
 that,
> > as cosmic background noise *is* random, unless you've had the misfortune
 to
> > land on an ETI signal...
> >
> > "Steve Long" <steven.long_at_erols.com> wrote in message
> > news:9c1pv3$2au$1_at_bob.news.rcn.net...
> > > if you are using sysdate, recall that sysdate gets down to
> > > milliseconds...what is the likelyhood that anyone would know the
 precise
> > > value of time wrt milliseconds when the function actually received a
 value
> > > from the system clock? you can use the low end of the systdate
 squared
 and
> > > then modified further...etc etc
> > >
> > > "Peter J. Holzer" <hjp_at_enkur.wsr.ac.at> wrote in message
> > > news:slrn9e8iid.g2j.hjp_at_enkur.wsr.ac.at...
> > > > I have a stored procedure which generates random passwords.
 Currently
> > > > dbms_random.initialize is called with a value computed from sysdate.
> > > > Of course this isn't very random, so if somebody knows the algorithm
 and
> > > > the (approximate) time when a password was created, he can easily
> > > > compute the password. So I am looking for values which can be used
 as
> > > > "real" random number sources, I.e. values which change often and
 cannot
> > > > be guessed with sufficient accuracy from the outside. Things like
 number
> > > > of sessions, bytes read or written since last startup, etc.
> > > >
> > > > Any suggestions? (Apart from using dbms_pipe to call a script which
> > > > reads /dev/random - I am aware of that possibility).
> > > >
> > > > Also I am interested in the internal workings of the dbms_random
 package
> > > > (what kind of RNG it uses, etc.) Any pointers would be appreciated.
> > > >
> > > > hp
> > > >
> > > > --
> > > > _ | Peter J. Holzer | It's nice to fix problems by
 accident.
> > > > |_|_) | Sysadmin WSR / LUGA | -- Theo de Raadt
> > > > | | | hjp_at_wsr.ac.at | <deraadt_at_CVS.OPENBSD.ORG>
> > > > __/ | http://www.hjp.at/ | on bugtraq 2001-03-19
> > >
> > >
> >
> >
>
>
Received on Wed Apr 25 2001 - 02:44:56 CDT