Re: random data
From: Bryan Olson (fakeaddress_at_nowhere.org)
Date: 07/31/03
- Next message: Mark Wooding: "Re: Into the Fire"
- Previous message: Simon Johnson: "Re: Is RC4 a good choice?"
- In reply to: Phillip Hauser: "Re: random data"
- Next in thread: Arthur J. O'Dwyer: "Re: random data"
- Reply: Arthur J. O'Dwyer: "Re: random data"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 31 Jul 2003 12:41:00 GMT
Phillip Hauser wrote:
>> > If I change the following line so that RANDOM_POOL_SIZE is divided
>> > by sizeof(LARGE_INTEGER) and filled up with all 8 bytes of tsc instead
>> > of only the least significant byte, my diehard test performance gets
>> > worse, and I don't really understand why...
>> >
>> > random_pool[c] = (char)tsc;
>>
>>I don't see what change to that line you mean.
>
> *(int *)&random_pool[c] = (int)tsc;
> That is, take the lower 4 Bytes of the TSC instead of only the lowest
> one. Or take the complete 8 Bytes of tsc:
> *(__int64 *)&random_pool[c] = tsc;
That only does part of what you said.
>>More importantly, I doubt you collect nearly as much entropy as
>>you might think. The calls to QueryPerformanceCounter are in a
>>quick loop, and there's nothing in the loop that's likely to
>>take varying time. Note that passing statistical tests does not
>>imply you collected significant entropy.
>
>
> I thought QueryPerformanceCounter uses the instruction RDTSC to
> read the processors' TSC. But then somebody wrote it uses the High
> Performance Timer which doesn't change that much per second. So
> I changed the QueryPerformanceCounter call into a RDTSC in assembly
> language. There should be a lot more entropy in that...
Not much, no. That's the same clock that drives execution of
the instructions. You want randomly varying differences, not
just larger ones. The first call might have a few bytes of
entropy; the second may have a little do to cache misses;
subsequent iterations are likely to take a fixed number of clock
cycles.
>>I'm also suspicious of the pointer casts -- why are &tsc and
>>random_pool not already the type to which they are cast?
>
>
> char random_pool[RANDOM_POOL_SIZE];
> __int64 tsc;
So why cast something to the type it already is?
-- --Bryan
- Next message: Mark Wooding: "Re: Into the Fire"
- Previous message: Simon Johnson: "Re: Is RC4 a good choice?"
- In reply to: Phillip Hauser: "Re: random data"
- Next in thread: Arthur J. O'Dwyer: "Re: random data"
- Reply: Arthur J. O'Dwyer: "Re: random data"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]