Linux-Crypto Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH 0/3] enable CAAM's HWRNG as default
@ 2019-10-29 16:29 Andrey Smirnov
  2019-10-29 16:29 ` [PATCH 1/3] crypto: caam - RNG4 TRNG errata Andrey Smirnov
                   ` (4 more replies)
  0 siblings, 5 replies; 9+ messages in thread
From: Andrey Smirnov @ 2019-10-29 16:29 UTC (permalink / raw)
  To: linux-crypto
  Cc: Andrey Smirnov, Chris Healy, Lucas Stach, Horia Geantă,
	Herbert Xu, Iuliana Prodan, linux-kernel

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(-)

-- 
2.21.0


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH 1/3] crypto: caam - RNG4 TRNG errata
  2019-10-29 16:29 [PATCH 0/3] enable CAAM's HWRNG as default Andrey Smirnov
@ 2019-10-29 16:29 ` Andrey Smirnov
  2019-10-29 16:29 ` [PATCH 2/3] crypto: caam - enable prediction resistance in HRWNG Andrey Smirnov
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 9+ messages in thread
From: Andrey Smirnov @ 2019-10-29 16:29 UTC (permalink / raw)
  To: linux-crypto
  Cc: Andrey Smirnov, Aymen Sghaier, Vipul Kumar, Chris Healy,
	Lucas Stach, Horia Geantă,
	Herbert Xu, Iuliana Prodan, linux-kernel

The TRNG as used in RNG4, used in CAAM has a documentation issue. The
effect is that it is possible that the entropy used to instantiate the
DRBG may be old entropy, rather than newly generated entropy. There is
proper programming guidance, but it is not in the documentation.

Signed-off-by: Aymen Sghaier <aymen.sghaier@nxp.com>
Signed-off-by: Vipul Kumar <vipul_kumar@mentor.com>
[andrew.smirnov@gmail.com ported to upstream kernel]
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Horia Geantă <horia.geanta@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Iuliana Prodan <iuliana.prodan@nxp.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/crypto/caam/ctrl.c | 11 ++++++++---
 drivers/crypto/caam/regs.h |  3 ++-
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index d7c3c3805693..df4db10e9fca 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -338,8 +338,12 @@ static void kick_trng(struct platform_device *pdev, int ent_delay)
 	ctrl = (struct caam_ctrl __iomem *)ctrlpriv->ctrl;
 	r4tst = &ctrl->r4tst[0];
 
-	/* put RNG4 into program mode */
-	clrsetbits_32(&r4tst->rtmctl, 0, RTMCTL_PRGM);
+	/*
+	 * Setting both RTMCTL:PRGM and RTMCTL:TRNG_ACC causes TRNG to
+	 * properly invalidate the entropy in the entropy register and
+	 * force re-generation.
+	 */
+	clrsetbits_32(&r4tst->rtmctl, 0, RTMCTL_PRGM | RTMCTL_ACC);
 
 	/*
 	 * Performance-wise, it does not make sense to
@@ -369,7 +373,8 @@ static void kick_trng(struct platform_device *pdev, int ent_delay)
 	 * select raw sampling in both entropy shifter
 	 * and statistical checker; ; put RNG4 into run mode
 	 */
-	clrsetbits_32(&r4tst->rtmctl, RTMCTL_PRGM, RTMCTL_SAMP_MODE_RAW_ES_SC);
+	clrsetbits_32(&r4tst->rtmctl, RTMCTL_PRGM | RTMCTL_ACC,
+		      RTMCTL_SAMP_MODE_RAW_ES_SC);
 }
 
 static int caam_get_era_from_hw(struct caam_ctrl __iomem *ctrl)
diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
index 05127b70527d..c191e8fd0fa7 100644
--- a/drivers/crypto/caam/regs.h
+++ b/drivers/crypto/caam/regs.h
@@ -487,7 +487,8 @@ struct rngtst {
 
 /* RNG4 TRNG test registers */
 struct rng4tst {
-#define RTMCTL_PRGM	0x00010000	/* 1 -> program mode, 0 -> run mode */
+#define RTMCTL_ACC  BIT(5)  /* TRNG access mode */
+#define RTMCTL_PRGM BIT(16) /* 1 -> program mode, 0 -> run mode */
 #define RTMCTL_SAMP_MODE_VON_NEUMANN_ES_SC	0 /* use von Neumann data in
 						     both entropy shifter and
 						     statistical checker */
-- 
2.21.0


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH 2/3] crypto: caam - enable prediction resistance in HRWNG
  2019-10-29 16:29 [PATCH 0/3] enable CAAM's HWRNG as default Andrey Smirnov
  2019-10-29 16:29 ` [PATCH 1/3] crypto: caam - RNG4 TRNG errata Andrey Smirnov
@ 2019-10-29 16:29 ` Andrey Smirnov
  2019-10-29 16:29 ` [PATCH 3/3] crypto: caam - set hwrng quality level Andrey Smirnov
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 9+ messages in thread
From: Andrey Smirnov @ 2019-10-29 16:29 UTC (permalink / raw)
  To: linux-crypto
  Cc: Andrey Smirnov, Chris Healy, Lucas Stach, Horia Geantă,
	Herbert Xu, Iuliana Prodan, linux-kernel

Instantiate CAAM RNG with prediction resistance enabled to improve its
quality.

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Horia Geantă <horia.geanta@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Iuliana Prodan <iuliana.prodan@nxp.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/crypto/caam/caamrng.c | 3 ++-
 drivers/crypto/caam/ctrl.c    | 8 +++++---
 drivers/crypto/caam/desc.h    | 2 ++
 drivers/crypto/caam/regs.h    | 4 +++-
 4 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
index e8baacaabe07..6dde8ae3cd9b 100644
--- a/drivers/crypto/caam/caamrng.c
+++ b/drivers/crypto/caam/caamrng.c
@@ -202,7 +202,8 @@ static inline int rng_create_sh_desc(struct caam_rng_ctx *ctx)
 	init_sh_desc(desc, HDR_SHARE_SERIAL);
 
 	/* Generate random bytes */
-	append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG);
+	append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG |
+			 OP_ALG_PR_ON);
 
 	/* Store bytes */
 	append_seq_fifo_store(desc, RN_BUF_SIZE, FIFOST_TYPE_RNGSTORE);
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index df4db10e9fca..a1c879820286 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -36,7 +36,8 @@ static void build_instantiation_desc(u32 *desc, int handle, int do_sk)
 	init_job_desc(desc, 0);
 
 	op_flags = OP_TYPE_CLASS1_ALG | OP_ALG_ALGSEL_RNG |
-			(handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INIT;
+			(handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INIT |
+			OP_ALG_PR_ON;
 
 	/* INIT RNG in non-test mode */
 	append_operation(desc, op_flags);
@@ -275,11 +276,12 @@ static int instantiate_rng(struct device *ctrldev, int state_handle_mask,
 		return -ENOMEM;
 
 	for (sh_idx = 0; sh_idx < RNG4_MAX_HANDLES; sh_idx++) {
+		const u32 rdsta_mask = (RDSTA_PR0 | RDSTA_IF0) << sh_idx;
 		/*
 		 * If the corresponding bit is set, this state handle
 		 * was initialized by somebody else, so it's left alone.
 		 */
-		if ((1 << sh_idx) & state_handle_mask)
+		if (rdsta_mask & state_handle_mask)
 			continue;
 
 		/* Create the descriptor for instantiating RNG State Handle */
@@ -302,7 +304,7 @@ static int instantiate_rng(struct device *ctrldev, int state_handle_mask,
 
 		rdsta_val = rd_reg32(&ctrl->r4tst[0].rdsta) & RDSTA_IFMASK;
 		if ((status && status != JRSTA_SSRC_JUMP_HALT_CC) ||
-		    !(rdsta_val & (1 << sh_idx))) {
+		    (rdsta_val & rdsta_mask) != rdsta_mask) {
 			ret = -EAGAIN;
 			break;
 		}
diff --git a/drivers/crypto/caam/desc.h b/drivers/crypto/caam/desc.h
index 4b6854bf896a..e796d3cb9be8 100644
--- a/drivers/crypto/caam/desc.h
+++ b/drivers/crypto/caam/desc.h
@@ -1254,6 +1254,8 @@
 #define OP_ALG_ICV_OFF		(0 << OP_ALG_ICV_SHIFT)
 #define OP_ALG_ICV_ON		(1 << OP_ALG_ICV_SHIFT)
 
+#define OP_ALG_PR_ON		BIT(1)
+
 #define OP_ALG_DIR_SHIFT	0
 #define OP_ALG_DIR_MASK		1
 #define OP_ALG_DECRYPT		0
diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
index c191e8fd0fa7..fe1f8c1409fd 100644
--- a/drivers/crypto/caam/regs.h
+++ b/drivers/crypto/caam/regs.h
@@ -524,9 +524,11 @@ struct rng4tst {
 	u32 rsvd1[40];
 #define RDSTA_SKVT 0x80000000
 #define RDSTA_SKVN 0x40000000
+#define RDSTA_PR0 BIT(4)
+#define RDSTA_PR1 BIT(5)
 #define RDSTA_IF0 0x00000001
 #define RDSTA_IF1 0x00000002
-#define RDSTA_IFMASK (RDSTA_IF1 | RDSTA_IF0)
+#define RDSTA_IFMASK (RDSTA_PR1 | RDSTA_PR0 | RDSTA_IF1 | RDSTA_IF0)
 	u32 rdsta;
 	u32 rsvd2[15];
 };
-- 
2.21.0


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH 3/3] crypto: caam - set hwrng quality level
  2019-10-29 16:29 [PATCH 0/3] enable CAAM's HWRNG as default Andrey Smirnov
  2019-10-29 16:29 ` [PATCH 1/3] crypto: caam - RNG4 TRNG errata Andrey Smirnov
  2019-10-29 16:29 ` [PATCH 2/3] crypto: caam - enable prediction resistance in HRWNG Andrey Smirnov
@ 2019-10-29 16:29 ` Andrey Smirnov
  2019-10-29 16:43 ` [PATCH 0/3] enable CAAM's HWRNG as default Lucas Stach
  2019-11-08 15:14 ` Herbert Xu
  4 siblings, 0 replies; 9+ messages in thread
From: Andrey Smirnov @ 2019-10-29 16:29 UTC (permalink / raw)
  To: linux-crypto
  Cc: Andrey Smirnov, Oleksij Rempel, Chris Healy, Lucas Stach,
	Horia Geantă,
	Herbert Xu, Iuliana Prodan, linux-kernel

Set high quality to let the HWRNG framework automatically use it.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Horia Geantă <horia.geanta@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Iuliana Prodan <iuliana.prodan@nxp.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/crypto/caam/caamrng.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
index 6dde8ae3cd9b..23a573ea6cdb 100644
--- a/drivers/crypto/caam/caamrng.c
+++ b/drivers/crypto/caam/caamrng.c
@@ -299,6 +299,7 @@ static struct hwrng caam_rng = {
 	.name		= "rng-caam",
 	.cleanup	= caam_cleanup,
 	.read		= caam_read,
+	.quality	= 999,
 };
 
 void caam_rng_exit(void)
-- 
2.21.0


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/3] enable CAAM's HWRNG as default
  2019-10-29 16:29 [PATCH 0/3] enable CAAM's HWRNG as default Andrey Smirnov
                   ` (2 preceding siblings ...)
  2019-10-29 16:29 ` [PATCH 3/3] crypto: caam - set hwrng quality level Andrey Smirnov
@ 2019-10-29 16:43 ` Lucas Stach
  2019-10-29 19:58   ` Andrey Smirnov
  2019-11-08 15:14 ` Herbert Xu
  4 siblings, 1 reply; 9+ messages in thread
From: Lucas Stach @ 2019-10-29 16:43 UTC (permalink / raw)
  To: Andrey Smirnov, linux-crypto
  Cc: Chris Healy, Horia Geantă, Herbert Xu, Iuliana Prodan, linux-kernel

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/3] enable CAAM's HWRNG as default
  2019-10-29 16:43 ` [PATCH 0/3] enable CAAM's HWRNG as default Lucas Stach
@ 2019-10-29 19:58   ` Andrey Smirnov
  2019-11-08 15:19     ` Herbert Xu
  0 siblings, 1 reply; 9+ messages in thread
From: Andrey Smirnov @ 2019-10-29 19:58 UTC (permalink / raw)
  To: Lucas Stach
  Cc: open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Chris Healy,
	Horia Geantă,
	Herbert Xu, Iuliana Prodan, linux-kernel

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/3] enable CAAM's HWRNG as default
  2019-10-29 16:29 [PATCH 0/3] enable CAAM's HWRNG as default Andrey Smirnov
                   ` (3 preceding siblings ...)
  2019-10-29 16:43 ` [PATCH 0/3] enable CAAM's HWRNG as default Lucas Stach
@ 2019-11-08 15:14 ` Herbert Xu
  4 siblings, 0 replies; 9+ messages in thread
From: Herbert Xu @ 2019-11-08 15:14 UTC (permalink / raw)
  To: Andrey Smirnov
  Cc: linux-crypto, Chris Healy, Lucas Stach, Horia Geantă,
	Iuliana Prodan, linux-kernel

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.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/3] enable CAAM's HWRNG as default
  2019-10-29 19:58   ` Andrey Smirnov
@ 2019-11-08 15:19     ` Herbert Xu
  2019-11-12 15:13       ` Andrey Smirnov
  0 siblings, 1 reply; 9+ messages in thread
From: Herbert Xu @ 2019-11-08 15:19 UTC (permalink / raw)
  To: Andrey Smirnov
  Cc: Lucas Stach, open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
	Chris Healy, Horia Geantă,
	Iuliana Prodan, linux-kernel

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,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/3] enable CAAM's HWRNG as default
  2019-11-08 15:19     ` Herbert Xu
@ 2019-11-12 15:13       ` Andrey Smirnov
  0 siblings, 0 replies; 9+ messages in thread
From: Andrey Smirnov @ 2019-11-12 15:13 UTC (permalink / raw)
  To: Herbert Xu
  Cc: Lucas Stach, open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
	Chris Healy, Horia Geantă,
	Iuliana Prodan, linux-kernel

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, back to index

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-29 16:29 [PATCH 0/3] enable CAAM's HWRNG as default Andrey Smirnov
2019-10-29 16:29 ` [PATCH 1/3] crypto: caam - RNG4 TRNG errata Andrey Smirnov
2019-10-29 16:29 ` [PATCH 2/3] crypto: caam - enable prediction resistance in HRWNG Andrey Smirnov
2019-10-29 16:29 ` [PATCH 3/3] crypto: caam - set hwrng quality level Andrey Smirnov
2019-10-29 16:43 ` [PATCH 0/3] enable CAAM's HWRNG as default Lucas Stach
2019-10-29 19:58   ` Andrey Smirnov
2019-11-08 15:19     ` Herbert Xu
2019-11-12 15:13       ` Andrey Smirnov
2019-11-08 15:14 ` Herbert Xu

Linux-Crypto Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-crypto/0 linux-crypto/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-crypto linux-crypto/ https://lore.kernel.org/linux-crypto \
		linux-crypto@vger.kernel.org
	public-inbox-index linux-crypto

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-crypto


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git