Ard,
This is really interesting implementation. Is there a way to test if
execution of this code is really constant time. Have you done any tests
like that? Adam Langley has proposed using modified version of valgrind
(ctgrind) for that, but I wonder if you maybe thought about any
alternative meth
On 26 January 2017 at 18:35, Krzysztof Kwiatkowski wrote:
> Ard,
>
> This is really interesting implementation. Is there a way to test if
> execution of this code is really constant time. Have you done any tests
> like that?
No, I haven't, and to be perfectly honest, I think it would only make
se
In preparation of splitting off the CBC-MAC transform in the CCM
driver into a separate algorithm, define some test cases for the
AES incarnation of cbcmac.
Signed-off-by: Ard Biesheuvel
---
crypto/testmgr.c | 7 +++
crypto/testmgr.h | 58
2 files changed, 65 insertions(+)
On ARMv8 implementations that do not support the Crypto Extensions,
such as the Raspberry Pi 3, the CCM driver falls back to the generic
table based AES implementation to perform the MAC part of the
algorithm, which is slow and not time invariant. So add a CBCMAC
implementation to the shared glue c
Lookup table based AES is sensitive to timing attacks, which is
due to the fact that such table lookups are data dependent, and
the fact that 8 KB worth of tables covers a significant number of
cachelines on any architecture.
For network facing algorithms such as CTR, CCM or GCM, this presents
a s
Update the generic CCM driver to defer CBC-MAC processing to a
dedicated CBC-MAC ahash transform rather than open coding this
transform (and much of the associated scatterwalk plumbing) in
the CCM driver itself.
This cleans up the code considerably, but more importantly, it allows
the use of alter
This series is primarily directed at improving the performance and security
of CCM on the Rasperry Pi 3. This involves splitting the MAC handling of
CCM into a separate driver so that we can efficiently replace it by something
else using the ordinary algo resolution machinery.
Patch #1 adds some t
This patch adds support to the hmac(shaX) algorithms.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha-regs.h | 4 +
drivers/crypto/atmel-sha.c | 598 +++-
2 files changed, 601 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/atmel-s
This patch adds a simple function to perform data transfer with the DMA
controller.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha.c | 116 +
1 file changed, 116 insertions(+)
diff --git a/drivers/crypto/atmel-sha.c b/drivers/crypto/atmel
This patch fixes the value returned by atmel_aes_handle_queue(), which
could have been wrong previously when the crypto request was started
synchronously but became asynchronous during the ctx->start() call.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-aes.c | 7 +--
1 file change
This patch is a transitional patch. It splits the atmel_sha_handle_queue()
function. Now atmel_sha_handle_queue() only manages the request queue and
calls a new .start() hook from the atmel_sha_ctx structure.
This hook allows to implement different kind of requests still handled by
a single queue.
This patchs allows to combine the AES and SHA hardware accelerators on
some Atmel SoCs. Doing so, AES blocks are only written to/read from the
AES hardware. Those blocks are also transferred from the AES to the SHA
accelerator internally, without additionnal accesses to the system busses.
Hence, t
When VERBOSE_DEBUG is defined and SHA_FLAGS_DUMP_REG flag is set in
dd->flags, this patch prints the register names and values when performing
IO accesses.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha.c | 110 -
1 file changed, 108 inser
This is a transitional patch: it creates the atmel_sha_find_dev() function,
which will be used in further patches to share the source code responsible
for finding a Atmel SHA device.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha.c | 15 +++
1 file changed, 11 insertions
This patch modifies the SHA_FLAGS_SHA* flags: those algo flags are now
organized as values of a single bitfield instead of individual bits.
This allows to reduce the number of bits needed to encode all possible
values. Also the new values match the SHA_MR_ALGO_SHA* values hence
the algorithm bitfie
This patch defines an alias macro to SHA_MR_MODE_PDC, which is not suited
for DMA usage.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha-regs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/atmel-sha-regs.h b/drivers/crypto/atmel-sha-regs.h
index deb0b0b15096..8d
This patch simply defines a helper function to test the 'Data Ready' flag
of the Status Register. It also gives a chance for the crypto request to
be processed synchronously if this 'Data Ready' flag is already set when
polling the Status Register. Indeed, running synchronously avoid the
latency of
This patch adds a simple function to perform data transfer with PIO, hence
handled by the CPU.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha.c | 90 ++
1 file changed, 90 insertions(+)
diff --git a/drivers/crypto/atmel-sha.c b/drivers/cr
This patch is a transitional patch. It updates atmel_sha_done_task() to
make it more generic. Indeed, it adds a new .resume() member in the
atmel_sha_dev structure. This hook is called from atmel_sha_done_task()
to resume processing an asynchronous request.
Signed-off-by: Cyrille Pitchen
---
dri
Hi all,
this series of patches has been based and tested on next-20170125 with
CRYPTO_MANAGER_DISABLED_TESTS not set.
The series adds support to the hmac(shaX) algorithms first, then combines
both the Atmel SHA and AES hardware accelerators to implement
authenc(hmac(shaX),Y(aes)) algorithms as us
From: Rabin Vincent
The documentation states that crypto_ahash_reqsize() provides the size
of the state structure used by crypto_ahash_export(). But it's actually
crypto_ahash_statesize() which provides this size.
Signed-off-by: Rabin Vincent
---
v2: Add crypto_ahash_statesize() to api-digest;
On Wed, Jan 25, 2017 at 05:18:05PM +0100, Stephan Müller wrote:
> Am Mittwoch, 25. Januar 2017, 16:55:06 CET schrieb Rabin Vincent:
> > The documentation states that crypto_ahash_reqsize() provides the size
> > of the state structure used by crypto_ahash_export(). But it's actually
> > crypto_ahas
On Thu, Jan 26, 2017 at 01:19:53AM -0800, Eric Biggers wrote:
> On Thu, Jan 26, 2017 at 08:57:30AM +0100, Sven Schmidt wrote:
> >
> > This patchset is for updating the LZ4 compression module to a version based
> > on LZ4 v1.7.3 allowing to use the fast compression algorithm aka LZ4 fast
> > which
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
On Thu, Jan 26, 2017 at 08:57:30AM +0100, Sven Schmidt wrote:
>
> This patchset is for updating the LZ4 compression module to a version based
> on LZ4 v1.7.3 allowing to use the fast compression algorithm aka LZ4 fast
> which provides an "acceleration" parameter as a tradeoff between
> high compre
25 matches
Mail list logo
