On Tue, Sep 08, 2020 at 06:04:03PM +0100, Elena Petrova wrote:
> Extend the user-space RNG interface:
> 1. Add entropy input via ALG_SET_DRBG_ENTROPY setsockopt option;
> 2. Add additional data input via sendmsg syscall.
>
> This allows DRBG to be tested with test vectors, for example for the
example for the
> purpose of CAVP testing, which otherwise isn't possible.
>
> To prevent erroneous use of entropy input, it is hidden under
> CRYPTO_USER_API_RNG_CAVP config option and requires CAP_SYS_ADMIN to
> succeed.
>
> Signed-off-by: Elena Petrova
> Acked-by: Stephan Müller
Reviewed-by: Eric Biggers
Looks like the tls subsystem is encrypting uninitialized memory again.
+tls maintainers and netdev.
On Thu, Sep 10, 2020 at 07:09:24AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:3b3ea602 x86: add failure injection to get/put/clear_user
> git tree:
From: Eric Biggers
The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
doesn't make sense. Reseed it from the input_pool instead.
Fixes: d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
Cc: sta...@vger.kernel.org
Signed-off-by: Eric Biggers
---
drivers/ch
From: Eric Biggers
Remove some dead code that was left over following commit 90ea1c6436d2
("random: remove the blocking pool").
Signed-off-by: Eric Biggers
---
drivers/char/random.c | 17 ++-
include/trace/events/random.h | 83 ---
2 fil
From: Eric Biggers
On big endian CPUs, the ChaCha20-based CRNG is using the wrong
endianness for the ChaCha20 constants.
This doesn't matter cryptographically, but technically it means it's not
ChaCha20 anymore. Fix it to always use the standard constants.
Cc: linux-crypto@vger.
On Wed, Sep 16, 2020 at 03:46:18PM +0100, Christoph Hellwig wrote:
> On Wed, Sep 16, 2020 at 10:43:04AM -0400, Chris Mason wrote:
> > Otherwise we just end up with drift and kernel-specific bugs that are harder
> > to debug. To the extent those APIs make us contort the kernel code, I???m
> > sure
From: Eric Biggers
When a CPU selects which CRNG to use, it accesses crng_node_pool without
a memory barrier. That's wrong, because crng_node_pool can be set by
another CPU concurrently. Without a memory barrier, the crng_state that
is used might not appear to be fully initialized.
There
On Thu, Sep 17, 2020 at 05:26:44PM +1000, Herbert Xu wrote:
> Eric Biggers wrote:
> > From: Eric Biggers
> >
> > When a CPU selects which CRNG to use, it accesses crng_node_pool without
> > a memory barrier. That's wrong, because crng_node_pool can be set
On Fri, Sep 18, 2020 at 04:42:07PM -0400, Theodore Y. Ts'o wrote:
>
> We're currently not bothering to deal with Endian conversions with the counter
Endianness conversion for the counter isn't needed because the implementation
only treats it as words, not as bytes.
(Exception: the counter does ge
gt; On Thu, Sep 17, 2020 at 09:58:02AM -0700, Eric Biggers wrote:
> > > > >
> > > > > smp_load_acquire() is obviously correct, whereas READ_ONCE() is an
> > > > > optimization
> > > > > that is difficult to tell whether it's corre
On Tue, Sep 22, 2020 at 11:42:43AM -0700, Paul E. McKenney wrote:
> On Tue, Sep 22, 2020 at 09:51:36AM +1000, Herbert Xu wrote:
> > On Mon, Sep 21, 2020 at 04:26:39PM -0700, Paul E. McKenney wrote:
> > >
> > > > But this reasoning could apply to any data structure that contains
> > > > a spin lock,
On Tue, Sep 22, 2020 at 11:31:00AM -0700, Paul E. McKenney wrote:
> > Also, it's not just the p == &global_variable case. Consider:
> >
> > struct a { struct b *b; };
> > struct b { ... };
> >
> > Thread 1:
> >
> > /* one-time initialized data shared by all instances of b */
> > static
On Tue, Sep 22, 2020 at 01:56:28PM -0700, Paul E. McKenney wrote:
> > You're missing the point here. b and c could easily be allocated by a
> > function
> > alloc_b() that's in another file.
>
> I am still missing something.
>
> If by "allocated" you mean something like kmalloc(), the compiler
On Thu, Sep 24, 2020 at 05:59:34PM -0700, Paul E. McKenney wrote:
> On Tue, Sep 22, 2020 at 02:55:58PM -0700, Eric Biggers wrote:
> > On Tue, Sep 22, 2020 at 01:56:28PM -0700, Paul E. McKenney wrote:
> > > > You're missing the point here. b and c could easily be alloca
On Thu, Sep 24, 2020 at 08:31:02PM -0700, Paul E. McKenney wrote:
> On Thu, Sep 24, 2020 at 07:09:08PM -0700, Eric Biggers wrote:
> > On Thu, Sep 24, 2020 at 05:59:34PM -0700, Paul E. McKenney wrote:
> > > On Tue, Sep 22, 2020 at 02:55:58PM -0700, Eric Biggers wrote:
> >
On Tue, Sep 15, 2020 at 09:36:52PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Remove some dead code that was left over following commit 90ea1c6436d2
> ("random: remove the blocking pool").
>
> Signed-off-by: Eric Biggers
Ping?
On Tue, Sep 15, 2020 at 09:19:08PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
> doesn't make sense. Reseed it from the input_pool instead.
>
> Fixes: d848e5f8e1eb ("random: add new ioc
On Fri, Sep 18, 2020 at 02:57:05PM -0700, Eric Biggers wrote:
> On Fri, Sep 18, 2020 at 04:42:07PM -0400, Theodore Y. Ts'o wrote:
Ted, any further feedback on this? Are you planning to apply this patch?
- Eric
On Fri, Oct 02, 2020 at 02:38:36PM +0200, Torsten Duwe wrote:
> Almost two weeks passed and these are the "relevant" replies:
>
> Jason personally does not like FIPS, and is afraid of
> "subpar crypto". Albeit this patch set strictly isn't about
> crypto at all; the crypto subsystem is in the unlu
On Thu, Oct 08, 2020 at 08:36:23AM +0200, Corentin Labbe wrote:
> On Thu, Oct 08, 2020 at 04:52:38PM +1100, Herbert Xu wrote:
> > On Thu, Sep 24, 2020 at 03:27:38PM +0200, Corentin Labbe wrote:
> > >
> > > This is an example on next-20200923+BigEndian
> > > alg: ahash: sha1 test failed (wrong resul
-by: Corentin Labbe
> Tested-on: sun50i-h6-pine-h64
> Tested-on: imx8mn-ddr4-evk
> Tested-on: sun50i-a64-bananapi-m64
> Signed-off-by: Daniel Jordan
Looks good,
Reviewed-by: Eric Biggers
On Sat, Oct 10, 2020 at 10:16:37AM +0800, Ye Bin wrote:
> Fix follow warning:
> [crypto/testmgr.c:2317]: (warning) %d in format string (no. 5) requires
> 'int' but the argument type is 'unsigned int'.
>
> Reported-by: Hulk Robot
> Signed-off-by: Ye Bin
> ---
> crypto/testmgr.c | 2 +-
> 1 file
From: Eric Biggers
Commit 1d2c3279311e ("crypto: x86/aes - drop scalar assembler
implementations") was meant to remove aes_glue.c, but it actually left
it as an unused one-line file. Remove this unused file.
Cc: Ard Biesheuvel
Signed-off-by: Eric Biggers
---
arch/x86/crypto/aes_
On Tue, Oct 20, 2020 at 04:39:57PM -0400, Arvind Sankar wrote:
> Putting the round constants and the message schedule arrays together in
> one structure saves one register, which can be a significant benefit on
> register-constrained architectures. On x86-32 (tested on Broadwell
> Xeon), this gives
function can get inlined into sha256(), in which case the memset is
> optimized away.
>
> Signed-off-by: Arvind Sankar
Reviewed-by: Eric Biggers
Maybe get the one in arch/arm64/crypto/sha3-ce-glue.c too?
- Eric
On Tue, Oct 20, 2020 at 04:39:53PM -0400, Arvind Sankar wrote:
> The assignments to clear a through h and t1/t2 are optimized out by the
> compiler because they are unused after the assignments.
>
> These variables shouldn't be very sensitive: t1/t2 can be calculated
> from a through h, so they do
ve about 2-3% of the total time taken to compute the digest, with a
> reasonable memset() implementation, and considerably more (~20%) with a
> bad one (eg the x86 purgatory currently uses a memset() coded in C).
>
> Signed-off-by: Arvind Sankar
Looks good,
Reviewed-by: Eric Biggers
On Tue, Oct 20, 2020 at 04:39:55PM -0400, Arvind Sankar wrote:
> This reduces code size substantially (on x86_64 with gcc-10 the size of
> sha256_update() goes from 7593 bytes to 1952 bytes including the new
> SHA256_K array), and on x86 is slightly faster than the full unroll
> (tesed on Broadwell
On Tue, Oct 20, 2020 at 04:39:56PM -0400, Arvind Sankar wrote:
> Unrolling the LOAD and BLEND loops improves performance by ~8% on x86_64
> (tested on Broadwell Xeon) while not increasing code size too much.
>
> Signed-off-by: Arvind Sankar
> ---
Looks good,
Reviewed-by: Eric Biggers
On Fri, Oct 23, 2020 at 11:39:27AM -0400, Arvind Sankar wrote:
> On Wed, Oct 21, 2020 at 09:36:33PM -0700, Eric Biggers wrote:
> > On Tue, Oct 20, 2020 at 04:39:52PM -0400, Arvind Sankar wrote:
> > > Without the barrier_data() inside memzero_explicit(), the compiler may
>
Hi Konrad,
On Fri, Oct 23, 2020 at 01:55:13PM +0200, Konrad Dybcio wrote:
> Hi,
>
> I was investigating Qualcomm Crypto Engine support on my sdm630
> smartphone and found out that the already-present driver is
> compatible. In meantime I found two issues:
>
> 1. The driver doesn't seem to have a
On Sat, Oct 24, 2020 at 07:45:36AM +1100, Herbert Xu wrote:
> On Fri, Oct 23, 2020 at 08:56:04AM -0700, Eric Biggers wrote:
> >
> > When clearing memory because "it may be sensitive" rather than "it's needed
> > for
> > the code to behave correc
> state[4] += e; state[5] += f; state[6] += g; state[7] += h;
>
> /* clear any sensitive info... */
> - a = b = c = d = e = f = g = h = t1 = t2 = 0;
> memzero_explicit(W, 64 * sizeof(u32));
> }
Looks good,
Reviewed-by: Eric Biggers
From: Eric Biggers
One of the assignments that was removed by commit 4a0c1de64bf9 ("crypto:
x86/poly1305 - Remove assignments with no effect") is actually needed,
since it affects the return value.
This fixes the following crypto self-test failure:
alg: shash: poly1305-simd t
; (tested on Broadwell Xeon).
>
> Signed-off-by: Arvind Sankar
Looks good,
Reviewed-by: Eric Biggers
From: Eric Biggers
Add crypto_aead_driver_name(), which is analogous to
crypto_skcipher_driver_name().
Signed-off-by: Eric Biggers
---
include/crypto/aead.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/crypto/aead.h b/include/crypto/aead.h
index c32a6f5664e9a
From: Eric Biggers
When alg_test() is called from tcrypt.ko rather than from the algorithm
registration code, "driver" is actually the algorithm name, not the
driver name. So it shouldn't be used in places where a driver name is
wanted, e.g. when reporting a test failure o
From: Eric Biggers
When alg_test() is called from tcrypt.ko rather than from the algorithm
registration code, "driver" is actually the algorithm name, not the
driver name. So it shouldn't be used in places where a driver name is
wanted, e.g. when reporting a test failure o
ame from the crypto tfm object that
actually got allocated.
Eric Biggers (4):
crypto: aead - add crypto_aead_driver_name()
crypto: testmgr - always print the actual hash driver name
crypto: testmgr - always print the actual AEAD driver name
crypto: testmgr - always print the actual
From: Eric Biggers
When alg_test() is called from tcrypt.ko rather than from the algorithm
registration code, "driver" is actually the algorithm name, not the
driver name. So it shouldn't be used in places where a driver name is
wanted, e.g. when reporting a test failure o
From: Eric Biggers
Currently, by default crypto self-test failures only result in a
pr_warn() message and an "unknown" status in /proc/crypto. Both of
these are easy to miss. There is also an option to panic the kernel
when a test fails, but that can't be the default behavior.
On Tue, Oct 06, 2020 at 08:50:21PM -0700, Eric Biggers wrote:
> On Tue, Sep 15, 2020 at 09:19:08PM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
> > doesn't make sense. Resee
On Tue, Oct 06, 2020 at 08:50:58PM -0700, Eric Biggers wrote:
> On Tue, Sep 15, 2020 at 09:36:52PM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Remove some dead code that was left over following commit 90ea1c6436d2
> > ("random: remove the blockin
On Tue, Oct 06, 2020 at 08:51:45PM -0700, Eric Biggers wrote:
> On Fri, Sep 18, 2020 at 02:57:05PM -0700, Eric Biggers wrote:
> > On Fri, Sep 18, 2020 at 04:42:07PM -0400, Theodore Y. Ts'o wrote:
>
> Ted, any further feedback on this? Are you planning to apply this patch?
>
> - Eric
Ping.
On Mon, Oct 26, 2020 at 03:04:46PM +0200, Gilad Ben-Yossef wrote:
> Replace the explicit EBOIV handling in the dm-crypt driver with calls
> into the crypto API, which now possesses the capability to perform
> this processing within the crypto subsystem.
>
> Signed-off-by: Gilad Ben-Yossef
>
> --
On Mon, Oct 26, 2020 at 03:04:44PM +0200, Gilad Ben-Yossef wrote:
> diff --git a/crypto/eboiv.c b/crypto/eboiv.c
> new file mode 100644
> index ..467833e89139
> --- /dev/null
> +++ b/crypto/eboiv.c
> @@ -0,0 +1,295 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * EBOIV skcipher tem
On Mon, Oct 26, 2020 at 11:24:50AM -0700, Eric Biggers wrote:
> > +static int eboiv_create(struct crypto_template *tmpl, struct rtattr **tb)
> > +{
> > + struct crypto_attr_type *algt;
> > + const char *inner_cipher_name;
> > + struct skcipher_instance *skciph
On Mon, Oct 26, 2020 at 07:29:57PM +0100, Milan Broz wrote:
> On 26/10/2020 18:52, Eric Biggers wrote:
> > On Mon, Oct 26, 2020 at 03:04:46PM +0200, Gilad Ben-Yossef wrote:
> >> Replace the explicit EBOIV handling in the dm-crypt driver with calls
> >> into the crypto A
From: Eric Biggers
Commit 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm
names") made the kernel start accepting arbitrarily long algorithm names
in sockaddr_alg. However, the actual length of the salg_name field
stayed at the original 64 bytes.
This is broken b
On Mon, Oct 26, 2020 at 10:23:35PM +0100, 'Jann Horn' via syzkaller-bugs wrote:
> On Mon, Oct 26, 2020 at 9:08 PM Eric Biggers wrote:
> > Commit 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm
> > names") made the kernel start accepting arbi
On Tue, Oct 27, 2020 at 12:00:27AM +0100, Ard Biesheuvel wrote:
> PAC pointer authentication signs the return address against the value
> of the stack pointer, to prevent stack overrun exploits from corrupting
> the control flow. However, this requires that the AUTIASP is issued with
> SP holding t
On Mon, Oct 26, 2020 at 06:10:59PM -0500, Gustavo A. R. Silva wrote:
> On Mon, Oct 26, 2020 at 04:21:48PM -0500, Gustavo A. R. Silva wrote:
> > > +/*
> > > + * Linux v4.12 and later removed the 64-byte limit on salg_name[]; it's
> > > now an
> > > + * arbitrary-length field. We had to keep the or
On Tue, Nov 03, 2020 at 08:15:06PM +0800, l00374334 wrote:
> From: liqiang
>
> In the libz library, the checksum algorithm adler32 usually occupies
> a relatively high hot spot, and the SVE instruction set can easily
> accelerate it, so that the performance of libz library will
On Thu, Nov 05, 2020 at 05:05:53PM +0800, Li Qiang wrote:
>
>
> 在 2020/11/5 15:51, Ard Biesheuvel 写道:
> > Note that NEON intrinsics can be compiled for 32-bit ARM as well (with
> > a bit of care - please refer to lib/raid6/recov_neon_inner.c for an
> > example of how to deal with intrinsics that
-- a/crypto/tcrypt.c
> +++ b/crypto/tcrypt.c
> @@ -3066,7 +3066,7 @@ static int __init tcrypt_mod_init(void)
> */
> static void __exit tcrypt_mod_fini(void) { }
>
> -subsys_initcall(tcrypt_mod_init);
> +late_initcall(tcrypt_mod_init);
> module_exit(tcrypt_mod_fini);
>
> module_param(alg, charp, 0);
> --
Reviewed-by: Eric Biggers
Hi Konrad,
On Thu, Nov 12, 2020 at 09:26:30PM +0100, Konrad Dybcio wrote:
> Hi Eric,
>
> First of all, I am EXTREMELY sorry for my long overdue response..
>
> I just wanted to bring up that piece of HW so as to offload crypto
> tasks from the CPU, but it ended up being slower (which I suspect is
From: Eric Biggers
Currently contains declarations for both SHA-1 and SHA-2,
and contains declarations for SHA-3.
This organization is inconsistent, but more importantly SHA-1 is no
longer considered to be cryptographically secure. So to the extent
possible, SHA-1 shouldn't be gr
On Tue, Sep 03, 2019 at 04:54:38PM +1000, Herbert Xu wrote:
> int skcipher_walk_done(struct skcipher_walk *walk, int err)
> {
> - unsigned int n; /* bytes processed */
> - bool more;
> -
> - if (unlikely(err < 0))
> - goto finish;
> + unsigned int n = walk->nbytes - er
On Wed, Sep 04, 2019 at 08:36:41AM +1000, Herbert Xu wrote:
> On Tue, Sep 03, 2019 at 08:50:20AM -0500, Eric Biggers wrote:
> >
> > Doesn't this re-introduce the same bug that my patch fixed -- that
> > scatterwalk_done() could be called after 0 bytes processe
On Thu, Sep 05, 2019 at 03:40:32PM +1000, Herbert Xu wrote:
> On Wed, Sep 04, 2019 at 10:22:17PM -0700, Eric Biggers wrote:
> >
> > Okay, but what about external callers that pass in an error? (I mean, I
> > don't
> > actually see any currently, but the po
On Wed, Sep 11, 2019 at 12:38:21PM +0200, Pascal van Leeuwen wrote:
> Added testvectors for the ofb(sm4) and cfb(sm4) skcipher algorithms
>
What is the use case for these algorithms? Who/what is going to use them?
- Eric
On Sun, Sep 15, 2019 at 08:35:36PM +0200, Corentin Labbe wrote:
> When a TFM is unregistered, the sun4i-ss driver does not clean the key used,
> leaking it in memory.
> This patch adds this absent key cleaning.
>
> Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto
> ac
On Wed, Sep 11, 2019 at 07:34:31PM +, Pascal Van Leeuwen wrote:
> > -Original Message-
> > From: Eric Biggers
> > Sent: Wednesday, September 11, 2019 6:06 PM
> > To: Pascal van Leeuwen
> > Cc: linux-crypto@vger.kernel.org; antoine.ten...@bootlin.com;
&
On Mon, Sep 16, 2019 at 03:19:06AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:f4b752a6 mlx4: fix spelling mistake "veify" -> "verify"
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=1183c7fa60
> kernel config:
On Thu, Sep 19, 2019 at 07:36:20AM +0200, Steffen Klassert wrote:
> On Wed, Sep 18, 2019 at 10:15:45PM -0700, Eric Biggers wrote:
> >
> > Reproducer involves pcrypt, so probably the pcrypt deadlock again...
> > https://lkml.kernel.org/linux-crypto/20190817054743.GE8209@sol.l
On Fri, Oct 04, 2019 at 04:29:57PM +0200, Jason A. Donenfeld wrote:
> On Fri, Oct 4, 2019 at 4:23 PM Ard Biesheuvel
> wrote:
> > How is it relevant whether the boot CPU is A5 or A7? These are bL
> > little cores that only implement NEON for feature parity with their bl
> > big counterparts, but C
On Fri, Oct 04, 2019 at 03:29:33PM +0200, Gert Robben wrote:
> Op 04-10-2019 om 08:16 schreef Ard Biesheuvel:
> > On Thu, 3 Oct 2019 at 23:26, Gert Robben wrote:
> > > Op 03-10-2019 om 15:39 schreef Ard Biesheuvel:
> > > > Commit 79c65d179a40e145 ("crypto: cbc - Convert to skcipher") updated
> > >
From: Eric Biggers
Instead of open-coding the calculations for ESSIV handling, use an ESSIV
skcipher which does all of this under the hood. ESSIV was added to the
crypto API in v5.4.
This is based on a patch from Ard Biesheuvel, but reworked to apply
after all the fscrypt changes that went
Hi David, thanks for working on this. Comments below.
On Thu, Oct 10, 2019 at 04:10:05PM +0200, David Sterba wrote:
> The patch brings support of several BLAKE2 variants (2b with various
> digest lengths). The keyed digest is supported, using tfm->setkey call.
> The in-tree user will be btrfs (f
A couple more comments:
On Thu, Oct 10, 2019 at 04:10:05PM +0200, David Sterba wrote:
> +static void blake2b_set_lastnode(struct blake2b_state *S)
> +{
> + S->f[1] = (u64)-1;
> +}
> +
[...]
> +static void blake2b_set_lastblock(struct blake2b_state *S)
> +{
> + if (S->last_node)
> +
From: Eric Biggers
The geode AES driver is heavily broken because it stores per-request
state in the transform context. So it will crash or produce the wrong
result if used by any of the many places in the kernel that issue
concurrent requests for the same transform object.
This driver is also
nrounds);
> + kernel_fpu_end();
Since the kernel_fpu_begin() and kernel_fpu_end() were moved here, it's now
possible to simplify the code by moving the call to skcipher_walk_virt() into
chacha_simd_stream_xor() rather than making the caller do it.
I.e., s
On Mon, Oct 07, 2019 at 06:46:02PM +0200, Ard Biesheuvel wrote:
> From: "Jason A. Donenfeld"
>
> The C implementation was originally based on Samuel Neves' public
> domain reference implementation but has since been heavily modified
> for the kernel. We're able to do compile-time optimizations by
On Mon, Oct 07, 2019 at 06:45:52PM +0200, Ard Biesheuvel wrote:
> Now that all users of generic ChaCha code have moved to the core library,
> there is no longer a need for the generic ChaCha skcpiher driver to
> export parts of it implementation for reuse by other drivers. So drop
> the exports, an
On Mon, Oct 07, 2019 at 06:45:48PM +0200, Ard Biesheuvel wrote:
> diff --git a/arch/arm/crypto/chacha-scalar-core.S
> b/arch/arm/crypto/chacha-scalar-core.S
> index 2140319b64a0..0970ae107590 100644
> --- a/arch/arm/crypto/chacha-scalar-core.S
> +++ b/arch/arm/crypto/chacha-scalar-core.S
> @@ -41,
On Mon, Oct 07, 2019 at 06:46:09PM +0200, Ard Biesheuvel wrote:
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index b9b0e969a1ce..05e80d7d5e40 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -302,6 +302,13 @@ config CRYPTO_GCM
> Support for Galois/Counter Mode (GCM) and Galois
On Mon, Oct 07, 2019 at 06:45:48PM +0200, Ard Biesheuvel wrote:
> +static int chacha_stream_xor(struct skcipher_request *req,
> + const struct chacha_ctx *ctx, const u8 *iv)
> +{
> + struct skcipher_walk walk;
> + u32 state[16];
> + int err;
> +
> + err = sk
On Fri, Oct 11, 2019 at 06:52:03PM +0200, David Sterba wrote:
> The patchset adds blake2b refrerence implementation and test vectors.
>
> V4:
>
> Code changes:
>
> - removed .finup
> - removed .cra_init
> - dropped redundant sanity checks (key length, output size length)
> - switch blake2b_param
On Fri, Oct 11, 2019 at 06:52:04PM +0200, David Sterba wrote:
> diff --git a/crypto/Makefile b/crypto/Makefile
> index 9479e1a45d8c..2318420d3e71 100644
> --- a/crypto/Makefile
> +++ b/crypto/Makefile
> @@ -74,6 +74,7 @@ obj-$(CONFIG_CRYPTO_STREEBOG) += streebog_generic.o
> obj-$(CONFIG_CRYPTO_WP5
On Fri, Oct 11, 2019 at 06:52:04PM +0200, David Sterba wrote:
> The patch brings support of several BLAKE2 variants (2b with various
> digest lengths). The keyed digest is supported, using tfm->setkey call.
> The in-tree user will be btrfs (for checksumming), we're going to use
> the BLAKE2b-256 v
From: Eric Biggers
Convert the glue code for the PowerPC SPE implementations of AES-ECB,
AES-CBC, AES-CTR, and AES-XTS from the deprecated "blkcipher" API to the
"skcipher" API.
Tested with:
export ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu-
make mpc85xx_d
From: Eric Biggers
Convert the glue code for the SPARC64 DES opcodes implementations of
DES-ECB, DES-CBC, 3DES-ECB, and 3DES-CBC from the deprecated "blkcipher"
API to the "skcipher" API. This is needed in order for the blkcipher
API to be removed.
Signed-off-by: Eric Bigg
boot and check for crypto self-test failures by running
'dmesg | grep alg'.
If there are test failures, please also check whether they were already
failing prior to this patchset.
Eric Biggers (3):
crypto: sparc/aes - convert to skcipher API
crypto: sparc/camellia - convert to skcip
From: Eric Biggers
Convert the glue code for the SPARC64 Camellia opcodes implementations
of Camellia-ECB and Camellia-CBC from the deprecated "blkcipher" API to
the "skcipher" API. This is needed in order for the blkcipher API to be
removed.
Signed-off-by: Eric Biggers
--
From: Eric Biggers
Convert the glue code for the SPARC64 AES opcodes implementations of
AES-ECB, AES-CBC, and AES-CTR from the deprecated "blkcipher" API to the
"skcipher" API. This is needed in order for the blkcipher API to be
removed.
Signed-off-by: Eric Biggers
--
On Sat, Oct 12, 2019 at 08:16:41AM +0300, Anatoly Pugachev wrote:
> On Sat, Oct 12, 2019, 07:47 Eric Biggers wrote:
>
> > This series converts the glue code for the SPARC64 crypto opcodes
> > implementations of AES, Camellia, DES, and 3DES modes from the
> > deprecate
From: Eric Biggers
Convert the glue code for the S390 CPACF implementations of AES-ECB,
AES-CBC, AES-XTS, and AES-CTR from the deprecated "blkcipher" API to the
"skcipher" API. This is needed in order for the blkcipher API to be
removed.
Note: I made CTR use the same fun
n't have self-tests. If anyone has any way to test those,
please do so.
Eric Biggers (3):
crypto: s390/aes - convert to skcipher API
crypto: s390/paes - convert to skcipher API
crypto: s390/des - convert to skcipher API
arch/s390/crypto/aes_s390.c | 609 +
From: Eric Biggers
Convert the glue code for the S390 CPACF implementations of DES-ECB,
DES-CBC, DES-CTR, 3DES-ECB, 3DES-CBC, and 3DES-CTR from the deprecated
"blkcipher" API to the "skcipher" API. This is needed in order for the
blkcipher API to be removed.
Note: I m
From: Eric Biggers
Convert the glue code for the S390 CPACF protected key implementations
of AES-ECB, AES-CBC, AES-XTS, and AES-CTR from the deprecated
"blkcipher" API to the "skcipher" API. This is needed in order for the
blkcipher API to be removed.
Note: I made CTR use t
From: Eric Biggers
Convert the VIA PadLock implementations of AES-ECB and AES-CBC from the
deprecated "blkcipher" API to the "skcipher" API. This is needed in
order for the blkcipher API to be removed.
Signed-off-by: Eric Biggers
---
This is compile-tested only, as I don&
From: Eric Biggers
Convert the PowerPC Nest (NX) implementation of AES-CTR from the
deprecated "blkcipher" API to the "skcipher" API. This is needed in
order for the blkcipher API to be removed.
Signed-off-by: Eric Biggers
---
drivers/crypto/
has this hardware, please test this patchset with
CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y.
Eric Biggers (4):
crypto: nx - don't abuse blkcipher_desc to pass iv around
crypto: nx - convert AES-ECB to skcipher API
crypto: nx - convert AES-CBC to skcipher API
crypto: nx - convert AES-CTR to
From: Eric Biggers
Convert the PowerPC Nest (NX) implementation of AES-ECB from the
deprecated "blkcipher" API to the "skcipher" API. This is needed in
order for the blkcipher API to be removed.
Signed-off-by: Eric Biggers
---
drivers/crypto/
From: Eric Biggers
The NX crypto driver is using 'struct blkcipher_desc' to pass the IV
around, even for AEADs (for which it creates the struct on the stack).
This is not appropriate since this structure is part of the "blkcipher"
API, which is deprecated and will be remove
From: Eric Biggers
Convert the PowerPC Nest (NX) implementation of AES-CBC from the
deprecated "blkcipher" API to the "skcipher" API. This is needed in
order for the blkcipher API to be removed.
Signed-off-by: Eric Biggers
---
drivers/crypto/
On Sun, Oct 13, 2019 at 05:31:31PM +0200, Ard Biesheuvel wrote:
> On Sun, 13 Oct 2019 at 08:29, Ard Biesheuvel
> wrote:
> >
> > On Sun, 13 Oct 2019 at 06:40, Eric Biggers wrote:
> > >
> > > This series converts the PowerPC Nest (NX) implementations of
On Sun, Oct 13, 2019 at 09:50:52PM +0200, David Sterba wrote:
> On Fri, Oct 11, 2019 at 10:57:40AM -0700, Eric Biggers wrote:
> > The choice of data lengths seems a bit unusual, as they include every
> > length in
> > two ranges but nothing in between. Also, none of the
On Sun, Oct 13, 2019 at 11:20:51PM +, Jamie Heilman wrote:
> Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Convert the VIA PadLock implementations of AES-ECB and AES-CBC from the
> > deprecated "blkcipher" API to the "skcipher" API. This
301 - 400 of 1650 matches
Mail list logo
