Path: cactus.org!milano!cs.utexas.edu!wupost!uunet!mcsun!sun4nl!alchemy! + accucx!nevries From: nevries@accucx.cc.ruu.nl (Nico E de Vries) Newsgroups: sci.crypt Subject: Re: IBM-PC random generator, source included Message-ID: <2804@accucx.cc.ruu.nl> Date: 24 Jun 92 20:53:04 GMT References: <2673@accucx.cc.ruu.nl> <1992Jun23.080147.15804@cactus.org> + <2677@accucx.cc.ruu.nl> <1992Jun23.200511.27492@cactus.org> + <2797@accucx.cc.ruu.nl> <1992Jun24.164407.28468@cl.cam.ac.uk> Organization: Academic Computer Centre Utrecht Lines: 56 In <1992Jun24.164407.28468@cl.cam.ac.uk> rja14@cl.cam.ac.uk (Ross Anderson) writ es: >The current flame war: [Flame detection on] >>> The total state for Nico's scheme seems to be contained in: 1) the >>> refresh counter-timer, 2) the interrupt counter-timer, 3) the >>> software counter lsb, and 4) the period uncertainty when used in a >>> particular program. This will be 4.2 + 12 + 1 + 2(?) = 19.2 bits, >>> and this is not enough to prevent analysis. No flame, assumption which I don't completely understand but which seems very valuable. >>I don't exactly see where your numbers come from but if they are >>correct changing the repeat counter into 24 should make the random >>generator better? No flame either, just question to try to understand previous. >>> increase the state-space by up to 7 bits by using the byte-parity >>> of each sample instead of just using the lsb, but this will not Attempt to improve my algo. >>I don't see the advantage of this. The jitter can only be measured >>when the last bit value changes (the time between two changes is >>undeterministic). Thats why the repeat is there. Reasons why I think the improvement wouldn't work. [No flames detected, search stopped] Please notice I TRY to be funny here. I DON'T want a flame war (and didn't see one either). I just want as many discussion on my algo as possible hoping either to confirm it or to prove some way it fails (and either correct it or give up). >should be amenable to birthday testing. >If Nico's generator does indeed approximate to a virtual state machine with >less than 32 bits of state, then this could be detected by drawing at most a >few hundred thousand samples and counting the number of doubles (and triples >if any). Good thought. >I have a preprint on such testing if anybody's interested but the basic >principles should be obvious enough from basic probability theory. I already mailed the outhor for it. Maybe others are interested? >Ross Nico