* 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: 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 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: 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
* [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
* 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
* 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
* 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 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: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: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: 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
* [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: [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
* 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 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 -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] 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] 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] 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
* [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 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
* 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: Stephan Mueller @ 2016-08-17 5:21 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: <2f43d23f-5fbe-9653-fc1c-489db1c7bde4@linux.intel.com>
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
^ permalink raw reply
* Re: [Patch-V2 2/3] chcr: Support for Chelsio's Crypto Hardware
From: Hariprasad Shenai @ 2016-08-17 5:51 UTC (permalink / raw)
To: David Miller
Cc: yeshaswi, netdev, linux-kernel, linux-crypto, jlulla, harsh,
atul.gupta, herbert
In-Reply-To: <20160719.211522.465417746785662817.davem@davemloft.net>
On Tue, Jul 19, 2016 at 09:15:22PM -0700, David Miller wrote:
> From: Yeshaswi M R Gowda <yeshaswi@chelsio.com>
> Date: Mon, 18 Jul 2016 22:42:14 -0700
>
> > +config CRYPTO_DEV_CHELSIO
> > + tristate "Chelsio Crypto Co-processor Driver"
> > + depends on PCI && NETDEVICES && ETHERNET
> > + select CRYPTO_SHA1
> > + select CRYPTO_SHA256
> > + select CRYPTO_SHA512
> > + select NET_VENDOR_CHELSIO
> > + select CHELSIO_T4
>
> The user shouldn't have to know about the technical details about
> how this chip is physically implemented.
>
> It's therefore not reasonable to require an ethernet driver to be
> enabled to use the crypto engine.
>
> Also, selecting Kconfig symbol X does not recursively enable the
> "select" statement(s) of symbol X nor does it check symbol X's
> dependencies.
>
> This is really one big huge dependency mess, and I think you have
> to split out the core of the T4 driver into a driver subtype
> agnostic library or similar to make this work properly.
>
> Don't just shoehorn this stuff into the ethernet driver. Round
> peg, square hole.
>
Hi David,
We looked at the interface exposed by the current Ethernet driver and
how other drivers/protocols use that for exchanging control/data with
hardware. The cxgb4 driver is more than a Ethernet driver, it also
initializes the hardware so that other protocols can use them.
We have a terminology called lower level driver(LLD) and
Upper level driver(ULD). The lower level driver, which is cxgb4 acts
both as Ethernet driver and enables the hardware resources for ULD.
The ULD's such as iSCSI/iWARP/Crypto depends on lower level driver for the
initializied harware resources before processing the protocol specific part.
In v3 series of patch we have introduced common API framework for upper
level drivers to use the hardware resources. At present, all resouces are
allocated statically, no matter whether ULD is loaded or not. With the new
framework, all allocations and initialization for respective ULD's are done,
when they register with the LLD and freed when unregistered.
The ULD API framework makes the interface flexible and scalable for any new
driver which shall run on top of cxgb4. The v3 patch uses the new ULD APIs
introduced by cxgb4 only for crypto, and shall be extended further for
iSCSI and iWARP in upcoming series. The API also saves new driver(ULD) from
exclusively requesting the PCI function and manage the resources associated.
Thanks,
Hari
^ 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