Messages in this thread | | | From | Andrey Smirnov <> | Date | Tue, 29 Oct 2019 12:58:24 -0700 | Subject | Re: [PATCH 0/3] enable CAAM's HWRNG as default |
| |
On Tue, Oct 29, 2019 at 9:43 AM Lucas Stach <l.stach@pengutronix.de> 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
| |