Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:15:21
Bill Frantz (frantz@netcom.com)
Thu, 8 Oct 1998 23:21:02 -0800
At 3:16 PM -0800 10/8/98, Anonymous wrote:
>> I ran both the old MD5 plus a longword call count generator and the new one
>> based on Arc5 I posted last week through Maurer's statistical test. I used
>> my Java translation of David Honig's <honig@sprynet.com> implementation of
>> Ueli M Maurer's "Universal Statistical Test for Random Bit Generators".
>> Thanks for posting it David.
>>
>> I ran the tests with continuous seeding turned on and with it turned off.
>> All tests ran for the maximum 66,191,360 samples. Here are the results.
>
>Remember that even a very low-entropy stream will pass most statistical
>randomness tests when run through conditioning routines; paranoia is still
>permissible, y'all. Refer to the earlier RNG threads for more on that.
Maurer claims his test if good for generators with 16 bits or less of
internal state (if I understand correctly the 10% of his paper that I think
I understand). The only thing I think his test can prove about a generator
with 258 bytes of state is that it is bad.
>Those designing applications for a truly surreal threat model might want
>to up the minimum amount of entropy tossed in per go.
I model the 80 bits of entropy buffered as being somewhat equivalent to
exhaustive search on a symmetric cypher with an 80 bit key. If you feel
comfortable with 80 bit keys it should be OK. Larger just makes it take
longer to collect the entropy, and keeps you in the insecure state that
much longer.
>If you're worried about your state being compromised on disk but not about
>delays, set the generator to assume that your state was compromised (i.e.,
>set the initial available entropy to zero).
Absolutely. However, it takes about 20 seconds to seed the generator with
160 bits on an IBM PC. (See the ...security.TimerJitterEntropy.java class
available from <http://www.erights.org>.) The user experience people don't
like the delay.
One compromise that might be viable in some systems would be to initialize
available entropy to 80. You don't start producing output until you have
collected the other 80 bits of entropy, which is a lot safer than zero, but
will only take half the time.
>Are you sure about the use of the raw key schedule over an
>already-initialised Arc4 state? I'd think it might not always give you all
>the avalanche you want.
That's the part I'm least sure of. The key schedule code looks like:
for (int i=0; i<256; i++) {
int j = 0xff & (i
+ myArc4SBox[i]
+ myEntropyBuffer[i%myEntropyBuffer.length]);
// Swap bytes a myArc4SBox [i] and myArc4SBox [j]
}
The code which produces output bytes looks like:
myArc4I = (myArc4I + 1) & 0xff;
myArc4J = (myArc4J + myArc4SBox[myArc4I]) & 0xff;
// Swap bytes a myArc4SBox [myArc4I] and myArc4SBox [myArc4J]
outputByte = myArc4SBox[ (myArc4I+myArc4J) & 0xff ];
Arc4 in its normal output mode has a swap operation where one element is
sequentially stepped through the S box and the other is chosen based on the
contents of a location in the S box. This seems close enough to the key
schedule to make it seem safe to rerun the key schedule over an already
initialized state. But I have no proof.
-------------------------------------------------------------------------
Bill Frantz | If hate must be my prison | Periwinkle -- Consulting
(408)356-8506 | lock, then love must be | 16345 Englewood Ave.
frantz@netcom.com | the key. - Phil Ochs | Los Gatos, CA 95032, USA
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:15:21