Re: [PATCH v6 0/5] /dev/random - a new approach

2016-08-16 Thread Stephan Mueller 
Am Dienstag, 16. August 2016, 15:28:45 CEST schrieb H. Peter Anvin:

Hi Peter,

> > 
> > 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.

It is not about the limiting of the data. It is all about the entropy estimate 
for those noise sources and how they affect the entropy estimator behind /dev/
random. If that fast noise source injects large amount of data but does not 
increase the entropy estimator, it is of no concern.

Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 0/5] /dev/random - a new approach

2016-08-16 Thread H. Peter Anvin 
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

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 0/5] /dev/random - a new approach

2016-08-16 Thread H. Peter Anvin 
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


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 linux-next] hwrng: update Freescale i.MX RNGA Random Number Generator

2016-08-16 Thread Fabian Frederick 
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 
---
-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

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwrng-PIC32: Delete unnecessary assignment for the field "owner"

2016-08-16 Thread Herbert Xu 
On Tue, Aug 16, 2016 at 08:04:11AM +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> 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 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: fix ctx pointer in sha512-mb

2016-08-16 Thread Herbert Xu 
On Fri, Aug 12, 2016 at 06:28:31AM -0400, Xiaodong Liu wrote:
> Signed-off-by: Xiaodong Liu 

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 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: DRBG: do not call drbg_instantiate in healt test

2016-08-16 Thread Herbert Xu 
Stephan Mueller  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 
> Signed-off-by: Stephan Mueller 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: fix a little typo

2016-08-16 Thread Herbert Xu 
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 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH -next] crypto: ccp - Fix non static symbol warning

2016-08-16 Thread Herbert Xu 
On Fri, Aug 12, 2016 at 12:00:09AM +, 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 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: fix ctx pointer and digest copy in sha256-mb

2016-08-16 Thread Herbert Xu 
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 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/6] crypto: sun4i-ss: fix a few signed warning

2016-08-16 Thread Herbert Xu 
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 

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] crypto: XTS - remove test that will fail in FIPS mode

2016-08-16 Thread Stephan Mueller 
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 
Signed-off-by: Stephan Mueller 
---
 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


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RSA key size not allowed in FIPS

2016-08-16 Thread Stephan Mueller 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function

2016-08-16 Thread Herbert Xu 
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 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function

2016-08-16 Thread Stephan Mueller 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function

2016-08-16 Thread Herbert Xu 
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 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function

2016-08-16 Thread Stephan Mueller 
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 
> 
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function

2016-08-16 Thread Herbert Xu 
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 

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 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Crypto Fixes for 4.8

2016-08-16 Thread Herbert Xu 
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 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] hwrng-PIC32: Delete unnecessary assignment for the field "owner"

2016-08-16 Thread SF Markus Elfring 
From: Markus Elfring 
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 
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html