| Message ID | 20191029162916.26579-1-andrew.smirnov@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | enable CAAM's HWRNG as default | expand |
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. 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. Regards, Lucas
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
On Tue, Oct 29, 2019 at 09:29:13AM -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! > > Thanks, > Andrey Smirnov > > [discussion] https://patchwork.kernel.org/patch/9850669/ > > Andrey Smirnov (3): > crypto: caam - RNG4 TRNG errata > crypto: caam - enable prediction resistance in HRWNG > crypto: caam - set hwrng quality level > > drivers/crypto/caam/caamrng.c | 4 +++- > drivers/crypto/caam/ctrl.c | 19 +++++++++++++------ > drivers/crypto/caam/desc.h | 2 ++ > drivers/crypto/caam/regs.h | 7 +++++-- > 4 files changed, 23 insertions(+), 9 deletions(-) All applied. Thanks.
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? > > 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. Thanks,
On Fri, Nov 8, 2019 at 7:19 AM Herbert Xu <herbert@gondor.apana.org.au> 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
On Tue, Nov 12, 2019 at 07:13:02AM -0800, Andrey Smirnov wrote: > > If I am reading the datasheet right reseeding should be done every > time CAAM is asked to generated random data. If you can guarantee that everytime the driver reads n bytes from the hardware, that the hardware is then reseeded with nbytes prior to that read, then it should be good enough. If the hardware only reseeds afterwards or reseeds with less than n bytes then it is not sufficient. > 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. If it offers true prediction resistance it should be good enough to use the drivers/char/hw_random interface. Otherwise please switch to the Crypto API RNG interface. Thanks,