On Fri, Nov 8, 2019 at 7:19 AM Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Oct 29, 2019 at 12:58:24PM -0700, Andrey Smirnov wrote: > > > > > 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. > > Prediction resistance should be sufficient in general. However, > is the prediction resistance reseeding done in real time? > If I am reading the datasheet right reseeding should be done every time CAAM is asked to generated random data. > > > 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. > > I've backed out the patch-set for now but if we can clarify the > prediction resistance implementation details then I'm happy to > put it back in. Even if prediction resistance is an acceptable approach, would it be better to expose underlying TRNG and downgrade current CAAM hwrng code to crypto rng API? If that's the best path forward, I am more than happy to go that way in v2. Thanks, Andrey Smirnov
