Criticism of a proposed floating point (cs)prng requested.
in [Cryptography]
|
Prev: Criticism of a proposed stream cipher requested.
Next: Question about pass phrase cracking through brute force
From: Tom St Denis on 4 Jun 2010 19:21 On Jun 3, 2:24 pm, Phoenix <ribeiroa...(a)gmail.com> wrote: > The algorithm is: > > x_n+1 = FRAC( x_n ( x_n + b_n ) +c ) > > b=1,2,3 2048 > c=(0;1) > > I ask criticism on the safety, randomness quality, speed performance, > non linearity, crypto > analisys, Discrete Logarithm Problem (DLP), etc. > I have no idea what the DLP has to do with your scheme, and for fear of sounding like I'm an advocate, why don't you just write your algorithm to use fixed-point arithmetic and do away with any portability issues? Tom
From: Phoenix on 4 Jun 2010 19:45 On 4 Jun, 23:21, Tom St Denis <t...(a)iahu.ca> wrote: > On Jun 3, 2:24 pm, Phoenix <ribeiroa...(a)gmail.com> wrote: > > > The algorithm is: > > > x_n+1 = FRAC( x_n ( x_n + b_n ) +c ) > > > b=1,2,3 2048 > > c=(0;1) > > > I ask criticism on the safety, randomness quality, speed performance, > > non linearity, crypto > > analisys, Discrete Logarithm Problem (DLP), etc. > > I have no idea what the DLP has to do with your scheme, and for fear > of sounding like I'm an advocate, why don't you just write your > algorithm to use fixed-point arithmetic and do away with any > portability issues? > > Tom If we use fixed-point arithmetic, we have nothing. Believe, I already try and test it.
From: unruh on 4 Jun 2010 20:31 On 2010-06-04, Mok-Kong Shen <mok-kong.shen(a)t-online.de> wrote: > Maaartin wrote: >> Mok-Kong Shen wrote: >>> Note the word "many" that I wrote. Consider e.g. the case where >>> different branch officies of a firm are to confidentially communicate >>> with one another. If that involves a PRNG that is based on computations >>> in R, then almost surely the firm could afford to purchase compatible >>> hardware, if not exactly identical hardware, for that purpose. In >>> more general situations, Intel-compatible PCs are sufficiently >>> "ubiquitous" and cheap, so that the problem in question could be >>> considered to be practically solved, I would say. >> >> Probably yes. But one day Microsoft decides to set default rounding >> mode differently and nothing more works - unless the programmer took >> care of it while implementing the PRNG, but maybe he did not, and one >> half of the can't communicate with the other. Would you take the >> chance? >> >> What if the company fuses with another one using the same PRNG on >> incompatible HW. Is it worth the hassle. > > Are you aware that incompatibility is ubiquitous in CS? Files of > Microsoft and of Apple are in different formats, if I don't err. > I can't read PS-documents, because I have Adobe Reader on my PC. > Currently I have the 64 bit version of Windows 7 and can no longer > run the exe-files I previously got using Windows XP on a 32 bit PC. > My point was that, 'if' the algorithm turns out to be 'sufficiently' > superior, 'then' it could well find application areas that it > deserves. One should not "always" demand standards that apply in > all cases, remembering that even the metric system is not yet employed > everywhere. To my knowledge, even different versions of certain ISO > Standards may also not be (entirely) upwards compatible. In real > life, one has often to accept compromises, right? > Since floating point values are represented on the system as integers (ie a finite number of bits) and since the representation can vary, why in the world would anyone design a floating point crypto with all its problems rather than the equivalent integer system. Ie, anything a floating point algorithm can do, an integer one can as well-- maybe with a bit more programming. > M. K. Shen
From: unruh on 4 Jun 2010 20:34 On 2010-06-04, Phoenix <ribeiroalvo(a)gmail.com> wrote: > On 4 Jun, 23:21, Tom St Denis <t...(a)iahu.ca> wrote: >> On Jun 3, 2:24?pm, Phoenix <ribeiroa...(a)gmail.com> wrote: >> >> > The algorithm is: >> >> > x_n+1 = FRAC( x_n ( x_n + b_n ) +c ) >> >> > b=1,2,3?2048 >> > c=(0;1) >> >> > I ask criticism on the safety, randomness quality, speed performance, >> > non linearity, crypto >> > analisys, Discrete Logarithm Problem (DLP), etc. >> >> I have no idea what the DLP has to do with your scheme, and for fear >> of sounding like I'm an advocate, why don't you just write your >> algorithm to use fixed-point arithmetic and do away with any >> portability issues? >> >> Tom > > If we use fixed-point arithmetic, we have nothing. > Believe, I already try and test it. Then you have nothing since all floating point values are represented by fixed point arithmetic on any computer I know of.
From: Phoenix on 4 Jun 2010 20:54
On 5 Jun, 00:34, unruh <un...(a)wormhole.physics.ubc.ca> wrote: > On 2010-06-04, Phoenix <ribeiroa...(a)gmail.com> wrote: > > > > > > > On 4 Jun, 23:21, Tom St Denis <t...(a)iahu.ca> wrote: > >> On Jun 3, 2:24?pm, Phoenix <ribeiroa...(a)gmail.com> wrote: > > >> > The algorithm is: > > >> > x_n+1 = FRAC( x_n ( x_n + b_n ) +c ) > > >> > b=1,2,3?2048 > >> > c=(0;1) > > >> > I ask criticism on the safety, randomness quality, speed performance, > >> > non linearity, crypto > >> > analisys, Discrete Logarithm Problem (DLP), etc. > > >> I have no idea what the DLP has to do with your scheme, and for fear > >> of sounding like I'm an advocate, why don't you just write your > >> algorithm to use fixed-point arithmetic and do away with any > >> portability issues? > > >> Tom > > > If we use fixed-point arithmetic, we have nothing. > > Believe, I already try and test it. > > Then you have nothing since all floating point values are represented by > fixed point arithmetic on any computer I know of. Read this: http://en.wikipedia.org/wiki/Fixed-point_arithmetic and http://en.wikipedia.org/wiki/Floating_point |