ut 17. 11. 2020 o 14:32 Ard Biesheuvel napísal(a):
> Wiring the SIMD code into the generic driver has the unfortunate side
> effect that the tcrypt testing code cannot distinguish them, and will
> therefore not use the latter to fuzz test the former, as it does for
> other algorithms.
>
> So let's
ut 10. 11. 2020 o 20:04 Ard Biesheuvel napísal(a):
> Wiring the SIMD code into the generic driver has the unfortunate side
> effect that the tcrypt testing code cannot distinguish them, and will
> therefore not use the latter to fuzz test the former, as it does for
> other algorithms.
Looking bac
ut 10. 11. 2020 o 20:04 Ard Biesheuvel napísal(a):
> The AEGIS spec mentions explicitly that the security guarantees hold
> only if the resulting plaintext and tag of a failed decryption are
> not disclosed. So ensure that we abide by this.
>
> While at it, drop the unused struct aead_request *req
st 30. 9. 2020 o 15:04 Colin King napísal(a):
>
> From: Colin Ian King
>
> There is an off-by-one range check on the upper limit of
> index "no". Fix this by changing the > comparison to >=
Note that this doesn't completely fix the bug though... (see below)
>
> Addresses-Coverity: ("Out-of-bou
pi 16. 8. 2019 o 9:02 Ondrej Mosnáček napísal(a):
> Hi Herbert,
>
> pi 16. 8. 2019 o 1:52 Herbert Xu napísal(a):
> > On Thu, Aug 15, 2019 at 10:17:37PM +0800, Zhou Wang wrote:
> > >
> > > > - dev_dbg(&qm->pdev->dev, "QM
Hi Herbert,
pi 16. 8. 2019 o 1:52 Herbert Xu napísal(a):
> On Thu, Aug 15, 2019 at 10:17:37PM +0800, Zhou Wang wrote:
> >
> > > - dev_dbg(&qm->pdev->dev, "QM mailbox request to q%u: %u-%pad\n", queue,
> > > - cmd, dma_addr);
> > > + dev_dbg(&qm->pdev->dev, "QM mailbox request to q%u
st 7. 8. 2019 o 19:44 Milan Broz napísal(a):
> On 07/08/2019 17:13, Pascal Van Leeuwen wrote:
> Seems there is no mistake in your code, it is some bug in aesni_intel
> implementation.
> If I disable this module, it works as expected (with aes generic and
> aes_i586).
>
>
pi 18. 1. 2019 o 0:15 Thomas Gleixner napísal(a):
> Precise and non-ambiguous license information is important. The recently
> added aegis header file has a SPDX license identifier, which is nice, but
> at the same time it has a contradictionary license boiler plate text.
>
> SPDX-License-Identi
pi 18. 1. 2019 o 0:15 Thomas Gleixner napísal(a):
> The license boiler plate text is not ideal for machine parsing. The kernel
> uses SPDX license identifiers for that purpose, which replace the boiler
> plate text.
>
> Signed-off-by: Thomas Gleixner
> Cc: Ondrej Mosnacek
> Cc: Herbert Xu
> Cc:
pi 18. 1. 2019 o 0:15 Thomas Gleixner napísal(a):
> The license boiler plate text is not ideal for machine parsing. The kernel
> uses SPDX license identifiers for that purpose, which replace the boiler
> plate text.
>
> Signed-off-by: Thomas Gleixner
> Cc: Ondrej Mosnacek
> Cc: Herbert Xu
> Cc:
pi 18. 1. 2019 o 0:15 Thomas Gleixner napísal(a):
> Precise and non-ambiguous license information is important. The recently
> added morus header files have a SPDX license identifier, which is nice, but
> at the same time they have a contradictionary license boiler plate text.
>
> SPDX-License-I
št 27. 9. 2018 o 0:50 napísal(a):
> sparse complains thusly:
>
> CHECK arch/x86/crypto/morus640-sse2-glue.c
> arch/x86/crypto/morus640-sse2-glue.c:38:1: warning: symbol
> 'crypto_morus640_sse2_algs' was not declared. Should it be static?
> CHECK arch/x86/crypto/morus1280-sse2-glue.c
> arc
ut 21. 8. 2018 o 18:41 Marcelo Henrique Cerri
napísal(a):
> On Tue, Aug 21, 2018 at 05:24:45PM +0200, Ondrej Mosnáček wrote:
> > CC: Paulo Flabiano Smorigo ,
> > linuxppc-...@lists.ozlabs.org
> >
> > (Sorry, sent this before reading new e-mails in the thread...)
>
CC: Paulo Flabiano Smorigo ,
linuxppc-...@lists.ozlabs.org
(Sorry, sent this before reading new e-mails in the thread...)
ut 21. 8. 2018 o 17:18 Ondrej Mosnacek napísal(a):
>
> This patch fixes sleep-in-atomic bugs in AES-CBC and AES-XTS VMX
> implementations. The problem is that the blkcipher_*
ut 21. 8. 2018 o 16:18 Stephan Mueller napísal(a):
> Am Dienstag, 21. August 2018, 14:48:11 CEST schrieb Ondrej Mosnáček:
>
> Hi Ondrej, Marcelo,
>
> (+Marcelo)
>
> > Looking at crypto/algif_skcipher.c, I can see that skcipher_recvmsg()
> > holds the socket lock
Hi,
I hit the following BUG when running the kcapi-enc-test.sh test from
libkcapi [1] on ppc64/ppc64le with recent kernels:
[ 891.863680] BUG: sleeping function called from invalid context at
include/crypto/algapi.h:424
[ 891.864622] in_atomic(): 1, irqs_disabled(): 0, pid: 12347, name: kcapi-en
Hi Linus,
ne 8. 7. 2018 o 20:32 Linus Torvalds napísal(a):
>
> On Sun, Jul 8, 2018 at 9:20 AM Herbert Xu wrote:
> >
> > - Add missing RETs in x86 aegis/morus.
>
> Side note - I queried earlier during the discussion about this: how
> was this code taken despite having clearly never tested on _any
ne 1. 7. 2018 o 15:20 Herbert Xu napísal(a):
>
> On Sat, Jun 23, 2018 at 12:36:22PM +0200, Borislav Petkov wrote:
> > Lemme send a proper patch now...
> >
> > ---
> > From: Borislav Petkov
> > Date: Sun, 17 Jun 2018 13:57:42 +0200
> > Subject: [PATCH] x86/crypto: Add missing RETs
> >
> > Add expl
so 23. 6. 2018 o 12:36 Borislav Petkov napísal(a):
>
> Lemme send a proper patch now...
>
> ---
> From: Borislav Petkov
> Date: Sun, 17 Jun 2018 13:57:42 +0200
> Subject: [PATCH] x86/crypto: Add missing RETs
>
> Add explicit RETs to the tail calls of AEGIS and MORUS crypto algorithms
> otherwise
From: Ondrej Mosnacek
Commit 56e8e57fc3a7 ("crypto: morus - Add common SIMD glue code for
MORUS") accidetally consiedered the glue code to be usable by different
architectures, but it seems to be only usable on x86.
This patch moves it under arch/x86/crypto and adds 'depends on X86' to
the Kconf
2018-05-18 23:01 GMT+02:00 Ondrej Mosnáček :
> From: Ondrej Mosnacek
>
> Commit 56e8e57fc3a7 ("crypto: morus - Add common SIMD glue code for
> MORUS") accidetally consiedered the glue code to be usable by different
> architectures, but it seems to be only usable on x86
From: Ondrej Mosnacek
AEGIS-256 key is two blocks, not one.
Fixes: 1d373d4e8e15 ("crypto: x86 - Add optimized AEGIS implementations")
Reported-by: Eric Biggers
Signed-off-by: Ondrej Mosnacek
---
arch/x86/crypto/aegis256-aesni-glue.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
2018-05-20 4:41 GMT+02:00 Eric Biggers :
> Hi Ondrej,
>
> On Fri, May 11, 2018 at 02:12:51PM +0200, Ondrej Mosnáček wrote:
>> From: Ondrej Mosnacek
>>
>> This patch adds optimized implementations of AEGIS-128, AEGIS-128L,
>> and AEGIS-256, utilizing t
From: Ondrej Mosnacek
Commit 56e8e57fc3a7 ("crypto: morus - Add common SIMD glue code for
MORUS") accidetally consiedered the glue code to be usable by different
architectures, but it seems to be only usable on x86.
This patch moves it under arch/x86/crypto and adds 'depends on X86' to
the Kconf
From: Ondrej Mosnacek
This patch adds test vectors for MORUS-640 and MORUS-1280. The test
vectors were generated using the reference implementation from
SUPERCOP (see code comments for more details).
Signed-off-by: Ondrej Mosnacek
---
crypto/testmgr.c | 18 +
crypto/testmgr.h | 3400
From: Ondrej Mosnacek
This patch adds a common glue code for optimized implementations of
MORUS AEAD algorithms.
Signed-off-by: Ondrej Mosnacek
---
crypto/Kconfig | 16 ++
crypto/Makefile | 2 +
crypto/morus1280_glue.c | 302 +
From: Ondrej Mosnacek
This patchset adds the MORUS AEAD algorithm implementation to the Linux Crypto
API.
MORUS [1] is a dedicated AEAD algorithm focused on SIMD instructions and
designed for high throughput both on modern processors and in hardware. It is
designed by Hongjun Wu and Tao Huang
From: Ondrej Mosnacek
This patch adds optimized implementations of MORUS-640 and MORUS-1280,
utilizing the SSE2 and AVX2 x86 extensions.
For MORUS-1280 (which operates on 256-bit blocks) we provide both AVX2
and SSE2 implementation. Although SSE2 MORUS-1280 is slower than AVX2
MORUS-1280, it is
From: Ondrej Mosnacek
This patch adds the generic implementation of the MORUS family of AEAD
algorithms (MORUS-640 and MORUS-1280). The original authors of MORUS
are Hongjun Wu and Tao Huang.
At the time of writing, MORUS is one of the finalists in CAESAR, an
open competition intended to select
From: Ondrej Mosnacek
This patch adds the generic implementation of the AEGIS family of AEAD
algorithms (AEGIS-128, AEGIS-128L, and AEGIS-256). The original
authors of AEGIS are Hongjun Wu and Bart Preneel.
At the time of writing, AEGIS is one of the finalists in CAESAR, an
open competition inte
From: Ondrej Mosnacek
This patchset adds the AEGIS AEAD algorithm implementation to the Linux Crypto
API.
AEGIS [1] is a dedicated AEAD algorithm based on the AES round function and
designed for high throughput both on modern processors and in hardware. It is
designed by Hongjun Wu and Bart P
From: Ondrej Mosnacek
This patch adds test vectors for the AEGIS family of AEAD algorithms
(AEGIS-128, AEGIS-128L, and AEGIS-256). The test vectors were
generated using the reference implementation from SUPERCOP (see code
comments for more details).
Signed-off-by: Ondrej Mosnacek
---
crypto/te
From: Ondrej Mosnacek
This patch adds optimized implementations of AEGIS-128, AEGIS-128L,
and AEGIS-256, utilizing the AES-NI and SSE2 x86 extensions.
Signed-off-by: Ondrej Mosnacek
---
arch/x86/crypto/Makefile | 8 +
arch/x86/crypto/aegis128-aesni-asm.S | 749 +++
(I accidentally hit "reply" instead of "reply all", so resending)
2017-11-24 6:07 GMT+01:00 Herbert Xu :
> On Thu, Nov 23, 2017 at 01:49:06PM +0100, Ondrej Mosnacek wrote:
>> diff --git a/crypto/skcipher.c b/crypto/skcipher.c
>> index 4faa0fd53b0c..6c45ed536664 100644
>> --- a/crypto/skcipher.c
>>
Never mind, Gmail is confusing me... there is indeed "v4" in the subject :)
O.M.
2017-04-01 17:19 GMT+02:00 Ondrej Mosnáček :
> Oops, sorry, wrong prefix...
>
> 2017-04-01 17:17 GMT+02:00 Ondrej Mosnacek :
>> The gf128mul_x_ble function is currently defined in gf128mul
Oops, sorry, wrong prefix...
2017-04-01 17:17 GMT+02:00 Ondrej Mosnacek :
> The gf128mul_x_ble function is currently defined in gf128mul.c, because
> it depends on the gf128mul_table_be multiplication table.
>
> However, since the function is very small and only uses two values from
> the table, i
2017-04-01 5:44 GMT+02:00 Eric Biggers :
> Also, I realized that for gf128mul_x_lle() now that we aren't using the table
> we
> don't need to shift '_tt' but rather can use the constant 0xe100:
>
> /* equivalent to (u64)gf128mul_table_le[(b << 7) & 0xff] << 48
> * (see
Hi Jeff,
2017-03-31 8:05 GMT+02:00 Jeffrey Walton :
>>> Also note that '(b & ((u64)1 << 63)) ? 0x87 : 0x00;' is actually getting
>>> compiled as '((s64)b >> 63) & 0x87', which is branchless and therefore
>>> makes the
>>> new version more efficient than one might expect:
>>>
>>> sar$0
Hi Eric,
2017-03-30 21:55 GMT+02:00 Eric Biggers :
> This is an improvement; I'm just thinking that maybe this should be done for
> all
> the gf128mul_x_*() functions, if only so that they use a consistent style and
> are all defined next to each other.
Right, that doesn't seem to be a bad idea.
Hi Gilad,
2017-01-24 15:38 GMT+01:00 Gilad Ben-Yossef :
> - v->tfm = crypto_alloc_shash(v->alg_name, 0, 0);
> + v->tfm = crypto_alloc_ahash(v->alg_name, 0, CRYPTO_ALG_ASYNC);
I believe you should pass zero as the mask here. When flags == 0 and
mask == CRYPTO_ALG_ASYNC, you are basical
2017-01-18 5:48 GMT+01:00 Herbert Xu :
> I'm open to other proposals. The basic requirement is to be able to
> process multiple blocks as one entity at the driver level, potentially
> generating the IVs there too.
>
> It's essentially the equivalent to full IPsec offload.
Hm, I just looked at wha
2017-01-13 15:29 GMT+01:00 Herbert Xu :
> What if the driver had hardware support for generating these IVs?
> With your scheme this cannot be supported at all.
That's true... I'm starting to think that this isn't really a good
idea. I was mainly trying to keep the door open for the random IV
suppo
Hi Binoy,
2017-01-16 9:37 GMT+01:00 Binoy Jayan :
> The initial goal of our proposal was to process the encryption requests with
> the
> maximum possible block sizes with a hardware which has automated iv generation
> capabilities. But when it is done in software, and if the bulk
> requests are p
2017-01-13 11:41 GMT+01:00 Herbert Xu :
> On Thu, Jan 12, 2017 at 01:59:52PM +0100, Ondrej Mosnacek wrote:
>> the goal of this patchset is to allow those skcipher API users that need to
>> process batches of small messages (especially dm-crypt) to do so efficiently.
>
> Please explain why this can'
Hi Eric,
2017-01-13 4:19 GMT+01:00 Eric Biggers :
> To what extent does the performance benefit of this patchset result from just
> the reduced numbers of calls to kernel_fpu_begin() and kernel_fpu_end()?
>
> If it's most of the benefit, would it make any sense to optimize
> kernel_fpu_begin() and
Hi Binoy,
2016-12-13 9:49 GMT+01:00 Binoy Jayan :
> Currently, the iv generation algorithms are implemented in dm-crypt.c.
> The goal is to move these algorithms from the dm layer to the kernel
> crypto layer by implementing them as template ciphers so they can be
> implemented in hardware for per
The cipher block size for GCM is 16 bytes, and thus the CTR transform
used in crypto_gcm_setkey() will also expect a 16-byte IV. However,
the code currently reserves only 8 bytes for the IV, causing
an out-of-bounds access in the CTR transform. This patch fixes
the issue by setting the size of the
2016-07-06 8:31 GMT+02:00, Herbert Xu :
> Well you're pretty much screwed as far as performance is concerned.
> So just postpone all processing to process context and allocate a new
> tfm for each request.
Yeah, I guess that's the only way then...
Thanks,
Ondrej
>
> Cheers,
> --
> Email: Herbert
Hi Stephan,
2016-07-05 18:11 GMT+02:00, Stephan Mueller :
> Am Dienstag, 5. Juli 2016, 13:44:05 schrieb Ondrej Mosnáček:
>
> Hi Ondrej,
>
>> Hi,
>>
>> I'm trying to experimentally implement the GCM-SIV AEAD algorithm from
>> [1] for the Lin
any memory there, so this may be tolerable...
Does anyone have any ideas how to deal with this?
BTW, for justification of deriving the key from the nonce see section
9 of [1]. I don't really like the design decision, but there seems to
be no better way to achieve the same property...
Thanks,
O
50 matches
Mail list logo
