I have strong doubt on this claim.
It claims that NIST member feed UNIX time of certain points in 1997-1998 to srand() and draw 20 bytes for n times, then use the last 20 bytes for the SEEDS.
Why NIST staff in 1999 used default rand() implementation of libc(or languages which rely on libc) at that time? Linear congruential generator was infamous for its poor quality even in 1990s.
NIST published recommended SEED value in 1999, July. Why did they use UNIX time from 1997-1998?
Why the exact date of that UNIX times are so sparse? 1 in 1997 May, 3 in 1997 Auguest, 1 in 1998 April? If they did srand(time(NULL)), it should be more closer.
The number of n'th 20 bytes thrown out is also doesn't make sense. n=139 for P-192, n=7026 for P-224 and so on. Why did they choose this numbers in particular? Why P-192 was odd and 3 digits while rest of 4 were even and 4 digits?
It seems to me, Claude simply hit a jackpot of coincidentally matching 20 bytes.
It claims that NIST member feed UNIX time of certain points in 1997-1998 to srand() and draw 20 bytes for n times, then use the last 20 bytes for the SEEDS.
Why NIST staff in 1999 used default rand() implementation of libc(or languages which rely on libc) at that time? Linear congruential generator was infamous for its poor quality even in 1990s.
NIST published recommended SEED value in 1999, July. Why did they use UNIX time from 1997-1998?
Why the exact date of that UNIX times are so sparse? 1 in 1997 May, 3 in 1997 Auguest, 1 in 1998 April? If they did srand(time(NULL)), it should be more closer.
The number of n'th 20 bytes thrown out is also doesn't make sense. n=139 for P-192, n=7026 for P-224 and so on. Why did they choose this numbers in particular? Why P-192 was odd and 3 digits while rest of 4 were even and 4 digits?
It seems to me, Claude simply hit a jackpot of coincidentally matching 20 bytes.