Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Is this a csprng?

1 view
Skip to first unread message

Phoenix

unread,
Nov 20, 2009, 8:39:13 PM11/20/09
to
The algorithm:

x=x(x+b)+c

For more see:

http://www.number.com.pt/index.html

Greg Rose

unread,
Nov 20, 2009, 8:50:58 PM11/20/09
to
In article <df48a599-acf8-4b4c...@c34g2000yqn.googlegroups.com>,
Phoenix <ribei...@gmail.com> wrote:
>The algorithm:
>
>x=x(x+b)+c

If b and c are positive, this just grows without
bound, and finding b and c (and then x) would be
easy. Basically, wait until the second of two
consecutive numbers is nearly the square of the
first.

So I assume you mean "modulo something". If the
modulus is a Blum integer (look it up), I think it
is secure, and it is certainly secure if b == c == 0.

Greg.

--
Greg Rose
232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C

Maaartin

unread,
Nov 20, 2009, 9:42:05 PM11/20/09
to
On Nov 21, 2:50 am, g...@nope.ucsd.edu (Greg Rose) wrote:
> In article <df48a599-acf8-4b4c-9619-af6a8f596...@c34g2000yqn.googlegroups.com>,

>
> Phoenix  <ribeiroa...@gmail.com> wrote:
> >The algorithm:
>
> >x=x(x+b)+c
>
> If b and c are positive, this just grows without
> bound, and finding b and c (and then x) would be
> easy. Basically, wait until the second of two
> consecutive numbers is nearly the square of the
> first.
>
> So I assume you mean "modulo something". If the
> modulus is a Blum integer (look it up), I think it
> is secure, and it is certainly secure if b == c == 0.

According to the link, it works using floating point number modulo 1.
So it's hardly portable and IMHO hard to analyse.

The author states that "Is very portable from platform to platform."
but this is very wrong - for example when using double in C on i86 the
precission may be 80 bits if the values get stored in registers and it
may 64 bits if there get saved to memory. So the result depends on the
compiler, compile flags and also on the usage pattern (when generating
many numbers in row he values stays in registers, when the computation
is interleaved with something else they may be saved to memory).

What's most interesting there is the formula for period length
depending on the current index...

mike3

unread,
Nov 24, 2009, 4:23:35 PM11/24/09
to

What about if one fixes the representation, then? Would that make it
easier to
analyze?

Maaartin

unread,
Nov 26, 2009, 5:00:13 PM11/26/09
to
On Nov 24, 10:23 pm, mike3 <mike4...@yahoo.com> wrote:
> What about if one fixes the representation, then? Would that make it
> easier to analyze?

Maybe I misunderstood your question, but I'd say, without fixing the
representation you have nothing to analyse at all. You need to specify
the exact rounding behavior, etc., otherwise this is no algorithm at
all.

I think the analysis is hard because of the different precission for
different number. Let's say, for an x near 1 you get 23 bits behind
the binary point, for an x near 0.001 you get 10 more. I;d rather do
something else than analysing this.

However, with the algorithm rewritten like follows
x[n+1] = frac((x[n] * (x[n] + B + n) + c))
I suppose, you can easily derive approximate values for x[0], B and c
given x[1], x[2], and x[3], can't you. Unless I oversee something, I
must restate what I said like this: "A good algorithm using floating
point numbers would be hard to analyse.".

0 new messages