* Re: [PATCH v6 0/5] /dev/random - a new approach
From: H. Peter Anvin @ 2016-08-16 22:49 UTC (permalink / raw)
To: Stephan Mueller
Cc: herbert, Ted Tso, sandyinchina, Jason Cooper, John Denker,
Joe Perches, Pavel Machek, George Spelvin, linux-crypto,
linux-kernel
In-Reply-To: <2f43d23f-5fbe-9653-fc1c-489db1c7bde4@linux.intel.com>
On 08/16/16 15:28, H. Peter Anvin wrote:
> On 08/15/16 22:45, Stephan Mueller wrote:
>> Am Montag, 15. August 2016, 13:42:54 CEST schrieb H. Peter Anvin:
>>
>> Hi H,
>>
>>> On 08/11/16 05:24, Stephan Mueller wrote:
>>>> * prevent fast noise sources from dominating slow noise sources
>>>>
>>>> in case of /dev/random
>>>
>>> Can someone please explain if and why this is actually desirable, and if
>>> this assessment has been passed to someone who has actual experience
>>> with cryptography at the professional level?
>>
>> There are two motivations for that:
>>
>> - the current /dev/random is compliant to NTG.1 from AIS 20/31 which requires
>> (in brief words) that entropy comes from auditible noise sources. Currently in
>> my LRNG only RDRAND is a fast noise source which is not auditible (and it is
>> designed to cause a VM exit making it even harder to assess it). To make the
>> LRNG to comply with NTG.1, RDRAND can provide entropy but must not become the
>> sole entropy provider which is the case now with that change.
>>
>> - the current /dev/random implementation follows the same concept with the
>> exception of 3.15 and 3.16 where RDRAND was not rate-limited. In later
>> versions, this was changed.
>>
>
> I'm not saying it should be *sole*. I am questioning the value in
> limiting it, as it seems to me that it could only ever produce a worse
> result.
>
Also, it would be great to actually get a definition for "auditable". A
quantum white noise source which exceeds the sampling bandwidth is an
ideal RNG; how do you "audit" that? If what you are doing is looking
for imperfections, those imperfections can be trivially emulated. If
what you mean is an audit on the chip or circuit level, that would
require some mechanism to know that all items were built identically
without deviation, which may be possible for intelligence agencies or
the military who have full control of their supply chain, but for anyone
else that is most likely an impossible task. How many people are going
to crack the case and look at even a discrete transistor circuit, and
how many of *those* are going to be able to discern if that circuit is
subject to RF capture, or its output even used?
I have been trying to figure out how to reasonably solve this problem
for a long time now, and it is not just a problem for RDSEED (RDRAND is
a slightly different beast.) The only reason RDSEED exposes the problem
particularly harshly is because it is extremely high bandwidth compared
to other noise sources and it is architecturally integrated into the
CPU, but the same would apply to an external noise generator connected
via PCIe, for example.
Incidentally, I am hoping -- and this is a personal statement and
nothing official from Intel -- that at some future date RDRAND (not
RDSEED) will be fast enough that it can completely replace even
prandom_u32(), which I really hope can be non-controversial as
prandom_u32() isn't cryptographically strong in the first place.
-hpa
^ permalink raw reply
* Re: [PATCH v6 0/5] /dev/random - a new approach
From: H. Peter Anvin @ 2016-08-16 22:28 UTC (permalink / raw)
To: Stephan Mueller
Cc: herbert, Ted Tso, sandyinchina, Jason Cooper, John Denker,
Joe Perches, Pavel Machek, George Spelvin, linux-crypto,
linux-kernel
In-Reply-To: <2672856.NsbgmUcCJx@tauon.atsec.com>
On 08/15/16 22:45, Stephan Mueller wrote:
> Am Montag, 15. August 2016, 13:42:54 CEST schrieb H. Peter Anvin:
>
> Hi H,
>
>> On 08/11/16 05:24, Stephan Mueller wrote:
>>> * prevent fast noise sources from dominating slow noise sources
>>>
>>> in case of /dev/random
>>
>> Can someone please explain if and why this is actually desirable, and if
>> this assessment has been passed to someone who has actual experience
>> with cryptography at the professional level?
>
> There are two motivations for that:
>
> - the current /dev/random is compliant to NTG.1 from AIS 20/31 which requires
> (in brief words) that entropy comes from auditible noise sources. Currently in
> my LRNG only RDRAND is a fast noise source which is not auditible (and it is
> designed to cause a VM exit making it even harder to assess it). To make the
> LRNG to comply with NTG.1, RDRAND can provide entropy but must not become the
> sole entropy provider which is the case now with that change.
>
> - the current /dev/random implementation follows the same concept with the
> exception of 3.15 and 3.16 where RDRAND was not rate-limited. In later
> versions, this was changed.
>
I'm not saying it should be *sole*. I am questioning the value in
limiting it, as it seems to me that it could only ever produce a worse
result.
-hpa
^ permalink raw reply
* [PATCH V2 linux-next] hwrng: update Freescale i.MX RNGA Random Number Generator
From: Fabian Frederick @ 2016-08-16 19:49 UTC (permalink / raw)
To: Matt Mackall, Herbert Xu; +Cc: linux-crypto, Arnd Bergmann, linux-kernel, fabf
We can directly depend on SOC_IMX31 since commit c9ee94965dce
("ARM: imx: deconstruct mxc_rnga initialization")
Since that commit, CONFIG_HW_RANDOM_MXC_RNGA could not be switched on
with unknown symbol ARCH_HAS_RNGA and mxc-rnga.o can't be generated with
ARCH=arm make M=drivers/char/hw_random
Previously, HW_RANDOM_MXC_RNGA required ARCH_HAS_RNGA
which was based on IMX_HAVE_PLATFORM_MXC_RNGA && ARCH_MXC.
IMX_HAVE_PLATFORM_MXC_RNGA was based on SOC_IMX31.
Fixes: c9ee94965dce ("ARM: imx: deconstruct mxc_rnga initialization")
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
-Cc to linux-crypto (suggested by Herbert Xu)
-Adding "Fixes:" (suggested by Arnd Bergmann)
-This patch appeared in 4.8-rc1 (not in stable yet)
-Improving patch description
drivers/char/hw_random/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 56ad5a59..8c0770b 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -244,7 +244,7 @@ config HW_RANDOM_TX4939
config HW_RANDOM_MXC_RNGA
tristate "Freescale i.MX RNGA Random Number Generator"
- depends on ARCH_HAS_RNGA
+ depends on SOC_IMX31
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
--
2.8.1
^ permalink raw reply related
* Re: [PATCH] hwrng-PIC32: Delete unnecessary assignment for the field "owner"
From: Herbert Xu @ 2016-08-16 9:59 UTC (permalink / raw)
To: SF Markus Elfring
Cc: linux-crypto, Daniel Thompson, Joshua Henderson, Matt Mackall,
Purna Chandra Mandal, LKML, kernel-janitors, Julia Lawall
In-Reply-To: <9205db89-24dc-8dc5-0e6c-1bfd60abf77f@users.sourceforge.net>
On Tue, Aug 16, 2016 at 08:04:11AM +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 16 Aug 2016 07:51:21 +0200
>
> The field "owner" is set by the core.
> Thus delete an unneeded initialisation.
>
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Patch 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
* Re: [PATCH] crypto: fix ctx pointer in sha512-mb
From: Herbert Xu @ 2016-08-16 9:55 UTC (permalink / raw)
To: Xiaodong Liu; +Cc: linux-crypto, tim.c.chen, megha.dey, linux-kernel
In-Reply-To: <1470997711-118507-1-git-send-email-xiaodong.liu@intel.com>
On Fri, Aug 12, 2016 at 06:28:31AM -0400, Xiaodong Liu wrote:
> Signed-off-by: Xiaodong Liu <xiaodong.liu@intel.com>
Patch applied. I copied some of the text from the previous patch.
Please do try to write something here next time.
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
* Re: [PATCH] crypto: fix ctx pointer and digest copy in sha256-mb
From: Herbert Xu @ 2016-08-16 9:52 UTC (permalink / raw)
To: Xiaodong Liu; +Cc: linux-crypto, tim.c.chen, megha.dey, linux-kernel
In-Reply-To: <1470997482-118327-1-git-send-email-xiaodong.liu@intel.com>
On Fri, Aug 12, 2016 at 06:24:42AM -0400, Xiaodong Liu wrote:
> 1. fix ctx pointer
> Use req_ctx which is the ctx for the next job that have
> been completed in the lanes instead of the first
> completed job rctx, whose completion could have been
> called and released.
> 2. fix digest copy
> Use XMM register to copy another 16 bytes sha256 digest
> instead of a regular register.
>
> Signed-off-by: Xiaodong Liu <xiaodong.liu@intel.com>
Patch 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
* Re: [PATCH -next] crypto: ccp - Fix non static symbol warning
From: Herbert Xu @ 2016-08-16 9:52 UTC (permalink / raw)
To: Wei Yongjun; +Cc: Tom Lendacky, Gary Hook, David S. Miller, linux-crypto
In-Reply-To: <1470960009-17784-1-git-send-email-weiyj.lk@gmail.com>
On Fri, Aug 12, 2016 at 12:00:09AM +0000, Wei Yongjun wrote:
> Fixes the following sparse warning:
>
> drivers/crypto/ccp/ccp-dev.c:62:14: warning:
> symbol 'ccp_increment_unit_ordinal' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
Patch 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
* Re: [PATCH 1/6] crypto: sun4i-ss: fix a few signed warning
From: Herbert Xu @ 2016-08-16 9:50 UTC (permalink / raw)
To: LABBE Corentin; +Cc: davem, maxime.ripard, wens, linux-crypto, linux-kernel
In-Reply-To: <1470822334-20672-1-git-send-email-clabbe.montjoie@gmail.com>
On Wed, Aug 10, 2016 at 11:45:29AM +0200, LABBE Corentin wrote:
> The variable i is always checked against unsigned value and cannot be
> negative.
> This patch set it as unsigned.
>
> Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
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
* Re: [PATCH] crypto: DRBG: do not call drbg_instantiate in healt test
From: Herbert Xu @ 2016-08-16 9:49 UTC (permalink / raw)
To: Stephan Mueller; +Cc: TSarangi, linux-crypto
In-Reply-To: <6079382.fWeFLzBGfE@positron.chronox.de>
Stephan Mueller <smueller@chronox.de> wrote:
> Am Dienstag, 9. August 2016, 19:52:46 CEST schrieb Stephan Mueller:
>
> Hi Tapas,
>
> I think I found the issue. Can you please test the attached patch?
>
> ---8<---
>
> When calling the DRBG health test in FIPS mode, the Jitter RNG is not
> yet present in the kernel crypto API which will cause the instantiation
> to fail and thus the health test to fail.
>
> As the health tests cover the enforcement of various thresholds, invoke
> the functions that are supposed to enforce the thresholds directly.
>
> This patch also saves precious seed.
>
> Reported-by: Tapas Sarangi <TSarangi@trustwave.com>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
Patch 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
* Re: [PATCH] crypto: fix a little typo
From: Herbert Xu @ 2016-08-16 9:50 UTC (permalink / raw)
To: LABBE Corentin; +Cc: linux-crypto, linux-kernel
In-Reply-To: <1470821373-8228-1-git-send-email-clabbe.montjoie@gmail.com>
On Wed, Aug 10, 2016 at 11:29:33AM +0200, LABBE Corentin wrote:
> The sentence 'Based on' is misspelled, respell it.
>
> Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
Patch 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
* [PATCH v2] crypto: XTS - remove test that will fail in FIPS mode
From: Stephan Mueller @ 2016-08-16 9:38 UTC (permalink / raw)
To: Tapas Sarangi; +Cc: herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org
In-Reply-To: <3590892.3HIz2aNZPY@positron.chronox.de>
Hi Tapas,
I was able to reproduce the issue now.
I tested the patch below and it works for me now. Yet, I see that dracut-fips seems to need some fixes too as it cannot find cmac when compiled as module and has some issues with the authenc() ciphers too.
---8<---
In FIPS mode, setting XTS keys where the AES key is identical to the
tweak key is forbidden. Thus, the self test with such property will fail
in FIPS mode.
As we have other tests available for XTS, this patch simply removes the
offending test vectors.
Reported-by: Tapas Sarangi <TSarangi@trustwave.com>
Signed-off-by: Stephan Mueller <stephan.mueller@atsec.com>
---
crypto/testmgr.h | 44 ++++----------------------------------------
1 file changed, 4 insertions(+), 40 deletions(-)
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index acb6bbf..893b321 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -15179,8 +15179,8 @@ static struct cipher_testvec cast6_xts_dec_tv_template[] = {
#define HMAC_SHA512_AES_CBC_ENC_TEST_VEC 7
#define AES_LRW_ENC_TEST_VECTORS 8
#define AES_LRW_DEC_TEST_VECTORS 8
-#define AES_XTS_ENC_TEST_VECTORS 5
-#define AES_XTS_DEC_TEST_VECTORS 5
+#define AES_XTS_ENC_TEST_VECTORS 4
+#define AES_XTS_DEC_TEST_VECTORS 4
#define AES_CTR_ENC_TEST_VECTORS 5
#define AES_CTR_DEC_TEST_VECTORS 5
#define AES_OFB_ENC_TEST_VECTORS 1
@@ -18218,25 +18218,7 @@ static struct cipher_testvec aes_lrw_dec_tv_template[] = {
static struct cipher_testvec aes_xts_enc_tv_template[] = {
/* http://grouper.ieee.org/groups/1619/email/pdf00086.pdf */
- { /* XTS-AES 1 */
- .key = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .klen = 32,
- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .input = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .ilen = 32,
- .result = "\x91\x7c\xf6\x9e\xbd\x68\xb2\xec"
- "\x9b\x9f\xe9\xa3\xea\xdd\xa6\x92"
- "\xcd\x43\xd2\xf5\x95\x98\xed\x85"
- "\x8c\x02\xc2\x65\x2f\xbf\x92\x2e",
- .rlen = 32,
- }, { /* XTS-AES 2 */
+ { /* XTS-AES 2 */
.key = "\x11\x11\x11\x11\x11\x11\x11\x11"
"\x11\x11\x11\x11\x11\x11\x11\x11"
"\x22\x22\x22\x22\x22\x22\x22\x22"
@@ -18560,25 +18542,7 @@ static struct cipher_testvec aes_xts_enc_tv_template[] = {
static struct cipher_testvec aes_xts_dec_tv_template[] = {
/* http://grouper.ieee.org/groups/1619/email/pdf00086.pdf */
- { /* XTS-AES 1 */
- .key = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .klen = 32,
- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .input = "\x91\x7c\xf6\x9e\xbd\x68\xb2\xec"
- "\x9b\x9f\xe9\xa3\xea\xdd\xa6\x92"
- "\xcd\x43\xd2\xf5\x95\x98\xed\x85"
- "\x8c\x02\xc2\x65\x2f\xbf\x92\x2e",
- .ilen = 32,
- .result = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .rlen = 32,
- }, { /* XTS-AES 2 */
+ { /* XTS-AES 2 */
.key = "\x11\x11\x11\x11\x11\x11\x11\x11"
"\x11\x11\x11\x11\x11\x11\x11\x11"
"\x22\x22\x22\x22\x22\x22\x22\x22"
--
2.7.4
^ permalink raw reply related
* Re: RSA key size not allowed in FIPS
From: Stephan Mueller @ 2016-08-16 9:33 UTC (permalink / raw)
To: Tapas Sarangi; +Cc: dhowells, linux-crypto@vger.kernel.org
In-Reply-To: <21317106.O9C0GvNNQc@positron.chronox.de>
Am Dienstag, 9. August 2016, 16:55:52 CEST schrieb Stephan Mueller:
Hi Tapas, David,
>
> David, the x509.genkey file seems to generate a 4k RSA key per default. This
> will cause a panic with fips=1 as only 2k and 3k keys are allowed.
Just yesterday, a new ruling came out from NIST allowing any key size >= 2048
provided that at least either 2048 or 3072 is a usable key size to allow CAVS
testing.
I will send a patch that changes this in the code.
Thanks
Stephan
^ permalink raw reply
* Re: [PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function
From: Herbert Xu @ 2016-08-16 9:26 UTC (permalink / raw)
To: Stephan Mueller; +Cc: mathew.j.martineau, dhowells, linux-crypto, keyrings
In-Reply-To: <1605606.kqFagSqufY@tauon.atsec.com>
On Tue, Aug 16, 2016 at 11:25:33AM +0200, Stephan Mueller wrote:
>> I was thinking of the DRBG implementation: decouple it from the underlying
> ciphers. Though, I am not fully sure that will work as there are several
> specific settings that depend on the underlying ciphers (e.g. the state of a
> Hash DRBG with SHA-256 is 444 bits whereas a Hash DRBG with SHA-512 has 888
> bits).
The only reason DRBG is in crypto is because it implements stdrng.
Cheers,
--
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
* Re: [PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function
From: Stephan Mueller @ 2016-08-16 9:25 UTC (permalink / raw)
To: Herbert Xu; +Cc: mathew.j.martineau, dhowells, linux-crypto, keyrings
In-Reply-To: <20160816091347.GA26733@gondor.apana.org.au>
Am Dienstag, 16. August 2016, 17:13:47 CEST schrieb Herbert Xu:
Hi Herbert,
> On Tue, Aug 16, 2016 at 11:11:47AM +0200, Stephan Mueller wrote:
> > Conceptually, a KDF is a random number generator by generating arbitrarily
> > sized strings from a fixed "seed". This lead me to add the RNG template
> > handling. Even the existing DRBG is more or less a "block chaining mode"
> > that is very similar to a KDF. Hence, the current plethora of 22
> > registered DRBGs could be elegantly eliminated if the DRBG is turned into
> > template using the proposed RNG framework.
>
> The point is that there is no alternative implementation for kdf,
> nor is there likely to be one.
I was thinking of the DRBG implementation: decouple it from the underlying
ciphers. Though, I am not fully sure that will work as there are several
specific settings that depend on the underlying ciphers (e.g. the state of a
Hash DRBG with SHA-256 is 444 bits whereas a Hash DRBG with SHA-512 has 888
bits).
>
> > If you think that a KDF should not be a generic mechanism, then the KDF
> > logic would need to move directly into the keys subsystem. But since TLS
> > is something folks speak about, a TLS KDF would need to be considered
> > eventually too which is yet again some form of RNG.
>
> If a TLS KDF comes with a hardware implementation then we could
> include it. Otherwise the answer would be the same.
It is certainly not an issue to move the KDF logic into the keys subsystem.
However, as it (may) resemble SP800-56A which is in line with FIPS 140-2,
folks may ask for a FIPS stamp on it. If a FIPS stamp is asked for, the KDF
itself must be subject to a self test (like what we have in testmgr.c). If we
move the KDF to the keys subsystem, the self test would then need to be
implemented there.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function
From: Herbert Xu @ 2016-08-16 9:13 UTC (permalink / raw)
To: Stephan Mueller; +Cc: mathew.j.martineau, dhowells, linux-crypto, keyrings
In-Reply-To: <11427544.kWdLX5BMAt@tauon.atsec.com>
On Tue, Aug 16, 2016 at 11:11:47AM +0200, Stephan Mueller wrote:
>
> Conceptually, a KDF is a random number generator by generating arbitrarily
> sized strings from a fixed "seed". This lead me to add the RNG template
> handling. Even the existing DRBG is more or less a "block chaining mode" that
> is very similar to a KDF. Hence, the current plethora of 22 registered DRBGs
> could be elegantly eliminated if the DRBG is turned into template using the
> proposed RNG framework.
The point is that there is no alternative implementation for kdf,
nor is there likely to be one.
> If you think that a KDF should not be a generic mechanism, then the KDF logic
> would need to move directly into the keys subsystem. But since TLS is
> something folks speak about, a TLS KDF would need to be considered eventually
> too which is yet again some form of RNG.
If a TLS KDF comes with a hardware implementation then we could
include it. Otherwise the answer would be the same.
Cheers,
--
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
* Re: [PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function
From: Stephan Mueller @ 2016-08-16 9:11 UTC (permalink / raw)
To: Herbert Xu; +Cc: mathew.j.martineau, dhowells, linux-crypto, keyrings
In-Reply-To: <20160816085745.GA26547@gondor.apana.org.au>
Am Dienstag, 16. August 2016, 16:57:45 CEST schrieb Herbert Xu:
Hi Herbert,
> On Tue, Aug 09, 2016 at 02:28:37PM +0200, Stephan Mueller wrote:
> > The SP800-108 compliant Key Derivation Function is implemented as a
> > random number generator considering that it behaves like a deterministic
> > RNG.
> >
> > All three KDF types specified in SP800-108 are implemented.
> >
> > The code comments provide details about how to invoke the different KDF
> > types.
> >
> > Signed-off-by: Stephan Mueller <smueller@chronox.de>
>
> So I have no problems with this functionality existing in the kernel,
> assuming that the keys patch using it is accepted.
>
> However, I'm still at a loss as to why this has to be done as
> an RNG. IOW what benefit does implementing this as an RNG give
> us compared to just using the underlying hash directly from the
> keys subsystem?
>
> In general the crypto API caters to algorithms that carry more
> than one implementation, especially if one of them is hardware-
> dependent. I really can't see how KDF would fit this criterion.
The KDF is logically equivalent to a block chaining mode. As the KDF can be
applied to arbitrary hash types (keyed and non-keyed), I thought of how to
integrate it with the existing framework. None of the template mechanisms seem
to fit what the KDF does.
Conceptually, a KDF is a random number generator by generating arbitrarily
sized strings from a fixed "seed". This lead me to add the RNG template
handling. Even the existing DRBG is more or less a "block chaining mode" that
is very similar to a KDF. Hence, the current plethora of 22 registered DRBGs
could be elegantly eliminated if the DRBG is turned into template using the
proposed RNG framework.
If you think that a KDF should not be a generic mechanism, then the KDF logic
would need to move directly into the keys subsystem. But since TLS is
something folks speak about, a TLS KDF would need to be considered eventually
too which is yet again some form of RNG.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function
From: Herbert Xu @ 2016-08-16 8:57 UTC (permalink / raw)
To: Stephan Mueller; +Cc: mathew.j.martineau, dhowells, linux-crypto, keyrings
In-Reply-To: <1734150.tKo42fLWeE@positron.chronox.de>
On Tue, Aug 09, 2016 at 02:28:37PM +0200, Stephan Mueller wrote:
> The SP800-108 compliant Key Derivation Function is implemented as a
> random number generator considering that it behaves like a deterministic
> RNG.
>
> All three KDF types specified in SP800-108 are implemented.
>
> The code comments provide details about how to invoke the different KDF
> types.
>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
So I have no problems with this functionality existing in the kernel,
assuming that the keys patch using it is accepted.
However, I'm still at a loss as to why this has to be done as
an RNG. IOW what benefit does implementing this as an RNG give
us compared to just using the underlying hash directly from the
keys subsystem?
In general the crypto API caters to algorithms that carry more
than one implementation, especially if one of them is hardware-
dependent. I really can't see how KDF would fit this criterion.
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
* Crypto Fixes for 4.8
From: Herbert Xu @ 2016-08-16 8:48 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20160627062819.GA6284@gondor.apana.org.au>
Hi Linus:
This push fixes the following issue:
- Missing ULL suffixes for 64-bit constants in sha3.
- Two caam AEAD regressions.
- Bogus setkey hooks in non-hmac caam hashes.
- Missing kbuild dependency for powerpc crc32c.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Geert Uytterhoeven (1):
crypto: sha3 - Add missing ULL suffixes for 64-bit constants
Horia Geantă (2):
crypto: caam - fix echainiv(authenc) encrypt shared descriptor
crypto: caam - defer aead_set_sh_desc in case of zero authsize
Michael Ellerman (1):
crypto: powerpc - CRYPT_CRC32C_VPMSUM should depend on ALTIVEC
Russell King (1):
crypto: caam - fix non-hmac hashes
crypto/Kconfig | 2 +-
crypto/sha3_generic.c | 16 ++++++++--------
drivers/crypto/caam/caamalg.c | 13 ++++++++-----
drivers/crypto/caam/caamhash.c | 1 +
4 files changed, 18 insertions(+), 14 deletions(-)
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
* [PATCH] hwrng-PIC32: Delete unnecessary assignment for the field "owner"
From: SF Markus Elfring @ 2016-08-16 6:04 UTC (permalink / raw)
To: linux-crypto, Daniel Thompson, Herbert Xu, Joshua Henderson,
Matt Mackall, Purna Chandra Mandal
Cc: LKML, kernel-janitors, Julia Lawall
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Tue, 16 Aug 2016 07:51:21 +0200
The field "owner" is set by the core.
Thus delete an unneeded initialisation.
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/char/hw_random/pic32-rng.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/hw_random/pic32-rng.c b/drivers/char/hw_random/pic32-rng.c
index 108897b..11dc9b7 100644
--- a/drivers/char/hw_random/pic32-rng.c
+++ b/drivers/char/hw_random/pic32-rng.c
@@ -143,7 +143,6 @@ static struct platform_driver pic32_rng_driver = {
.remove = pic32_rng_remove,
.driver = {
.name = "pic32-rng",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(pic32_rng_of_match),
},
};
--
2.9.2
^ permalink raw reply related
* Re: [PATCH v6 0/5] /dev/random - a new approach
From: Stephan Mueller @ 2016-08-16 5:45 UTC (permalink / raw)
To: H. Peter Anvin
Cc: herbert, Ted Tso, sandyinchina, Jason Cooper, John Denker,
Joe Perches, Pavel Machek, George Spelvin, linux-crypto,
linux-kernel
In-Reply-To: <2c3286c8-7150-12db-937d-b6407d50d748@linux.intel.com>
Am Montag, 15. August 2016, 13:42:54 CEST schrieb H. Peter Anvin:
Hi H,
> On 08/11/16 05:24, Stephan Mueller wrote:
> > * prevent fast noise sources from dominating slow noise sources
> >
> > in case of /dev/random
>
> Can someone please explain if and why this is actually desirable, and if
> this assessment has been passed to someone who has actual experience
> with cryptography at the professional level?
There are two motivations for that:
- the current /dev/random is compliant to NTG.1 from AIS 20/31 which requires
(in brief words) that entropy comes from auditible noise sources. Currently in
my LRNG only RDRAND is a fast noise source which is not auditible (and it is
designed to cause a VM exit making it even harder to assess it). To make the
LRNG to comply with NTG.1, RDRAND can provide entropy but must not become the
sole entropy provider which is the case now with that change.
- the current /dev/random implementation follows the same concept with the
exception of 3.15 and 3.16 where RDRAND was not rate-limited. In later
versions, this was changed.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v6 0/5] /dev/random - a new approach
From: H. Peter Anvin @ 2016-08-15 20:42 UTC (permalink / raw)
To: Stephan Mueller, herbert, Ted Tso
Cc: sandyinchina, Jason Cooper, John Denker, Joe Perches,
Pavel Machek, George Spelvin, linux-crypto, linux-kernel
In-Reply-To: <4723196.TTQvcXsLCG@positron.chronox.de>
On 08/11/16 05:24, Stephan Mueller wrote:
> * prevent fast noise sources from dominating slow noise sources
> in case of /dev/random
Can someone please explain if and why this is actually desirable, and if
this assessment has been passed to someone who has actual experience
with cryptography at the professional level?
-hpa
^ permalink raw reply
* Re: [PATCH v6 0/5] /dev/random - a new approach
From: Theodore Ts'o @ 2016-08-15 15:00 UTC (permalink / raw)
To: Stephan Mueller
Cc: herbert, sandyinchina, Jason Cooper, John Denker, H. Peter Anvin,
Joe Perches, Pavel Machek, George Spelvin, linux-crypto,
linux-kernel
In-Reply-To: <1756772.RGD5U4JGHJ@tauon.atsec.com>
On Mon, Aug 15, 2016 at 08:13:06AM +0200, Stephan Mueller wrote:
>
> According to my understanding of NAPI, the network card sends one interrupt
> when receiving the first packet of a packet stream and then the driver goes
> into polling mode, disabling the interrupt. So, I cannot see any batching
> based on some on-board timer where add_interrupt_randomness is affected.
>
> Can you please elaborate?
>From https://wiki.linuxfoundation.org/networking/napi:
NAPI (“New API”) is an extension to the device driver packet
processing framework, which is designed to improve the performance
of high-speed networking. NAPI works through:
* Interrupt mitigation
* High-speed networking can create thousands of interrupts per
second, all of which tell the system something it already knew:
it has lots of packets to process. NAPI allows drivers to run
with (some) interrupts disabled during times of high traffic,
with a corresponding decrease in system load.
...
The idea is to mitigate the CPU load from having a large number of
interrupts. Spinning in a tight loop, wihch is what polling odoes,
doesn't help reduce the CPU load. So it's *not* what you would want
to do on a small-count core CPU, or on a bettery operated device.
What you're thinking about is a technique to reduce interrupt latency,
which might be useful on a 32-core server CPU where trading off power
consumption for interrupt latency makes sense. But NAPI is the exact
reverese thing --- it trades interrupt latency for CPU and power
efficiency.
NAPI in its traditional works by having the interrupt card *not* send
an interrupt after the packet comes in, and instead accumulate packets
in a buffer. The interupt only gets sent after an short timeout, or
when the on-NIC buffer is in danger of filling. As a result, when
interrupts get sent might be granularized based on some clock --- and
on small systems, there may only be a single CPU on that clock.
> Well, injecting a trojan to a system in user space as unprivileged user that
> starts some X11 session and that can perform the following command is all you
> need to get to the key commands of the console.
>
> xinput list | grep -Po 'id=\K\d+(?=.*slave\s*keyboard)' | xargs -P0 -n1
> xinput test
>
> That is fully within reach of not only some agencies but also other folks. It
> is similar for mice.
This doesn't result in keyboard and mice interrupts, which is how
add_input_randomness() works. So it's mostly irrelevant.
> When you refer to my Jitter RNG, I think I have shown that its strength comes
> from the internal state of the CPU (states of the internal building blocks
> relative to each other which may cause internal wait states, state of branch
> prediction or pipelines, etc.) and not of the layout of the CPU.
All of this is deterministic. Just as AES_ENCRPT(NSA_KEY, COUNTER++)
is completely deterministic and dependant on the internal state of the
PRNG. But it's not random, and if you don't know NSA_KEY you can't
prove that it's not really random.
> On VMs, the add_disk_randomness is always used with the exception of KVM when
> using a virtio disk. All other VMs do not use virtio and offer the disk as a
> SCSI or IDE device. In fact, add_disk_randomness is only disabled when the
> kernel detects:
>
> - SDDs
>
> - virtio
>
> - use of device mapper
AWS uses para-virtualized SCSI; Google Compute Engine uses
virtio-SCSI. So the kernel should know that these are virtual
devices, and I'd argue that if we're setting the add_random flag, we
shouldn't be.
> > As far as whether you can get 5-6 bits of entropy from interrupt
> > timings --- that just doesn't pass the laugh test. The min-entropy
>
> May I ask what you find amusing? When you have a noise source for which you
> have no theoretical model, all you can do is to revert to statistical
> measurements.
So tell me, how much "minimum", "conservative" entropy do the non-IID
tests report when fed as input AES_ENCRYPT*NSA_KEY, COUNTER++)?
Sometimes, laughing is better than crying. :-)
> Just see the guy that sent an email to linux-crypto today. His MIPS /dev/
> random cannot produce 16 bytes of data within 4 hours (which is similar to
> what I see on POWER systems). This raises a very interesting security issue: /
> dev/urandom is not seeded properly. And we all know what folks do in the wild:
> when /dev/random does not produce data, /dev/urandom is used -- all general
> user space libs (OpenSSL, libgcrypt, nettle, ...) seed from /dev/urandom per
> default.
>
> And I call that a very insecure state of affairs.
Overestimating entropy that isn't there doesn't actually make things
more secure. It just makes people feel better. This is especially
true if the goal is declare the /dev/urandom to be fully initialized
before userspace is started. So if the claim is that your "LRNG" can
fully initialize the /dev/urandom pool, and it's using fundamentally
using the same interrupt sampling techniques as what is currently in
the kernel, then there is no substantive difference in security
between using /dev/urandom and using /dev/urandom with your patches
applied and enabled.
In the case of MIPS it doesn't have a high resolution timer, so it
*will* have less entropy that it can gather using interrupts compared
to an x86 system. So i'd much rather be very conservative and
encourage people to use a CPU that *does* have a high resolution timer
or a hardware random number generator, or use some other very
carefully seeding via the bootloader or some such, rather than lull
them into a potentially false sense of security.
> As mentioned, to my very surprise, I found that interrupts are the only thing
> in a VM that works extremely well even under attack scenarios. VMMs that I
> quantiatively tested include QEMU/KVM, VirtualBox, VMWare ESXi and Hyper-V.
> After more research, I came to the conclusion that even on the theoretical
> side, it must be one of the better noise sources in a VM.
Again, how does your quantitive tests work on AES_ENCRYPT(NSA_KEY, COUNTER++)?
> I am concerned about the *two* separate injections of 64 bits. It should
> rather be *one* injection of at least 112 bit (or 128 bits). This is what I
> mean with "atomic" operation here.
We only consider urandom/getrandom CRNG to be initialized when 2
injections happen without an intervening extract operation. If there
is an extract operation, we print a warning and then reset the
counter. So by the time /dev/urandom is initialized, it has had two
"atomic" injections of entropy. It's the same kind of atomicity which
is provided by the seqlock_t abstraction in the linux kernel.
> For example, the one key problem I have with the ChaCha20 DRNG is the
> following: when final update of the internal state is made for enhanced
> prediction resistance, ChaCha20 is used to generate one more block. That new
> block has 512 bits in size. In your implementation, you use the first 256 bits
> to inject it back into ChaCha20 as key. I use the entire 512 bits. I do not
> know whether one is better than the other (in the sense that it does not loose
> entropy). But barring any real research from other cryptographers, I guess we
> both do not know. And I have seen that such subtle issues may lead to
> catastrophic problems.
Chacha20 uses a 256-bit key, and what I'm doing is folding in 256 bits
into the ChaCha20 key. The security strength that we're claiming fom
in the SP800-90A DRBG model is 256 bits (the maximum from the
SP800-90A set of 112, 128, 192, or 256), and so I'd argue that what
I'm doing is sufficient.
Entropy doesn't really have a meaning in a DRBG, so SP800-90A wouldn't
have anything to say anything about either alternative.
Cheers,
- Ted
^ permalink raw reply
* Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Kalle Valo @ 2016-08-15 11:01 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Stephan Mueller, Ted Tso, Sepehrdad, Pouyan,
herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, ath9k-devel,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
Jason Cooper
In-Reply-To: <657897b90b8344eeab10d7a0f604988d@aptaiexm02f.ap.qualcomm.com>
"Pan, Miaoqing" <miaoqing@qti.qualcomm.com> writes:
> The entropy was evaluated by crypto expert, the analysis report show
> the ADC with at least 10bits and up to 22 bits of min-entropy for a 32
> bits value, we conservatively assume the min-entropy is 10 bits out of
> 32 bits, so that's why set entropy quality to 320/1024 = 10/32. Also
> we have explained in the commit message why can't use the HW RNG
> framework.
>
> Otherwise, your patch will cause high CPU load, as continuously read
> ADC data if entropy bits under write_wakeup_threshold.
Please don't top post, it breaks patchwork which is extremely annoying
for me:
https://patchwork.kernel.org/patch/9266265/
https://patchwork.kernel.org/patch/9266617/
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v6 0/5] /dev/random - a new approach
From: Stephan Mueller @ 2016-08-15 6:13 UTC (permalink / raw)
To: Theodore Ts'o
Cc: herbert, sandyinchina, Jason Cooper, John Denker, H. Peter Anvin,
Joe Perches, Pavel Machek, George Spelvin, linux-crypto,
linux-kernel
In-Reply-To: <20160812192208.GA30280@thunk.org>
Am Freitag, 12. August 2016, 15:22:08 CEST schrieb Theodore Ts'o:
Hi Theodore,
> On Fri, Aug 12, 2016 at 11:34:55AM +0200, Stephan Mueller wrote:
> > - correlation: the interrupt noise source is closely correlated to the
> > HID/
> > block noise sources. I see that the fast_pool somehow "smears" that
> > correlation. However, I have not seen a full assessment that the
> > correlation is gone away. Given that I do not believe that the HID event
> > values (key codes, mouse coordinates) have any entropy -- the user
> > sitting at the console exactly knows what he pressed and which mouse
> > coordinates are created, and given that for block devices, only the
> > high-resolution time stamp gives any entropy, I am suggesting to remove
> > the HID/block device noise sources and leave the IRQ noise source. Maybe
> > we could record the HID event values to further stir the pool but do not
> > credit it any entropy. Of course, that would imply that the assumed
> > entropy in an IRQ event is revalued. I am currently finishing up an
> > assessment of how entropy behaves in a VM (where I hope that the report
> > is released). Please note that contrary to my initial
> > expectations, the IRQ events are the only noise sources which are almost
> > unaffected by a VMM operation. Hence, IRQs are much better in a VM
> > environment than block or HID noise sources.
>
> The reason why I'm untroubled with leaving them in is because I beieve
> the quality of the timing information from the HID and block devices
> is better than most of the other interrupt sources. For example, most
> network interfaces these days use NAPI, which means interrupts get
> coalesced and sent in batch, which means the time of the interrupt is
> latched off of some kind of timer --- and on many embeded devices
According to my understanding of NAPI, the network card sends one interrupt
when receiving the first packet of a packet stream and then the driver goes
into polling mode, disabling the interrupt. So, I cannot see any batching
based on some on-board timer where add_interrupt_randomness is affected.
Can you please elaborate?
> there is a single oscillator for the entire mainboard. We only call
> add_disk_randomness for rotational devices (e.g., only HDD's, not
> SSD's), after the interrupt has been recorded. Yes, most of the
> entropy is probably going to be found in the high entropy time stamp
> rather than the jiffies-based timestamp, especially for the hard drive
> completion time.
>
> I also tend to take a much more pragmatic viewpoint towards
> measurability. Sure, the human may know what she is typing, and
> something about when she typed it (although probably not accurately
> enough on a millisecond basis, so even the jiffies number is going to
> be not easily predicted), but the analyst sitting behind the desk at
> the NSA or the BND or the MSS is probably not going to have access to
> that information.
Well, injecting a trojan to a system in user space as unprivileged user that
starts some X11 session and that can perform the following command is all you
need to get to the key commands of the console.
xinput list | grep -Po 'id=\K\d+(?=.*slave\s*keyboard)' | xargs -P0 -n1
xinput test
That is fully within reach of not only some agencies but also other folks. It
is similar for mice.
>
> (Whereas the NSA or the BND probably *can* get low-level information
> about the Intel x86 CPU's internal implementation, which is why I'm
> extremely amused by the arugment --- "the internals of the Intel CPU
> are **so** complex we can't reverse engineer what's going on inside,
> so the jitter RNG *must* be good!" Note BTW that the NSA has only
Sure, agencies may know the full internals of a CPU like they know the full
internals of the Linux kernel with the /dev/random implementation or just like
they know the full internals of AES. But they do not know the current state of
the system. And the cryptographic strength comes from that state.
When you refer to my Jitter RNG, I think I have shown that its strength comes
from the internal state of the CPU (states of the internal building blocks
relative to each other which may cause internal wait states, state of branch
prediction or pipelines, etc.) and not of the layout of the CPU.
> said they won't do industrial espionage for economic for economic
> gain, not that they won't engage in espionage against industrial
> entities at all. This is why the NSA spying on Petrobras is
> considered completely fair game, even if it does enrage the
> Brazillians. :-)
>
> > - entropy estimate: the current entropy heuristics IMHO have nothing to do
> > with the entropy of the data coming in. Currently, the min of
> > first/second/
> > third derivative of the Jiffies time stamp is used and capped at 11. That
> > value is the entropy value credited to the event. Given that the entropy
> > rests with the high-res time stamp and not with jiffies or the event
> > value, I think that the heuristic is not helpful. I understand that it
> > underestimates on average the available entropy, but that is the only
> > relationship I see. In my mentioned entropy in VM assessment (plus the
> > BSI report on /dev/random which is unfortunately written in German, but
> > available in the Internet) I did a min entropy calculation based on
> > different min entropy formulas (SP800-90B). That calculation shows that
> > we get from the noise sources is about 5 to 6 bits. On average the
> > entropy heuristic credits between 0.5 and 1 bit for events, so it
> > underestimates the entropy. Yet, the entropy heuristic can credit up to
> > 11 bits. Here I think it becomes clear that the current entropy heuristic
> > is not helpful. In addition, on systems where no high-res timer is
> > available, I assume (I have not measured it yet), the entropy heuristic
> > even overestimates the entropy.
>
> The disks on a VM are not rotational disks, so we wouldn't be using
> the add-disk-randomness entropy calculation. And you generally don't
> have a keyboard on a mouse attached to the VM, so we would be using
> the entropy estimate from the interrupt timing.
On VMs, the add_disk_randomness is always used with the exception of KVM when
using a virtio disk. All other VMs do not use virtio and offer the disk as a
SCSI or IDE device. In fact, add_disk_randomness is only disabled when the
kernel detects:
- SDDs
- virtio
- use of device mapper
(Btw we should be thankful that this is done on Hyper-V as we would have a
fatal state in a very common use case where /dev/random would have collected
no entropy and /dev/urandom would have provided bogus data before the patch
for using the VMBus interrupts was added.)
>
> As far as whether you can get 5-6 bits of entropy from interrupt
> timings --- that just doesn't pass the laugh test. The min-entropy
May I ask what you find amusing? When you have a noise source for which you
have no theoretical model, all you can do is to revert to statistical
measurements.
> formulas are estimates assuming IID data sources, and it's not at all
> clear (in fact, i'd argue pretty clearly _not_) that they are IID. As
Sure, they are not IID based on the SP800-90B IID verification tests. For
that, SP800-90B has non-IID versions of the min entropy calculations. See
section 9.1 together with 9.3 of SP800-90B where I used those non-IID
formulas.
Sure, it is "just" some statistical test. But it is better IMHO than to brush
away available entropy entirely just because "my stomach tells me it is not
good".
Just see the guy that sent an email to linux-crypto today. His MIPS /dev/
random cannot produce 16 bytes of data within 4 hours (which is similar to
what I see on POWER systems). This raises a very interesting security issue: /
dev/urandom is not seeded properly. And we all know what folks do in the wild:
when /dev/random does not produce data, /dev/urandom is used -- all general
user space libs (OpenSSL, libgcrypt, nettle, ...) seed from /dev/urandom per
default.
And I call that a very insecure state of affairs.
> I said, take for example the network interfaces, and how NAPI gets
As mentioned above, I do not see NAPI as an issue for interrupt entropy.
> implemented. And in a VM environment, where everything is synthetic,
> the interrupt timings are definitely not IID, and there may be
> patterns that will not detectable by statistical mechanisms.
As mentioned, to my very surprise, I found that interrupts are the only thing
in a VM that works extremely well even under attack scenarios. VMMs that I
quantiatively tested include QEMU/KVM, VirtualBox, VMWare ESXi and Hyper-V.
After more research, I came to the conclusion that even on the theoretical
side, it must be one of the better noise sources in a VM.
Note, this was the key motivation for me to start my own implementation of /
dev/random.
>
> > - albeit I like the current injection of twice the fast_pool into the
> > ChaCha20 (which means that the pathological case where the collection of
> > 128 bits of entropy would result in an attack resistance of 2 * 128 bits
> > and *not* 2^128 bits is now increased to an attack strength of 2^64 * 2
> > bits), / dev/urandom has *no* entropy until that injection happens. The
> > injection happens early in the boot cycle, but in my test system still
> > after user space starts. I tried to inject "atomically" (to not fall into
> > the aforementioned pathological case trap) of 32 / 112 / 256 bits of
> > entropy into the /dev/ urandom RNG to have /dev/urandom at least seeded
> > with a few bits before user space starts followed by the atomic injection
> > of the subsequent bits.
> The early boot problem is a hard one. We can inject some noise in,
> but I don't think a few bits actually does much good. So the question
> is whether it's faster to get to fully seeded, or to inject in 32 bits
I am not talking about the 32 bits. We can leave the current 64 bits for the
first seed.
I am concerned about the *two* separate injections of 64 bits. It should
rather be *one* injection of at least 112 bit (or 128 bits). This is what I
mean with "atomic" operation here.
> of entropy in the hopes that this will do some good. Personally, I'm
> not convinced. So the tack I've taken is to have warning messages
> printed when someone *does* draw from /dev/urandom before it's fully
> seeded. In many cases, it's for entirely bogus, non-cryptographic
> reasons. (For example, Python wanting to use a random salt to protect
> against certain DOS attacks when Python is being used in a web server
> --- a use case which is completely irrelevant when it's being used by
> systemd generator scripts at boot time.)
>
> Ultimately, I think the right answer here is we need help from the
> bootloader, and ultimately some hardware help or some initialization
> at factory time which isn't too easily hacked by a Tailored Access
> Organization team who can intercept hardware shipments. :-)
I agree. But we can still try to make the Linux side good as possible to cover
people who do not have the luxury to control the hardware.
>
[...]
>
> > Finally, one remark which I know you could not care less: :-)
> >
> > I try to use a known DRNG design that a lot of folks have already assessed
> > -- SP800-90A (and please, do not hint to the Dual EC DRBG as this issue
> > was pointed out already by researcher shortly after the first SP800-90A
> > came out in 2007). This way I do not need to re-invent the wheel and
> > potentially forget about things that may be helpful in a DRNG. To allow
> > researchers to assess my ChaCha20 DRNG. that used when no kernel crypto
> > API is compiled. independently from the kernel, I extracted the ChaCha20
> > DRNG code into a standalone DRNG accessible at [1]. This standalone
> > implementation can be debugged and studied in user space. Moreover it is
> > a simple copy of the kernel code to allow researchers an easy comparison.
>
> SP800-90A consists of a high level architecture of a DRBG, plus some
> lower-level examples of how to use that high level architecture
> assuming you have a hash function, or a block cipher, etc. But it
> doesn't have an example on using a stream cipher like ChaCha20. So
> all you can really do is follow the high-level architecture. Mapping
> the high-level architecture to the current /dev/random generator isn't
> hard. And no, I don't see the point of renaming things or moving
> things around just to make the mapping to the SP800-90A easier.
Unfortunately I have seen subtle problems with DRNG implementations -- and a
new one will emerge in the not too far future... There are examples of that
and I like tests against reference implementations.
For example, the one key problem I have with the ChaCha20 DRNG is the
following: when final update of the internal state is made for enhanced
prediction resistance, ChaCha20 is used to generate one more block. That new
block has 512 bits in size. In your implementation, you use the first 256 bits
to inject it back into ChaCha20 as key. I use the entire 512 bits. I do not
know whether one is better than the other (in the sense that it does not loose
entropy). But barring any real research from other cryptographers, I guess we
both do not know. And I have seen that such subtle issues may lead to
catastrophic problems.
Thus, knowing valid DRNG designs may cover 99% of a new DRNG design. But the
remaining 1% usually gives you the creeps.
Ciao
Stephan
^ permalink raw reply
* Re: JZ4780 RNG and entropy depletion
From: Stephan Mueller @ 2016-08-15 4:58 UTC (permalink / raw)
To: noloader; +Cc: linux-crypto
In-Reply-To: <CAH8yC8=S7ZaK9o+VCjRrpF0gNwTEL9a-SfQmFkjt97j6h34kBw@mail.gmail.com>
Am Sonntag, 14. August 2016, 01:33:32 CEST schrieb Jeffrey Walton:
Hi Jeffrey,
> Hi Everyone,
>
> I have a MIPSEL ci20 dev board for testing. The board has a hardware
> based rng, but its suffering entropy depletion. I have Debian's
> rng-tools package installed.
>
> The board lacks /dev/hwrng. /dev/random blocks indefinitely after
> draining the device. "Indefinitely" may not be accurate, but I killed
> a program that waited over 4 hours for 16 bytes after draining
> /dev/random.
>
> The ci20's documentation is a bit scant, but it can be found at
> http://mipscreator.imgtec.com/CI20/hardware/soc/JZ4780_PM.pdf. I'm not
> sure what the output rate is, but it seems to be capable of one
> machine word (4 bytes) every few milliseconds. Without a delay, I can
> see values being shifted into the register mapped at 0x100000DC.
>
> I have a few questions:
>
> * Is there a driver for JZ4780 rng?
What is the PCI ID?
> * Is there a particular package for the driver that needs to be installed?
> * What causes/triggers /dev/hwrng to replenish /dev/random?
Using rngd which is triggered by /dev/random automatically when its entropy
level falls below a threshold.
Ciao
Stephan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox