On Wed, 20 May 2020 at 08:47, Stephan Mueller wrote:
>
> Am Mittwoch, 20. Mai 2020, 08:40:57 CEST schrieb Ard Biesheuvel:
>
> Hi Ard,
>
> > On Wed, 20 May 2020 at 08:03, Stephan Mueller wrote:
> > > Am Dienstag, 19. Mai 2020, 21:02:09 CEST schrieb Ard Biesheuvel:
> > >
> > > Hi Ard,
> > >
> > > >
Am Mittwoch, 20. Mai 2020, 08:40:57 CEST schrieb Ard Biesheuvel:
Hi Ard,
> On Wed, 20 May 2020 at 08:03, Stephan Mueller wrote:
> > Am Dienstag, 19. Mai 2020, 21:02:09 CEST schrieb Ard Biesheuvel:
> >
> > Hi Ard,
> >
> > > Stephan reports that the arm64 implementation of cts(cbc(aes)) deviates
On Wed, 20 May 2020 at 08:03, Stephan Mueller wrote:
>
> Am Dienstag, 19. Mai 2020, 21:02:09 CEST schrieb Ard Biesheuvel:
>
> Hi Ard,
>
> > Stephan reports that the arm64 implementation of cts(cbc(aes)) deviates
> > from the generic implementation in what it returns as the output IV. So
> > fix th
Am Dienstag, 19. Mai 2020, 23:25:51 CEST schrieb Łukasz Stelmach:
Hi Łukasz,
> The value was estimaded with ea_iid[1] using on 10485760 bytes read from
> the RNG via /dev/hwrng. The min-entropy value calculated using the most
> common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.96446
Am Dienstag, 19. Mai 2020, 21:02:09 CEST schrieb Ard Biesheuvel:
Hi Ard,
> Stephan reports that the arm64 implementation of cts(cbc(aes)) deviates
> from the generic implementation in what it returns as the output IV. So
> fix this, and add some test vectors to catch other non-compliant
> impleme
On Mon, May 18, 2020 at 6:59 PM Horia Geantă wrote:
>
> On 5/16/2020 7:23 AM, Andrey Smirnov wrote:
> > Vyrbrid devices don't have any clock that need to be taken care of, so
> > make clock data optional on i.MX.
> >
> Vybrid Security RM states that IPG clock used by CAAM
> can be gated by CCM_CCG
Now, in crypto-engine, if hardware queue is full (-ENOSPC),
requeue request regardless of MAY_BACKLOG flag.
If hardware throws any other error code (like -EIO, -EINVAL,
-ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into
crypto-engine's queue, since the others can be dropped.
The latter
On Tue, 19 May 2020 13:21:56 -0400 Pooja Trivedi wrote:
> On Mon, May 18, 2020 at 6:50 PM Jakub Kicinski wrote:
> > On Sun, 17 May 2020 16:26:36 + Pooja Trivedi wrote:
> > > In pure sw ktls(AES-NI), -EAGAIN from tcp layer (do_tcp_sendpages for
> > > encrypted record) gets treated as error, s
The rng structure contains the quality field which tells how many bits
of entropy can be obtained from 1024 bits read from a device. With the
quality value set the hw_random framework starts a kernel thread to feed
the entropy pool in the CRNG, which helps to initialize it quickly
especially during
The value was estimaded with ea_iid[1] using on 10485760 bytes read from
the RNG via /dev/hwrng. The min-entropy value calculated using the most
common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.489627.
[1] https://github.com/usnistgov/SP800-90B_EntropyAssessment
[2] https://csrc.nis
The value was estimaded with ea_iid[1] using on 10485760 bytes read from
the RNG via /dev/hwrng. The min-entropy value calculated using the most
common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.964464.
[1] https://github.com/usnistgov/SP800-90B_EntropyAssessment
[2] https://csrc.nis
When a list is completely iterated with 'list_for_each_entry(x, ...)', x is
not NULL at the end.
Introduce an intermediate variable and test it instead, in order to
reliably know if something was found or not.
Fixes: f2663872f073 ("crypto: cavium - Register the CNN55XX supported crypto
algorithm
s/NITORX/NITROX/
Signed-off-by: Christophe JAILLET
---
drivers/crypto/cavium/nitrox/nitrox_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/cavium/nitrox/nitrox_main.c
b/drivers/crypto/cavium/nitrox/nitrox_main.c
index e91be9b8b083..788c6607078b 100644
-
Hello Ben,
On Tue, May 19, 2020 at 02:53:05PM +0100, Ben Hutchings wrote:
> I noticed that commit 07928d9bfc81 "padata: Remove broken queue
> flushing" has been backported to most stable branches, but commit
> 6fc4dbcf0276 "padata: Replace delayed timer with immediate workqueue in
> padata_reorder
(add Gilad for cc-ree)
On Tue, 19 May 2020 at 21:02, Ard Biesheuvel wrote:
>
> Stephan reports that the arm64 implementation of cts(cbc(aes)) deviates
> from the generic implementation in what it returns as the output IV. So
> fix this, and add some test vectors to catch other non-compliant
> imp
Add some test vectors to get coverage for the IV that is output by CTS
implementations.
Signed-off-by: Ard Biesheuvel
---
crypto/testmgr.h | 12
1 file changed, 12 insertions(+)
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index d29983908c38..d45fa1ad91ee 100644
--- a/crypto/te
Stephan reports that the arm64 implementation of cts(cbc(aes)) deviates
from the generic implementation in what it returns as the output IV. So
fix this, and add some test vectors to catch other non-compliant
implementations.
Stephan, could you provide a reference for the NIST validation tool and
The generic CTS chaining mode wraps the CBC mode driver in a way that
results in the IV buffer referenced by the skcipher request to be
updated with the last block of ciphertext. The arm64 implementation
deviates from this, given that CTS itself does not specify the concept
of an output IV, or how
Am Dienstag, 19. Mai 2020, 19:53:57 CEST schrieb Ard Biesheuvel:
Hi Ard,
> On Tue, 19 May 2020 at 19:50, Ard Biesheuvel wrote:
> > On Tue, 19 May 2020 at 19:35, Stephan Mueller wrote:
> > > Am Dienstag, 19. Mai 2020, 18:21:01 CEST schrieb Ard Biesheuvel:
> > >
> > > Hi Ard,
> > >
> > > > To b
On Tue, 19 May 2020 at 19:50, Ard Biesheuvel wrote:
>
> On Tue, 19 May 2020 at 19:35, Stephan Mueller wrote:
> >
> > Am Dienstag, 19. Mai 2020, 18:21:01 CEST schrieb Ard Biesheuvel:
> >
> > Hi Ard,
> >
> > >
> > > To be honest, this looks like the API is being used incorrectly. Is
> > > this a si
On Tue, 19 May 2020 at 19:35, Stephan Mueller wrote:
>
> Am Dienstag, 19. Mai 2020, 18:21:01 CEST schrieb Ard Biesheuvel:
>
> Hi Ard,
>
> >
> > To be honest, this looks like the API is being used incorrectly. Is
> > this a similar issue to the one Herbert spotted recently with the CTR
> > code?
>
Am Dienstag, 19. Mai 2020, 18:21:01 CEST schrieb Ard Biesheuvel:
Hi Ard,
>
> To be honest, this looks like the API is being used incorrectly. Is
> this a similar issue to the one Herbert spotted recently with the CTR
> code?
>
> When you say 'leaving the TFM untouched' do you mean the skcipher
On Mon, May 18, 2020 at 6:50 PM Jakub Kicinski wrote:
>
> On Sun, 17 May 2020 16:26:36 + Pooja Trivedi wrote:
> > In pure sw ktls(AES-NI), -EAGAIN from tcp layer (do_tcp_sendpages for
> > encrypted record) gets treated as error, subtracts the offset, and
> > returns to application. Because of
(+ Eric)
Hi Stephan,
On Tue, 19 May 2020 at 17:31, Stephan Mueller wrote:
>
> Hi Ard,
>
> The following report applies to kernel 5.3 as I am currently unable to test
> the latest upstream version.
>
> The CTS IV handling for cts-cbc-aes-ce and cts-cbc-aes-neon is not consistent
> with the C impl
Hi Ard,
The following report applies to kernel 5.3 as I am currently unable to test
the latest upstream version.
The CTS IV handling for cts-cbc-aes-ce and cts-cbc-aes-neon is not consistent
with the C implementation for CTS such as cts(cbc-aes-ce) and cts(cbc-aes-
neon).
For example, assume e
On Tue, May 19, 2020 at 07:13:21AM -0400, Theodore Y. Ts'o wrote:
> On Fri, May 15, 2020 at 01:41:41PM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > The eMMC inline crypto standard will only specify 32 DUN bits (a.k.a. IV
> > bits), unlike UFS's 64. IV_INO_LBLK_64 is therefore not ap
I noticed that commit 07928d9bfc81 "padata: Remove broken queue
flushing" has been backported to most stable branches, but commit
6fc4dbcf0276 "padata: Replace delayed timer with immediate workqueue in
padata_reorder" has not.
Is this correct? What prevents the parallel_data ref-count from
droppi
On Fri, May 15, 2020 at 01:41:41PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> The eMMC inline crypto standard will only specify 32 DUN bits (a.k.a. IV
> bits), unlike UFS's 64. IV_INO_LBLK_64 is therefore not applicable, but
> an encryption format which uses one key per policy and permi
28 matches
Mail list logo
