New Random Number Generator for encryption
in [Cryptography]
|
Prev: Scalable Key Cryptography - The Universal Model.
Next: New Generation Lossless Data Representations
From: orz on 12 Aug 2010 23:12 Clearly I should use more carriage returns / line feeds.
From: orz on 13 Aug 2010 04:27 on topic again: Is there any reason to have walls in the system instead of wrap around coordinates? If the size is set fairly high then some screwy stuff starts happening in its performance on statistical tests. In some cases with very large sizes it will fails some tests very quickly, gradually get worse on those tests, then gradually get better on them until it starts passing them. ie the particle system is changing states in some strange ways over time, and some of those states produce highly biased output.
From: Cristiano on 12 Aug 2010 09:31 orz wrote: > RaBiGeTe is still in development? I saw no updates since 2005 and > assumed it had frozen. Multi-threading RNG testing sounds like a > really good idea for this day and age. I vastly improved RaBiGeTe (multi-threading, GUI, new tests, new tabular and graphical reports), but I haven't published the updates because of the little feedback I got: little feedback, little interest. :-) > I'm working on a vaguely > similar package (though probably closer to TestU01, as it includes > RNGs and is intended to have the RNG output passed directly to the > tests without being written to disk first). That is the way RaBiGeTe works when the user is a programmer; when I test RNGs, I don't write anything on disk. Cristiano
From: Lev Dymchenko on 13 Aug 2010 06:42 On Aug 13, 12:27 pm, orz <cdh...(a)gmail.com> wrote: > on topic again: > > Is there any reason to have walls in the system instead of wrap around > coordinates? > > If the size is set fairly high then some screwy stuff starts happening > in its performance on statistical tests. In some cases with very > large sizes it will fails some tests very quickly, gradually get worse > on those tests, then gradually get better on them until it starts > passing them. ie the particle system is changing states in some > strange ways over time, and some of those states produce highly biased > output. Maybe initial-non random state affects that it fails some tests quickly than become more better. In new version I shuffle initial state by running function with out generation of bits. In that version initial state may affect huge sizes as particles are ordered. Also with huge sizes particles tends to be isolated. With out wrapping coordinates I believe particles will gather in corners, it may add something. I now research that attack, need dimension from 6 and dimension should be even. That way trajectories of particles itself looks random. That way I changed default parameters of rng from dim 5 to 6.
From: jbriggs444 on 13 Aug 2010 08:29
On Aug 13, 4:27 am, orz <cdh...(a)gmail.com> wrote: > on topic again: > > Is there any reason to have walls in the system instead of wrap around > coordinates? If you have walls and corners, does that bias your results? Let's see... We are looking for 4-tuples with each element selected from the set {-1, 0, 1} subject to the constraints that: 1. Not all elements can be zero 2. The x element cannot be -1. There should be ( 81 - 27 ) / 2 such elements. We want to ensure that the parity of these elements is evenly split between even and odd. Ahah! An easy argument follows. We already know that the three dimensional (3x3x3) hyper-plane right at the wall is not evenly split with respect to parity. And we already know that the full four dimensional (3x3x3x3) hyper-cube is evenly split. And we can easily see that the two four-dimensional half-cubes with the center plane excluded are mirror images of one another and must neccessarily have an identical parity excess. It follows that eliminating one four-dimensional half-cube at the walls will have the effect of inducing a parity bias there. So yes, non-toroidal walls are a problem. |