On Tue, Oct 29, 2019 at 9:43 AM Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote: > > On Di, 2019-10-29 at 09:29 -0700, Andrey Smirnov wrote: > > Everyone: > > > > This series is a continuation of original [discussion]. I don't know > > if what's in the series is enough to use CAAMs HWRNG system wide, but > > I am hoping that with enough iterations and feedback it will be. > > > > Feedback is welcome! > > I'm not sure if we can ever use the job based RNG interface to hook it > up to the Linux HWRNG interface. After all the job based RNG interface > is always a DRNG, which only gets seeded by the TRNG. The reseed > interval is given in number of clock cycles, so there is no clear > correlation between really true random input bits and the number of > DRNG output bits. > Doesn't enabling prediction resistance gives us that correlation? E.g. that every time new random data is generated, DRNG is reseeded? I am assuming even if this is true we'd have to significantly limit generated data length (< seed length?), so maybe what you propose below is still simpler. > I've hacked up some proof of concept code which uses the TRNG access in > the control interface to get the raw TRNG random bits. This seems to > yield about 6400 bit/s of true entropy. It may be better to use this > interface to hook up to the Linux HWRNG framework. > OK, I'll take a look into that and send out a v2 with results. Thanks, Andrey Smirnov
