Prev: Criticism of a proposed stream cipher requested.
Next: Question about pass phrase cracking through brute force
From: Tom St Denis on 7 Jun 2010 10:46 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 7 Jun 2010 11:02 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 7 Jun 2010 11:29 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 7 Jun 2010 13:11 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 7 Jun 2010 14:40
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. > |