From: Tom St Denis on
On Jun 7, 10:25 am, Phoenix <ribeiroa...(a)gmail.com> wrote:
> My previus post, is for the question: portability/non portability on
> fp numbers.
> If all hardwere/software reproduce the same results (if), then we have
> portability and every value is representable exactly
> once.

Well we don't have portability since not all platforms compute the
value with the same internal precision. That aside, that has nothing
to do with proving that you have uniformity since you don't.

Why not lets start at the basics, why are you doing this? What are
you trying to achieve that other designs do not?
From: Phoenix on
On 7 Jun, 15:46, Tom St Denis <t...(a)iahu.ca> wrote:

> Why not lets start at the basics,

The basics are already know.

why are you doing this?

Because I can see some potencial in this. I am sorry for that.

What are you trying to achieve that other designs do not?

Even this have no portability, see: I can hide information on the same
platform (Same hardware/software etc). That is favor point in
security.
Because the algorithm is elegant, easy to undestand with good
satistical qualitys and fast, and because I like to play, learnig,
that kind of stuff.

From: Tom St Denis on
On Jun 7, 11:02 am, Phoenix <ribeiroa...(a)gmail.com> wrote:
> On 7 Jun, 15:46, Tom St Denis <t...(a)iahu.ca> wrote:
>
> > Why not lets start at the basics,
>
> The basics are already know.
>
>  why are you doing this?
>
> Because I can see some potencial in this. I am sorry for that.

Potential value over say AES in CTR mode?

> What are you trying to achieve that other designs do not?
>
> Even this have no portability, see: I can hide information on the same
> platform (Same hardware/software etc). That is favor point in
> security.

Not really. For instance, with known plaintext I can observe
keystream which may help me identifying which type of machine produced
the output. If my friends use PPC and my enemies use x86 ... etc...
It also makes the algorithm entirely impractical since
interoperability is actually a virtue for cryptography, not a fault.

> Because the algorithm is elegant, easy to undestand with good
> satistical qualitys and fast, and because I like to play, learnig,
> that kind of stuff.

I'd say that RC4 and RC5 are much more elegant, RC5 in CTR mode can
produce a key stream easily. Are you planning on actually learning
from analysis or is your goal to change the algorithm subtly so
specific attacks no longer work?

Also if your goal is to learn you should be reading papers on
cryptanalysis. What papers have you read? Can you cite them?

Tom
From: Francois Grieu on
On 07/06/2010 16:25, Phoenix wrote:
> On 7 Jun, 15:15, Tom St Denis <t...(a)iahu.ca> wrote:
>> On Jun 7, 9:41 am, Phoenix <ribeiroa...(a)gmail.com> wrote:
>>
>>> I have this javascipt code that generate 1000 pseudo random numbers
>>> (0;1)
>>
>> And?
>>
>> None of that changes the fact that 2-adic numbers can't represent
>> (0,1) fluidly (to any non-trivial level of precision).
>>
>> It's easier if you used integers to say you're uniform in (0,255) or
>> some other power of 2 because every value is representable exactly
>> once.
>>
>> Tom
>
> My previus post, is for the question: portability/non portability on
> fp numbers.
> If all hardwere/software reproduce the same results (if), then we have
> portability and every value is representable exactly
> once.

The generator described in the original post does produce results that,
after a few iterations, are very dependent on FP hardware and software
details; one justification is that the effect of small errors
skyrockets, because the derivative if the function x*(x+b) is 2*x+b, and
is greater than 1 for all x in the input domain.

Things with a major effect:
- mantissa size and base (the two most common cases are IEEE 754 binary
modes with 23+1 or 52+1 bits, but even under IEEE 754 there are many others)
- rounding: there are 4 IEEE 754 rounding modes, which (in the context
where all real numbers are non-negative) make 3 distinct classes
- subtle details, like the width of the internal multiplier (which may
further affect rounding).

The combinatoric is high; I know no EXACT model of the different FP
hardware around, even limited to x86-related hardware and ignoring the
intricacies of FP divisions. I am not even certain that current Amd and
Intel hardware *always* produce the same result for the same input.

Actually, the generator might have one interest: after enough iterations
it is likely to show differences, if there are any, in the
implementation of multiplication and rounding !


Also: the implementation at
<http://www.number.com.pt/index.html>
includes:
x=FRAC(x*(x+b)+c)
MID$(z$,m%,8)=MKQ$(INT(x*18446559606268814520-9223372036854775808))
where I assume MKQ$ performs some conversion from 64-bit int to eight
8-bit bytes, presumably using a little-endian convention; and x is a
10-byte FP number in this format:
<http://en.wikipedia.org/wiki/Extended_precision>

Things are terribly wrong here: the constants are 0xFFFF583A53B8E4B8 and
0x8000000000000000; thus when the last two bytes on an 8-byte block are
FFh 7Fh, the byte before that is in range [0x00..0x58], or something on
that tune; this alone makes the binary generator derived from the FP
generator trivially distinguishable from random with few megabytes of
output.

If that was fixed so that the output accurately matches the mantissa of
x in fixed precision (which perhaps was the intend), the first byte of
each block would be terribly biased.


Francois Grieu
From: unruh on
On 2010-06-07, Phoenix <ribeiroalvo(a)gmail.com> wrote:
> On 7 Jun, 15:46, Tom St Denis <t...(a)iahu.ca> wrote:
>
>> Why not lets start at the basics,
>
> The basics are already know.

To whom?

>
> why are you doing this?

Precisely the question you are being asked.
>
> Because I can see some potencial in this. I am sorry for that.

What potential? And since you have now seen that there are huge
disadvantages, that potential would seem to have disappeared.

>
> What are you trying to achieve that other designs do not?
>
> Even this have no portability, see: I can hide information on the same
> platform (Same hardware/software etc). That is favor point in
> security.

????

> Because the algorithm is elegant, easy to undestand with good
> satistical qualitys and fast, and because I like to play, learnig,
> that kind of stuff.

Apparently you are extremely resistant to learning however.
All floating point values are represented in the computer by integers--
ie a finite number of bits. Thus anything you can do with floats you can
do with integers. Floats have problems with reproducibilty. Integers do
not. Thus, since floats are already represented by integers, why would
you want to use floats? The only answer is perhaps that many (not all)
computers have hardware to manipulate floats that would be messy to
reimpliment in integers, making implimentation easier. But since that
hardware implimentation is of variable output, that is not an advantage.
>