* Re: [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
From: Ard Biesheuvel @ 2016-12-28 19:50 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20161228092328.GA12494@gondor.apana.org.au>
On 28 December 2016 at 09:23, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Dec 28, 2016 at 09:19:32AM +0000, Ard Biesheuvel wrote:
>>
>> Ok, so that implies a field in the skcipher algo struct then, rather than some definition internal to the driver?
>
> Oh yes it should definitely be visible to other crypto API drivers
> and algorithms. It's just that we don't want to export it outside
> of the crypto API, e.g., to IPsec or algif.
>
Understood.
So about this chunksize, is it ever expected to assume other values
than 1 (for stream ciphers) or the block size (for block ciphers)?
Having block size, IV size *and* chunk size fields may be confusing to
some already, so if the purpose of chunk size can be fulfilled by a
single 'stream cipher' flag, perhaps we should change that first.
^ permalink raw reply
* [ANNOUNCE] /dev/random - a new approach (code for 4.10-rc1)
From: Stephan Müller @ 2016-12-28 17:17 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-crypto
Hi,
The patch set that can be downloaded at [1] provides a different approach to /
dev/random which I call Linux Random Number Generator (LRNG) to collect
entropy within the Linux kernel. The main improvements compared to the legacy
/dev/random is to provide sufficient entropy during boot time as well as in
virtual environments and when using SSDs or Device Mapper targets. A secondary
design goal is to limit the impact of the entropy collection on massive
parallel systems and also allow the use accelerated cryptographic primitives.
Also, all steps of the entropic data processing are testable. Finally
performance improvements are visible at /dev/urandom and get_random_bytes.
The design and implementation is driven by a set of goals described in [2]
that the LRNG completely implements. Furthermore, [2] includes a
comparison with RNG design suggestions such as SP800-90B, SP800-90C, and
AIS20/31.
[1] http://www.chronox.de/lrng.html
[2] http://www.chronox.de/lrng/doc/lrng.pdf
Ciao
Stephan
^ permalink raw reply
* Re: simd ciphers
From: Stephan Müller @ 2016-12-28 11:21 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20161228102826.GB12607@gondor.apana.org.au>
Am Mittwoch, 28. Dezember 2016, 18:28:26 CET schrieb Herbert Xu:
Hi Herbert,
> On Wed, Dec 28, 2016 at 11:00:51AM +0100, Stephan Müller wrote:
> > When I configure AES-NI as module, it works. When compiling it statically,
> > the allocation returns an -ENOENT.
> >
> > Now, when I diff both config files after a simple toggle from AES-NI=y to
> > =m I see (linux-4.10.config contains the static config, .config contains
> > the module
> > configuration):
> Thanks Stephan! Does this patch help?
This patch does not help. But I now found the issue: we need some Kconfig
wizardry to mandate pcbc to be compiled statically when AES-NI is static.
Currently I had pcbc always as a module even when selecting AES-NI as static
compilation.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] crypto: qat - initialize cra_flags before register into kpp
From: Herbert Xu @ 2016-12-28 10:12 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: linux-crypto, giovanni.cabiddu, Sushil Kumar
In-Reply-To: <20161222150051.6284-1-giovanni.cabiddu@intel.com>
On Thu, Dec 22, 2016 at 03:00:51PM +0000, Giovanni Cabiddu wrote:
> Initialize dh.base.cra_flags before registering the dh algorithm.
> Without this fix, the registration of the dh algorithm might fail
> if the qat driver is restarted.
>
> Signed-off-by: Sushil Kumar <sushilx.kumar@intel.com>
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Please patch the crypto API instead. I think unsetting the bit
CRYPTO_ALG_DEAD at the top of crypto_register_alg should do the
trick.
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: simd ciphers
From: Herbert Xu @ 2016-12-28 10:28 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <3170771.4e7c0aHuJX@positron.chronox.de>
On Wed, Dec 28, 2016 at 11:00:51AM +0100, Stephan Müller wrote:
>
> When I configure AES-NI as module, it works. When compiling it statically, the
> allocation returns an -ENOENT.
>
> Now, when I diff both config files after a simple toggle from AES-NI=y to =m I
> see (linux-4.10.config contains the static config, .config contains the module
> configuration):
Thanks Stephan! Does this patch help?
---8<---
Subject: crypto: pcbc - Move pcbc registration up to subsys_initcall
The pcbc template is required by aesni. As aesni registers itself
at late_initcall, we have to make sure pcbc is registered before
that.
This patch moves it to subsys_initcall like cryptd.
Fixes: 85671860caac ("crypto: aesni - Convert to skcipher")
Reported-by: Stephan Müller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/pcbc.c b/crypto/pcbc.c
index e4538e0..0855c61 100644
--- a/crypto/pcbc.c
+++ b/crypto/pcbc.c
@@ -307,7 +307,7 @@ static void __exit crypto_pcbc_module_exit(void)
crypto_unregister_template(&crypto_pcbc_tmpl);
}
-module_init(crypto_pcbc_module_init);
+subsys_initcall(crypto_pcbc_module_init);
module_exit(crypto_pcbc_module_exit);
MODULE_LICENSE("GPL");
--
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 related
* Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)
From: George Spelvin @ 2016-12-28 10:04 UTC (permalink / raw)
To: daniel, hannes, linux
Cc: ak, davem, David.Laight, ebiggers3, eric.dumazet, Jason,
kernel-hardening, linux-crypto, linux-kernel, luto, netdev, tom,
tytso, vegard.nossum
In-Reply-To: <1482902602.2234.1.camel@stressinduktion.org>
Hannes Frederic Sowa wrote:
> We call extract_crng when we run out of batched entropy and reseed. How
> often we call down to extract_crng depends on how much entropy we
> extracted by calls to get_random_int/long, so the number of calls into
> those functions matter.
>
> In extract_crng we have a timer which reseeds every 300s the CPRNG and
> either uses completely new entropy from the CRNG or calls down into the
> CPRNG while also doing backtracing protection (which feeds chacha's
> block size / 2 back into chacha, if I read the code correctly, thus
> 1024 bits, which should be enough).
In the current code, _extract_crng checks to see if more than 300 s
have elapsed since last time it was reseeded, and if so, reseeds with
fresh entropy.
In addition, on every read (or get_random_bytes), if the request leaves
enough ranfom bits in the last ChaCha block, it feeds back 256 bits
(the ChaCha block size is 16*32 = 512 bits) for anti-backtracking.
If the last read happened to not fit under that limit (size % 512 >
256), *and* there are no calls for RNG output for a long time, there is
no upper limit to how long the old ChaCha key can hang around.
> On Fri, 2016-12-23 at 20:17 -0500, George Spelvin wrote:
>> For example, two mix-backs of 64 bits gives you 65 bit security, not 128.
>> (Because each mixback can be guessed and verified separately.)
> Exactly, but the full reseed after running out of entropy is strong
> enough to not be defeated by your argumentation. Neither the reseed
> from the CRNG.
Yes, I was just reacting to your original statement:
>>>>> couldn't we simply use 8 bytes of the 64 byte
>>>>> return block to feed it directly back into the state chacha?
It's not the idea that's bad, just the proposed quantity.
>> If you want that, I have a pile of patches to prandom I really
>> should push upstream. Shall I refresh them and send them to you?
> I would like to have a look at them in the new year, certainly! I can
> also take care about the core prandom patches, but don't know if I have
> time to submit the others to the different subsystems.
>
> Maybe, if David would be okay with that, we can submit all patches
> through his tree, as he is also the dedicated maintainer for prandom.
Amazing, thank you very much! They're just minor cleanups, nothing
too exciting. I'll put it in the queue to make sure they're up to
date.
^ permalink raw reply
* Re: simd ciphers
From: Stephan Müller @ 2016-12-28 10:00 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20161228085938.GA11904@gondor.apana.org.au>
Am Mittwoch, 28. Dezember 2016, 16:59:38 CET schrieb Herbert Xu:
Hi Herbert,
> > With 4.10-rc1, I also do not get the AES-NI implementations to work. do
> > you
> > have any ideas what may be the issue?
>
> I'm having problems reproducing this. Does it work for you if you
> build them as modules?
When I configure AES-NI as module, it works. When compiling it statically, the
allocation returns an -ENOENT.
Now, when I diff both config files after a simple toggle from AES-NI=y to =m I
see (linux-4.10.config contains the static config, .config contains the module
configuration):
$ diff -urN ../linux-4.10.config .config
--- ../linux-4.10.config 2016-12-28 10:56:51.805526584 +0100
+++ .config 2016-12-28 11:00:17.959608195 +0100
@@ -4062,8 +4062,8 @@
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_TEST=m
CONFIG_CRYPTO_ABLK_HELPER=m
-CONFIG_CRYPTO_SIMD=y
-CONFIG_CRYPTO_GLUE_HELPER_X86=y
+CONFIG_CRYPTO_SIMD=m
+CONFIG_CRYPTO_GLUE_HELPER_X86=m
#
# Authenticated Encryption with Associated Data
@@ -4132,7 +4132,7 @@
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=y
-CONFIG_CRYPTO_AES_NI_INTEL=y
+CONFIG_CRYPTO_AES_NI_INTEL=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
Ciao
Stephan
^ permalink raw reply
* Re: simd ciphers
From: Herbert Xu @ 2016-12-28 8:59 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <1497014.RmdRyQUAOo@positron.chronox.de>
On Wed, Dec 28, 2016 at 09:37:04AM +0100, Stephan Müller wrote:
> Am Donnerstag, 8. Dezember 2016, 19:40:38 CET schrieb Stephan Müller:
>
> Hi Herbert,
>
> > Am Donnerstag, 8. Dezember 2016, 19:32:03 CET schrieb Stephan Müller:
> >
> > Hi Herbert,
> >
> > > Hi Herbert,
> > >
> > > with the addition of the simd cipher change I seem to be unable to use the
> > > AESNI ciphers. My .config contains CONFIG_CRYPTO_SIMD=y and
> > > CONFIG_CRYPTO_AES_NI_INTEL=y. Those options always worked to load the
> > > AES-NI
> > (with "always worked" I meant the CONFIG_CRYPTO_AES_NI_INTEL=y option of
> > course, that always ensured AES-NI to be present and usable)
>
> With 4.10-rc1, I also do not get the AES-NI implementations to work. do you
> have any ideas what may be the issue?
I'm having problems reproducing this. Does it work for you if you
build them as modules?
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 v2 1/3] crypto: chacha20 - convert generic and x86 versions to skcipher
From: Herbert Xu @ 2016-12-28 9:25 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto, linux-arm-kernel
In-Reply-To: <C46A3CDE-2329-4171-B4C5-071423EC3B4B@linaro.org>
On Wed, Dec 28, 2016 at 09:23:07AM +0000, Ard Biesheuvel wrote:
>
> Ehm, could you keep this one and revert the other two instead please? This patch will not change in the respin, and the other two are blkciphers rather than skciphers (and in the arm64 version, I optimized the asm code as well) so they will look rather different ( as they do in the nacked v2)
OK I will keep this patch and revert the other two.
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: arm/aes-neonbs - process 8 blocks in parallel if we can
From: Herbert Xu @ 2016-12-28 9:23 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <B32240B5-953F-42A2-A010-6FF64AC45859@linaro.org>
On Wed, Dec 28, 2016 at 09:19:32AM +0000, Ard Biesheuvel wrote:
>
> Ok, so that implies a field in the skcipher algo struct then, rather than some definition internal to the driver?
Oh yes it should definitely be visible to other crypto API drivers
and algorithms. It's just that we don't want to export it outside
of the crypto API, e.g., to IPsec or algif.
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 v2 1/3] crypto: chacha20 - convert generic and x86 versions to skcipher
From: Ard Biesheuvel @ 2016-12-28 9:23 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, linux-arm-kernel
In-Reply-To: <20161228091801.GA12318@gondor.apana.org.au>
> On 28 Dec 2016, at 09:18, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
>> On Tue, Dec 27, 2016 at 06:04:52PM +0800, Herbert Xu wrote:
>>> On Fri, Dec 09, 2016 at 02:33:51PM +0000, Ard Biesheuvel wrote:
>>> This converts the ChaCha20 code from a blkcipher to a skcipher, which
>>> is now the preferred way to implement symmetric block and stream ciphers.
>>>
>>> This ports the generic and x86 versions at the same time because the
>>> latter reuses routines of the former.
>>>
>>> Note that the skcipher_walk() API guarantees that all presented blocks
>>> except the final one are a multiple of the chunk size, so we can simplify
>>> the encrypt() routine somewhat.
>>>
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>
>> Patch applied. Thanks.
>
> I'm reverting this patch because it breaks the build on ARM without
> the two subsequent patches.
>
> When resubmitting please make sure that the kernel can build and
> work after each patch. Otherwise git bisections will fail.
>
Ehm, could you keep this one and revert the other two instead please? This patch will not change in the respin, and the other two are blkciphers rather than skciphers (and in the arm64 version, I optimized the asm code as well) so they will look rather different ( as they do in the nacked v2)
> --
> 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 v2 1/3] crypto: chacha20 - convert generic and x86 versions to skcipher
From: Herbert Xu @ 2016-12-28 9:20 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto, linux-arm-kernel
In-Reply-To: <20161228091801.GA12318@gondor.apana.org.au>
On Wed, Dec 28, 2016 at 05:18:01PM +0800, Herbert Xu wrote:
> On Tue, Dec 27, 2016 at 06:04:52PM +0800, Herbert Xu wrote:
> > On Fri, Dec 09, 2016 at 02:33:51PM +0000, Ard Biesheuvel wrote:
> > > This converts the ChaCha20 code from a blkcipher to a skcipher, which
> > > is now the preferred way to implement symmetric block and stream ciphers.
> > >
> > > This ports the generic and x86 versions at the same time because the
> > > latter reuses routines of the former.
> > >
> > > Note that the skcipher_walk() API guarantees that all presented blocks
> > > except the final one are a multiple of the chunk size, so we can simplify
> > > the encrypt() routine somewhat.
> > >
> > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >
> > Patch applied. Thanks.
>
> I'm reverting this patch because it breaks the build on ARM without
> the two subsequent patches.
>
> When resubmitting please make sure that the kernel can build and
> work after each patch. Otherwise git bisections will fail.
Sorry, it only broke the build because I applied your other two
patches first.
So I'll just revert all three and it should work.
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] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
From: Ard Biesheuvel @ 2016-12-28 9:19 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20161228091020.GE11904@gondor.apana.org.au>
> On 28 Dec 2016, at 09:10, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
>> On Tue, Dec 27, 2016 at 06:35:46PM +0000, Ard Biesheuvel wrote:
>>
>> OK, I will try to hack something up.
>>
>> One thing to keep in mind though is that stacked chaining modes should
>> present the data with the same granularity for optimal performance.
>> E.g., xts(ecb(aes)) should pass 8 blocks at a time. How should this
>> requirement be incorporated according to you?
>
> xts tries to do a page at a time, which should be good enough, no?
>
Yes, if the xts chaining mode driver invokes the ecb transform with that granularity, it should be fine. Note that this is a theoretical
concern for this mode in particular, given that the bit sliced aes code implements the xts bits as well
> In general this parameter should be visible to internal API users
> such as xts so they could use it to determine how it wants to
> structure its walks.
>
Ok, so that implies a field in the skcipher algo struct then, rather than some definition internal to the driver?
> 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 v2 1/3] crypto: chacha20 - convert generic and x86 versions to skcipher
From: Herbert Xu @ 2016-12-28 9:18 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto, linux-arm-kernel
In-Reply-To: <20161227100452.GB10629@gondor.apana.org.au>
On Tue, Dec 27, 2016 at 06:04:52PM +0800, Herbert Xu wrote:
> On Fri, Dec 09, 2016 at 02:33:51PM +0000, Ard Biesheuvel wrote:
> > This converts the ChaCha20 code from a blkcipher to a skcipher, which
> > is now the preferred way to implement symmetric block and stream ciphers.
> >
> > This ports the generic and x86 versions at the same time because the
> > latter reuses routines of the former.
> >
> > Note that the skcipher_walk() API guarantees that all presented blocks
> > except the final one are a multiple of the chunk size, so we can simplify
> > the encrypt() routine somewhat.
> >
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> Patch applied. Thanks.
I'm reverting this patch because it breaks the build on ARM without
the two subsequent patches.
When resubmitting please make sure that the kernel can build and
work after each patch. Otherwise git bisections will fail.
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 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
From: Herbert Xu @ 2016-12-28 9:13 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto, linux-arm-kernel
In-Reply-To: <AA6F25FA-C998-462F-9E25-FF543BBE3EA7@linaro.org>
On Wed, Dec 28, 2016 at 09:11:03AM +0000, Ard Biesheuvel wrote:
>
> > On 28 Dec 2016, at 09:03, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> >
> >> On Tue, Dec 27, 2016 at 02:26:35PM +0000, Ard Biesheuvel wrote:
> >>
> >> You just nacked the v2 of this series (due to the chunksize/walksize) and i rewrote them as skciphers as well
> >
> > Sorry. Would you like me to revert or just send a new series
> > on top of this?
> >
>
> No worries. If you can, please drop them entirely, or revert them otherwise. I will resend after the holidays
OK I will revert. 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 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
From: Ard Biesheuvel @ 2016-12-28 9:11 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, linux-arm-kernel
In-Reply-To: <20161228090350.GD11904@gondor.apana.org.au>
> On 28 Dec 2016, at 09:03, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
>> On Tue, Dec 27, 2016 at 02:26:35PM +0000, Ard Biesheuvel wrote:
>>
>> You just nacked the v2 of this series (due to the chunksize/walksize) and i rewrote them as skciphers as well
>
> Sorry. Would you like me to revert or just send a new series
> on top of this?
>
No worries. If you can, please drop them entirely, or revert them otherwise. I will resend after the holidays
> 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: arm/aes-neonbs - process 8 blocks in parallel if we can
From: Herbert Xu @ 2016-12-28 9:10 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAKv+Gu8OkOR3Xzx=XEOWyFpo6sLiq=WQrq0SauaY0V57uYetCQ@mail.gmail.com>
On Tue, Dec 27, 2016 at 06:35:46PM +0000, Ard Biesheuvel wrote:
>
> OK, I will try to hack something up.
>
> One thing to keep in mind though is that stacked chaining modes should
> present the data with the same granularity for optimal performance.
> E.g., xts(ecb(aes)) should pass 8 blocks at a time. How should this
> requirement be incorporated according to you?
xts tries to do a page at a time, which should be good enough, no?
In general this parameter should be visible to internal API users
such as xts so they could use it to determine how it wants to
structure its walks.
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 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
From: Herbert Xu @ 2016-12-28 9:03 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto, linux-arm-kernel
In-Reply-To: <6124F827-BA28-4A3D-B05F-EBCB1323955D@linaro.org>
On Tue, Dec 27, 2016 at 02:26:35PM +0000, Ard Biesheuvel wrote:
>
> You just nacked the v2 of this series (due to the chunksize/walksize) and i rewrote them as skciphers as well
Sorry. Would you like me to revert or just send a new series
on top of this?
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: [RFC PATCH 0/3] Cavium ThunderX ZIP driver
From: Herbert Xu @ 2016-12-28 9:01 UTC (permalink / raw)
To: Challa, Mahipal
Cc: Jan Glauber, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, David S . Miller, Nair, Vishnu
In-Reply-To: <DM5PR07MB3148D87C62159523B750CD20E5690@DM5PR07MB3148.namprd07.prod.outlook.com>
On Tue, Dec 27, 2016 at 11:39:21AM +0000, Challa, Mahipal wrote:
>
> Mahipal: One major issue is, the kernel use cases to validate the Cavium ThunderX ZIP driver are "ZSWAP" and "IPComp" which are not yet supported with scomp-acomp framework.
OK I'll look into converting IPcomp.
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: xts(ecb(aes-asm))
From: Herbert Xu @ 2016-12-28 9:01 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <4308953.jQs16UQPE9@tauon.atsec.com>
On Fri, Dec 09, 2016 at 07:02:25AM +0100, Stephan Müller wrote:
> Hi Herbert,
>
> while testing the current cryptodev-2.6 tree, I noticed that instead of the
> driver name of xts(aes-asm) (which used to be there), I now see xts(ecb(aes-
> asm)).
>
> Is that intentional?
Yes this is a result of the xts template switching over to skciphers
instead of simple ciphers as its base.
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: simd ciphers
From: Stephan Müller @ 2016-12-28 8:37 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto
In-Reply-To: <10079298.uODr7IfrOJ@tauon.atsec.com>
Am Donnerstag, 8. Dezember 2016, 19:40:38 CET schrieb Stephan Müller:
Hi Herbert,
> Am Donnerstag, 8. Dezember 2016, 19:32:03 CET schrieb Stephan Müller:
>
> Hi Herbert,
>
> > Hi Herbert,
> >
> > with the addition of the simd cipher change I seem to be unable to use the
> > AESNI ciphers. My .config contains CONFIG_CRYPTO_SIMD=y and
> > CONFIG_CRYPTO_AES_NI_INTEL=y. Those options always worked to load the
> > AES-NI
> (with "always worked" I meant the CONFIG_CRYPTO_AES_NI_INTEL=y option of
> course, that always ensured AES-NI to be present and usable)
With 4.10-rc1, I also do not get the AES-NI implementations to work. do you
have any ideas what may be the issue?
Ciao
Stephan
^ permalink raw reply
* Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)
From: Hannes Frederic Sowa @ 2016-12-28 5:23 UTC (permalink / raw)
To: George Spelvin, daniel
Cc: ak, davem, David.Laight, ebiggers3, eric.dumazet, Jason,
kernel-hardening, linux-crypto, linux-kernel, luto, netdev, tom,
tytso, vegard.nossum
In-Reply-To: <20161224011754.14207.qmail@ns.sciencehorizons.net>
Hello,
On Fri, 2016-12-23 at 20:17 -0500, George Spelvin wrote:
> Hannes Frederic Sowa wrote:
> > On 24.12.2016 00:39, George Spelvin wrote:
> > > We just finished discussing why 8 bytes isn't enough. If you only
> > > feed back 8 bytes, an attacker who can do 2^64 computation can find it
> > > (by guessing and computing forward to verify the guess) and recover the
> > > previous state. You need to feed back at least as much output as your
> > > security targete. For /dev/urandom's ChaCha20, that's 256 bits.
> > I followed the discussion but it appeared to me that this has the
> > additional constraint of time until the next reseeding event happenes,
> > which is 300s (under the assumption that calls to get_random_int happen
> > regularly, which I expect right now). After that the existing reseeding
> > mechansim will ensure enough backtracking protection. The number of
> > bytes can easily be increased here, given that reseeding was shown to be
> > quite fast already and we produce enough output. But I am not sure if
> > this is a bit overengineered in the end?
>
> I'm not following your description of how the time-based and call-based
> mechanisms interact, but for any mix-back, you should either do enough
> or none at all. (Also called "catastrophic reseeding".)
We call extract_crng when we run out of batched entropy and reseed. How
often we call down to extract_crng depends on how much entropy we
extracted by calls to get_random_int/long, so the number of calls into
those functions matter.
In extract_crng we have a timer which reseeds every 300s the CPRNG and
either uses completely new entropy from the CRNG or calls down into the
CPRNG while also doing backtracing protection (which feeds chacha's
block size / 2 back into chacha, if I read the code correctly, thus
1024 bits, which should be enough).
> For example, two mix-backs of 64 bits gives you 65 bit security, not 128.
> (Because each mixback can be guessed and verified separately.)
Exactly, but the full reseed after running out of entropy is strong
enough to not be defeated by your argumentation. Neither the reseed
from the CRNG.
> > Also agreed. Given your solution below to prandom_u32, I do think it
> > might also work without the seqlock now.
>
> It's not technically a seqlock; in particular the reader doesn't
> spin. But the write side, and general logic is so similar it's
> a good mental model.
>
> Basically, assume a 64-byte buffer. The reader has gone through
> 32 bytes of it, and has 32 left, and when he reads another 8 bytes,
> has to distinguish three cases:
>
> 1) No update; we read the old bytes and there are now 32 - 24 bytes left.
> 2) Update completed while we weren't looking. There are now new
> bytes in the buffer, and we took 8 leaving 64 - 8 = 56.
> 3) Update in progress at the time of the read. We don't know if we
> are seeing old bytes or new bytes, so we have to assume the worst
> and not proceeed unless 32 >= 8, but assume at the end there are
> 64 - 8 = 56 new bytes left.
>
> > I wouldn't have added a disable irqs, but given that I really like your
> > proposal, I would take it in my todo branch and submit it when net-next
> > window opens.
>
> If you want that, I have a pile of patches to prandom I really
> should push upstream. Shall I refresh them and send them to you?
I would like to have a look at them in the new year, certainly! I can
also take care about the core prandom patches, but don't know if I have
time to submit the others to the different subsystems.
Maybe, if David would be okay with that, we can submit all patches
through his tree, as he is also the dedicated maintainer for prandom.
> [... patch descriptions ...]
Thanks,
Hannes
^ permalink raw reply
* [PATCH 0/8] random: cleanup of code after removal of nonblocking pool
From: Stephan Müller @ 2016-12-27 22:38 UTC (permalink / raw)
To: Ted Tso; +Cc: linux-kernel, linux-crypto
Hi Ted,
with the removal of the nonblocking_pool, several code paths are now unused
which were only applicable to the nonblocking pool. This patch set removes
these unused code paths.
Also, a code path in the add_interrupt_randomness function that is never used
is removed.
In addition, the FIPS 140-2 continuous self tests are required to process
the output data of the RNG given to a caller. A patch is added to cover this
requirement.
Ciao
Stephan
Stephan Mueller (8):
random: remove stale maybe_reseed_primary_crng
random: remove stale urandom_init_wait
random: trigger random_ready callback upon crng_init == 1
random: remove unused branch in hot code path
random: remove variable limit
random: fix comment for unused random_min_urandom_seed
random: remove noop function call to xfer_secondary_pool
random: move FIPS continuous test to output functions
drivers/char/random.c | 118 +++++++++++++++++++++++---------------------------
1 file changed, 53 insertions(+), 65 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH 3/8] random: trigger random_ready callback upon crng_init == 1
From: Stephan Müller @ 2016-12-27 22:39 UTC (permalink / raw)
To: Ted Tso; +Cc: linux-kernel, linux-crypto
In-Reply-To: <3254875.f5A5oHPdxF@positron.chronox.de>
The random_ready callback mechanism is intended to replicate the
getrandom system call behavior to in-kernel users. As the getrandom
system call unblocks with crng_init == 1, trigger the random_ready
wakeup call at the same time.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
drivers/char/random.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 482531d..5c26b1c 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -810,6 +810,7 @@ static int crng_fast_load(const char *cp, size_t len)
}
if (crng_init_cnt >= CRNG_INIT_CNT_THRESH) {
crng_init = 1;
+ process_random_ready_list();
wake_up_interruptible(&crng_init_wait);
pr_notice("random: fast init done\n");
}
--
2.9.3
^ permalink raw reply related
* [PATCH 2/8] random: remove stale urandom_init_wait
From: Stephan Müller @ 2016-12-27 22:39 UTC (permalink / raw)
To: Ted Tso; +Cc: linux-kernel, linux-crypto
In-Reply-To: <3254875.f5A5oHPdxF@positron.chronox.de>
The urandom_init_wait wait queue is a left over from the pre-ChaCha20
times and can therefore be savely removed.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
drivers/char/random.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 8e5ab20..482531d 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -409,7 +409,6 @@ static struct poolinfo {
*/
static DECLARE_WAIT_QUEUE_HEAD(random_read_wait);
static DECLARE_WAIT_QUEUE_HEAD(random_write_wait);
-static DECLARE_WAIT_QUEUE_HEAD(urandom_init_wait);
static struct fasync_struct *fasync;
static DEFINE_SPINLOCK(random_ready_list_lock);
--
2.9.3
^ permalink raw reply related
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