Re: Good random number source in oracle

Apologies for the multipost, Outlook is a bit enthusiastic, time to change newsreader

"Ian Ledzion" <ian.ledzion_at_lgxbow.com> wrote in message news:9c6089$60n$1_at_rex.ip-plus.net...
> 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.
>
> However, let's look at what happens if you take the part of sysdate after
> the
> decimal:
>
> 1) Assume you are taking SYSDATE to the millisecond, and are testing 100
> possibilities / second.
>
> 2) It would it would take you 10 days to check all the available
> possibilities. If start with the most likely times to change your
 password,
> you can get a match faster.
>
> 3) Because you are testing a linear set of values, you can break the work
> down over several machines, each investigating a subset of possibilities.
> 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.
>
> Of course this assumes that someone really wants to get into your system
 and
> is willing to commit the resources to crack your passwords in the first
> place.
>
> PS Check out www.random.org for a discussion on random number generators.
>
> "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 - 03:40:45 CDT