On Mon, 22 Oct 2018, James Bottomley wrote:
This code adds true session based HMAC authentication plus parameter
decryption and response encryption using AES.
In order to reduce complexity it would make sense to split into two
commits: authentication and parameter encryption.
The basic
On Mon, 22 Oct 2018, James Bottomley wrote:
This separates out the old tpm_buf_... handling functions from static
inlines into tpm.h and makes them their own tpm-buf.c file. It also
adds handling for tpm2b structures and also incremental pointer
advancing parsers.
Signed-off-by: James
On Mon, 22 Oct 2018, James Bottomley wrote:
This separates out the old tpm_buf_... handling functions from static
inlines into tpm.h and makes them their own tpm-buf.c file. It also
adds handling for tpm2b structures and also incremental pointer
advancing parsers.
Nitpicking: when my SGX
On 23 October 2018 at 04:01, James Bottomley
wrote:
> On Mon, 2018-10-22 at 19:19 -0300, Ard Biesheuvel wrote:
> [...]
>> > +static void hmac_init(struct shash_desc *desc, u8 *key, int
>> > keylen)
>> > +{
>> > + u8 pad[SHA256_BLOCK_SIZE];
>> > + int i;
>> > +
>> > + desc->tfm =
On Mon, 2018-10-22 at 19:19 -0300, Ard Biesheuvel wrote:
[...]
> > +static void hmac_init(struct shash_desc *desc, u8 *key, int
> > keylen)
> > +{
> > + u8 pad[SHA256_BLOCK_SIZE];
> > + int i;
> > +
> > + desc->tfm = sha256_hash;
> > + desc->flags =
Hi James,
Some comments below on how you are using the crypto API.
On 22 October 2018 at 04:36, James Bottomley
wrote:
> This code adds true session based HMAC authentication plus parameter
> decryption and response encryption using AES.
>
> The basic design of this code is to segregate all the
This runs through a preset sequence using sessions to demonstrate that
the session handling code functions. It does both HMAC, encryption
and decryption by testing an encrypted sealing operation with
authority and proving that the same sealed data comes back again via
an HMAC and response
This is the last component of encrypted tpm2 session handling that
allows us to verify from userspace that the key derived from the NULL
seed genuinely belongs to the TPM and has not been spoofed.
The procedure for doing this involves creating an attestation identity
key (which requires
If some entity is snooping the TPM bus, the can see the data going in
to be sealed and the data coming out as it is unsealed. Add parameter
and response encryption to these cases to ensure that no secrets are
leaked even if the bus is snooped.
As part of doing this conversion it was discovered
If some entity is snooping the TPM bus, they can see the random
numbers we're extracting from the TPM and do prediction attacks
against their consumers. Foil this attack by using response
encryption to prevent the attacker from seeing the random sequence.
Signed-off-by: James Bottomley
---
We use tpm2_pcr_extend() in trusted keys to extend a PCR to prevent a
key from being re-loaded until the next reboot. To use this
functionality securely, that extend must be protected by a session
hmac.
Signed-off-by: James Bottomley
---
v3: add error handling to sessions
---
This code adds true session based HMAC authentication plus parameter
decryption and response encryption using AES.
The basic design of this code is to segregate all the nasty crypto,
hash and hmac code into tpm2-sessions.c and export a usable API.
The API first of all starts off by gaining a
This separates out the old tpm_buf_... handling functions from static
inlines into tpm.h and makes them their own tpm-buf.c file. It also
adds handling for tpm2b structures and also incremental pointer
advancing parsers.
Signed-off-by: James Bottomley
---
v2: added this patch to separate out
By now, everybody knows we have a problem with the TPM2_RS_PW easy
button on TPM2 in that transactions on the TPM bus can be intercepted
and altered. The way to fix this is to use real sessions for HMAC
capabilities to ensure integrity and to use parameter and response
encryption to ensure
On 21 October 2018 at 11:00, James Bottomley
wrote:
> On October 21, 2018 9:58:04 AM GMT, Ard Biesheuvel
> wrote:
>>On 21 October 2018 at 10:07, James Bottomley
>> wrote:
>>> On Sun, 2018-10-21 at 09:05 +0200, Ard Biesheuvel wrote:
(+ James)
>>>
>>> Thanks!
>>>
On 20 October 2018 at
On October 21, 2018 9:58:04 AM GMT, Ard Biesheuvel
wrote:
>On 21 October 2018 at 10:07, James Bottomley
> wrote:
>> On Sun, 2018-10-21 at 09:05 +0200, Ard Biesheuvel wrote:
>>> (+ James)
>>
>> Thanks!
>>
>>> On 20 October 2018 at 01:01, Dmitry Eremin-Solenikov
>>> wrote:
>>> >
On 21 October 2018 at 10:07, James Bottomley
wrote:
> On Sun, 2018-10-21 at 09:05 +0200, Ard Biesheuvel wrote:
>> (+ James)
>
> Thanks!
>
>> On 20 October 2018 at 01:01, Dmitry Eremin-Solenikov
>> wrote:
>> > crypto_cfb_decrypt_segment() incorrectly XOR'ed generated keystream
>> > with
>> > IV,
On Sun, 2018-10-21 at 09:05 +0200, Ard Biesheuvel wrote:
> (+ James)
Thanks!
> On 20 October 2018 at 01:01, Dmitry Eremin-Solenikov
> wrote:
> > crypto_cfb_decrypt_segment() incorrectly XOR'ed generated keystream
> > with
> > IV, rather than with data stream, resulting in incorrect
> >
(+ James)
On 20 October 2018 at 01:01, Dmitry Eremin-Solenikov
wrote:
> Add AES128/192/256-CFB testvectors from NIST SP800-38A.
>
> Signed-off-by: Dmitry Eremin-Solenikov
> Cc: sta...@vger.kernel.org
> Signed-off-by: Dmitry Eremin-Solenikov
> ---
> crypto/tcrypt.c | 5
>
Hi Herbert,
I'm sorry for notifying just now, but this patch set should be applies on top of
"crypto: ccree: add CryptoCell 713 baseline support" patch set by Gilad
Ben-Yossef
Hence failures reported by kbuild test robot .
> -Original Message-
> From: Gilad Ben-Yossef
> Sent: Thursday,
(+ James)
On 20 October 2018 at 01:01, Dmitry Eremin-Solenikov
wrote:
> crypto_cfb_decrypt_segment() incorrectly XOR'ed generated keystream with
> IV, rather than with data stream, resulting in incorrect decryption.
> Test vectors will be added in the next patch.
>
> Signed-off-by: Dmitry
On 20 October 2018 at 04:39, Eric Biggers wrote:
> On Fri, Oct 19, 2018 at 05:54:12PM +0800, Ard Biesheuvel wrote:
>> On 19 October 2018 at 13:41, Ard Biesheuvel
>> wrote:
>> > On 18 October 2018 at 12:37, Eric Biggers wrote:
>> >> From: Eric Biggers
>> >>
>> >> Make the ARM scalar AES
crypto_cfb_decrypt_segment() incorrectly XOR'ed generated keystream with
IV, rather than with data stream, resulting in incorrect decryption.
Test vectors will be added in the next patch.
Signed-off-by: Dmitry Eremin-Solenikov
Cc: sta...@vger.kernel.org
---
crypto/cfb.c | 2 +-
1 file changed,
Add AES128/192/256-CFB testvectors from NIST SP800-38A.
Signed-off-by: Dmitry Eremin-Solenikov
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Eremin-Solenikov
---
crypto/tcrypt.c | 5
crypto/testmgr.c | 7 +
crypto/testmgr.h | 76
On Fri, Oct 19, 2018 at 05:54:12PM +0800, Ard Biesheuvel wrote:
> On 19 October 2018 at 13:41, Ard Biesheuvel wrote:
> > On 18 October 2018 at 12:37, Eric Biggers wrote:
> >> From: Eric Biggers
> >>
> >> Make the ARM scalar AES implementation closer to constant-time by
> >> disabling interrupts
On Fri, Oct 19, 2018 at 01:41:35PM +0800, Ard Biesheuvel wrote:
> On 18 October 2018 at 12:37, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Make the ARM scalar AES implementation closer to constant-time by
> > disabling interrupts and prefetching the tables into L1 cache. This is
> >
On 19 October 2018 at 13:41, Ard Biesheuvel wrote:
> On 18 October 2018 at 12:37, Eric Biggers wrote:
>> From: Eric Biggers
>>
>> Make the ARM scalar AES implementation closer to constant-time by
>> disabling interrupts and prefetching the tables into L1 cache. This is
>> feasible because due
On 18 October 2018 at 12:37, Eric Biggers wrote:
> From: Eric Biggers
>
> Make the ARM scalar AES implementation closer to constant-time by
> disabling interrupts and prefetching the tables into L1 cache. This is
> feasible because due to ARM's "free" rotations, the main tables are only
> 1024
From: Eric Biggers
Make the ARM scalar AES implementation closer to constant-time by
disabling interrupts and prefetching the tables into L1 cache. This is
feasible because due to ARM's "free" rotations, the main tables are only
1024 bytes instead of the usual 4096 used by most AES
From: Eric Biggers
In the "aes-fixed-time" AES implementation, disable interrupts while
accessing the S-box, in order to make cache-timing attacks more
difficult. Previously it was possible for the CPU to be interrupted
while the S-box was loaded into L1 cache, potentially evicting the
This series makes the "aes-fixed-time" and "aes-arm" implementations of
AES more resistant to cache-timing attacks.
Note that even after these changes, the implementations still aren't
necessarily guaranteed to be constant-time; see
https://cr.yp.to/antiforgery/cachetiming-20050414.pdf for a
Hi Eric,
On 17 October 2018 at 14:18, Eric Biggers wrote:
> From: Eric Biggers
>
> In the "aes-fixed-time" AES implementation, disable interrupts while
> accessing the S-box, in order to make cache-timing attacks more
> difficult. Previously it was possible for the CPU to be interrupted
>
Hi Eric,
Thanks for looking into this.
On 17 October 2018 at 14:18, Eric Biggers wrote:
> From: Eric Biggers
>
> Make the ARM scalar AES implementation closer to constant-time by
> disabling interrupts and prefetching the tables into L1 cache. This is
> feasible because due to ARM's "free"
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: a1c6fd4308d37f072e939a2782f24214115fc7e8
commit: 944585a64f5e37d11ff274a905304b565a88e147 [97/126] crypto: x86/aes-ni -
remove special handling of AES in PCBC mode
config:
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: a1c6fd4308d37f072e939a2782f24214115fc7e8
commit: 944585a64f5e37d11ff274a905304b565a88e147 [97/126] crypto: x86/aes-ni -
remove special handling of AES in PCBC mode
config:
On Wed, Oct 10, 2018 at 02:26:48PM +0300, Horia Geantă wrote:
> Previously, a tree-wide change added SPDX license identifiers to
> files lacking licensing information:
> b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to files
> with no license")
>
> To be consistent update
From: Eric Biggers
Make the ARM scalar AES implementation closer to constant-time by
disabling interrupts and prefetching the tables into L1 cache. This is
feasible because due to ARM's "free" rotations, the main tables are only
1024 bytes instead of the usual 4096 used by most AES
This series makes the "aes-fixed-time" and "aes-arm" implementations of
AES more resistant to cache-timing attacks.
Note that even after these changes, the implementations still aren't
necessarily guaranteed to be constant-time; see
https://cr.yp.to/antiforgery/cachetiming-20050414.pdf for a
From: Eric Biggers
In the "aes-fixed-time" AES implementation, disable interrupts while
accessing the S-box, in order to make cache-timing attacks more
difficult. Previously it was possible for the CPU to be interrupted
while the S-box was loaded into L1 cache, potentially evicting the
Hi Ard,
On Thu, Oct 04, 2018 at 08:55:14AM +0200, Ard Biesheuvel wrote:
> Hi Eric,
>
> On 4 October 2018 at 06:07, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > The generic constant-time AES implementation is supposed to preload the
> > AES S-box into the CPU's L1 data cache. But, an
Did you get my email from last week?
Let me know if you have photos for cutting out or retouching?
We are an image team who can do editing for your the web store photos,
industry photos or portrait photos.
Send photos, we will do testing for you to check quality.
Waiting for your reply soon.
Hello, all:
I have a request to add this list to be archived at lore.kernel.org. For
that to happen, I need to collect a complete (or as complete as
possible) archive of previous messages. If you've been subscribed to
this list for a long time and have an mbox or maildir archive of
messages
On Thu, Oct 11, 2018 at 02:10:42PM +0300, Dan Carpenter wrote:
> Hello Corentin Labbe,
>
> The patch cac5818c25d0: "crypto: user - Implement a generic crypto
> statistics" from Sep 19, 2018, leads to the following static checker
> warning:
>
> crypto/crypto_user_stat.c:53
Hello my dear.
Did you receive my email message to you? Please, get back to me ASAP as the
matter is becoming late. Expecting your urgent response.
Sean.
On Mon, Oct 08, 2018 at 01:16:59PM +0200, Ard Biesheuvel wrote:
> Commit 2e5d2f33d1db ("crypto: arm64/aes-blk - improve XTS mask handling")
> optimized away some reloads of the XTS mask vector, but failed to take
> into account that calls into the XTS en/decrypt routines will take a
> slightly
On Thu, Oct 11, 2018 at 01:49:48AM +, Wei Yongjun wrote:
> Fixes the following sparse warnings:
>
> drivers/crypto/mxs-dcp.c:39:15: warning:
> symbol 'sha1_null_hash' was not declared. Should it be static?
> drivers/crypto/mxs-dcp.c:43:15: warning:
> symbol 'sha256_null_hash' was not
On Sun, Oct 07, 2018 at 01:58:10PM +0200, Michael Schupikov wrote:
> After allocation, output and decomp_output both point to memory chunks of
> size COMP_BUF_SIZE. Then, only the first bytes are zeroed out using
> sizeof(COMP_BUF_SIZE) as parameter to memset(), because
> sizeof(COMP_BUF_SIZE)
On Fri, Oct 05, 2018 at 06:42:44AM +, YueHaibing wrote:
> Remove .owner field if calls are used which set it automatically
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
>
> Signed-off-by: YueHaibing
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page:
On Fri, Oct 05, 2018 at 06:43:27AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/crypto/chelsio/chtls/chtls_cm.c: In function 'chtls_disconnect':
> drivers/crypto/chelsio/chtls/chtls_cm.c:408:21: warning:
> variable 'csk' set but not used
Hello Corentin Labbe,
The patch cac5818c25d0: "crypto: user - Implement a generic crypto
statistics" from Sep 19, 2018, leads to the following static checker
warning:
crypto/crypto_user_stat.c:53 crypto_report_aead()
warn: check that 'raead' doesn't leak information (struct has
Fixes the following sparse warnings:
drivers/crypto/mxs-dcp.c:39:15: warning:
symbol 'sha1_null_hash' was not declared. Should it be static?
drivers/crypto/mxs-dcp.c:43:15: warning:
symbol 'sha256_null_hash' was not declared. Should it be static?
Fixes: c709eebaf5c5 ("crypto: mxs-dcp - Fix SHA
Previously, a tree-wide change added SPDX license identifiers to
files lacking licensing information:
b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to files
with no license")
To be consistent update the rest of the files:
-files with license specified by means of
Lieber Freund,
Ich bin Herr Tayeb Souami, New Jersey, Vereinigte Staaten von Amerika, der
Mega-Gewinner von $ 315million In Mega Millions Jackpot, spende ich an 5
zufällige Personen, wenn Sie diese E-Mail erhalten, dann wurde Ihre E-Mail nach
einem Spinball ausgewählt.Ich habe den größten
On 9 October 2018 at 05:47, Eric Biggers wrote:
> Hi Ard,
>
> On Mon, Oct 08, 2018 at 11:15:53PM +0200, Ard Biesheuvel wrote:
>> On ARM v6 and later, we define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
>> because the ordinary load/store instructions (ldr, ldrh, ldrb) can
>> tolerate any misalignment
On 9 October 2018 at 05:34, Eric Biggers wrote:
> Hi Ard,
>
> On Mon, Oct 08, 2018 at 11:15:52PM +0200, Ard Biesheuvel wrote:
>> On ARM v6 and later, we define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
>> because the ordinary load/store instructions (ldr, ldrh, ldrb) can
>> tolerate any misalignment
Hi Ard,
On Mon, Oct 08, 2018 at 11:15:53PM +0200, Ard Biesheuvel wrote:
> On ARM v6 and later, we define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> because the ordinary load/store instructions (ldr, ldrh, ldrb) can
> tolerate any misalignment of the memory address. However, load/store
> double and
Hi Ard,
On Mon, Oct 08, 2018 at 11:15:52PM +0200, Ard Biesheuvel wrote:
> On ARM v6 and later, we define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> because the ordinary load/store instructions (ldr, ldrh, ldrb) can
> tolerate any misalignment of the memory address. However, load/store
> double and
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS behaves a bit counterintuitively
on ARM: we set it for architecture revisions v6 and up, which support
any alignment for load/store instructions that operate on bytes, half
words or words. However, load/store double word and load store multiple
instructions
On ARM v6 and later, we define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
because the ordinary load/store instructions (ldr, ldrh, ldrb) can
tolerate any misalignment of the memory address. However, load/store
double and load/store multiple instructions (ldrd, ldm) may still only
be used on memory
On ARM v6 and later, we define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
because the ordinary load/store instructions (ldr, ldrh, ldrb) can
tolerate any misalignment of the memory address. However, load/store
double and load/store multiple instructions (ldrd, ldm) may still only
be used on memory
On ARM v6 and later, we define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
because the ordinary load/store instructions (ldr, ldrh, ldrb) can
tolerate any misalignment of the memory address. However, load/store
double and load/store multiple instructions (ldrd, ldm) may still only
be used on memory
Commit 2e5d2f33d1db ("crypto: arm64/aes-blk - improve XTS mask handling")
optimized away some reloads of the XTS mask vector, but failed to take
into account that calls into the XTS en/decrypt routines will take a
slightly different code path if a single block of input is split across
different
On Fri, Oct 05, 2018 at 10:13:06AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> aesni-intel_glue.c still calls crypto_fpu_init() and crypto_fpu_exit()
> to register/unregister the "fpu" template. But these functions don't
> exist anymore, causing a build error. Remove the calls to them.
On Tue, Oct 02, 2018 at 10:22:15PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> In the new arm64 CTS-CBC implementation, return an error code rather
> than crashing on inputs shorter than AES_BLOCK_SIZE bytes. Also set
> cra_blocksize to AES_BLOCK_SIZE (like is done in the cts template)
On Tue, Oct 02, 2018 at 07:01:46PM +, Leonard Crestez wrote:
> The mxs-dcp driver currently fails to probe on imx6. Fix the whole thing
> by porting a cleaned/squashed version of fixes carried in the NXP vendor
> tree.
>
> Tested with "modprobe tcrypt" and
On Mon, Oct 01, 2018 at 10:36:36AM +0200, Ard Biesheuvel wrote:
> Some bug fixes for issues that I stumbled upon while working on other
> stuff.
>
> Changes since v1:
> - add Ondrej's ack to #1
> - simplify #2 and drop unrelated performance tweak
>
> Ard Biesheuvel (2):
> crypto: morus/generic
Franck LENORMAND wrote:
> The CAAM driver has multiple configuration and all are listed
> in the crypto menu.
>
> This patch create a menu dedicated to the Freescale CAAM driver.
>
> Signed-off-by: Franck LENORMAND
> ---
> drivers/crypto/caam/Kconfig | 4
> 1 file changed, 4 insertions(+)
I am contacting you because my office noticed you have an unclaimed Inheritance
contact me immediately for further details.
Hello
i need your help to invest in your region, please can you assist me?
On Fri, Oct 05, 2018 at 07:16:13PM +0200, Ard Biesheuvel wrote:
> On 5 October 2018 at 19:13, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > aesni-intel_glue.c still calls crypto_fpu_init() and crypto_fpu_exit()
> > to register/unregister the "fpu" template. But these functions don't
> >
On 5 October 2018 at 19:13, Eric Biggers wrote:
> From: Eric Biggers
>
> aesni-intel_glue.c still calls crypto_fpu_init() and crypto_fpu_exit()
> to register/unregister the "fpu" template. But these functions don't
> exist anymore, causing a build error. Remove the calls to them.
>
> Fixes:
From: Eric Biggers
aesni-intel_glue.c still calls crypto_fpu_init() and crypto_fpu_exit()
to register/unregister the "fpu" template. But these functions don't
exist anymore, causing a build error. Remove the calls to them.
Fixes: 944585a64f5e ("crypto: x86/aes-ni - remove special handling of
On 5 October 2018 at 04:29, Herbert Xu wrote:
> On Wed, Sep 26, 2018 at 11:51:59AM +0200, Ard Biesheuvel wrote:
>> Arnd reports that with Kees's latest VLA patches applied, the HMAC
>> handling in the QAT driver uses a worst case estimate of 160 bytes
>> for the SHA blocksize, allowing the
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/crypto/chelsio/chtls/chtls_cm.c: In function 'chtls_disconnect':
drivers/crypto/chelsio/chtls/chtls_cm.c:408:21: warning:
variable 'csk' set but not used [-Wunused-but-set-variable]
drivers/crypto/chelsio/chtls/chtls_cm.c: In function
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: YueHaibing
---
drivers/crypto/axis/artpec6_crypto.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/axis/artpec6_crypto.c
On Sun, Sep 30, 2018 at 09:51:16PM +0200, Ard Biesheuvel wrote:
> Due to an unfortunate interaction between commit fbe1a850b3b1
> ("crypto: lrw - Fix out-of bounds access on counter overflow") and
> commit c778f96bf347 ("crypto: lrw - Optimize tweak computation"),
> we ended up with a version of
On Wed, Sep 26, 2018 at 11:51:59AM +0200, Ard Biesheuvel wrote:
> Arnd reports that with Kees's latest VLA patches applied, the HMAC
> handling in the QAT driver uses a worst case estimate of 160 bytes
> for the SHA blocksize, allowing the compiler to determine the size
> of the stack frame at
On Wed, Sep 26, 2018 at 02:09:23AM +, Wei Yongjun wrote:
> Fixes the following sparse warning:
>
> drivers/crypto/ccp/psp-dev.c:444:5: warning:
> symbol 'sev_get_firmware' was not declared. Should it be static?
>
> Fixes: e93720606efd ("crypto: ccp - Allow SEV firmware to be chosen based on
On Mon, Sep 24, 2018 at 02:48:16PM +0200, Ard Biesheuvel wrote:
> For historical reasons, the AES-NI based implementation of the PCBC
> chaining mode uses a special FPU chaining mode wrapper template to
> amortize the FPU start/stop overhead over multiple blocks.
>
> When this FPU wrapper was
Hi Eric,
On 4 October 2018 at 06:07, Eric Biggers wrote:
> From: Eric Biggers
>
> The generic constant-time AES implementation is supposed to preload the
> AES S-box into the CPU's L1 data cache. But, an interrupt handler can
> run on the CPU and muck with the cache. Worse, on preemptible
From: Eric Biggers
The generic constant-time AES implementation is supposed to preload the
AES S-box into the CPU's L1 data cache. But, an interrupt handler can
run on the CPU and muck with the cache. Worse, on preemptible kernels
the process can even be preempted and moved to a different CPU.
On 3 October 2018 at 07:22, Eric Biggers wrote:
> From: Eric Biggers
>
> In the new arm64 CTS-CBC implementation, return an error code rather
> than crashing on inputs shorter than AES_BLOCK_SIZE bytes. Also set
> cra_blocksize to AES_BLOCK_SIZE (like is done in the cts template) to
> indicate
From: Eric Biggers
In the new arm64 CTS-CBC implementation, return an error code rather
than crashing on inputs shorter than AES_BLOCK_SIZE bytes. Also set
cra_blocksize to AES_BLOCK_SIZE (like is done in the cts template) to
indicate the minimum input size.
Fixes: dd597fb33ff0 ("crypto:
On Mon, Oct 1, 2018 at 10:36 AM Ard Biesheuvel
wrote:
> Use the correct __le32 annotation and accessors to perform the
> single round of AES encryption performed inside the AEGIS transform.
> Otherwise, tcrypt reports:
>
> alg: aead: Test 1 failed on encryption for aegis128-generic
>
The CAAM driver has multiple configuration and all are listed
in the crypto menu.
This patch create a menu dedicated to the Freescale CAAM driver.
Signed-off-by: Franck LENORMAND
---
drivers/crypto/caam/Kconfig | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/crypto/caam/Kconfig
Omit the endian swabbing when folding the lengths of the assoc and
crypt input buffers into the state to finalize the tag. This is not
necessary given that the memory representation of the state is in
machine native endianness already.
This fixes an error reported by tcrypt running on a big
Use the correct __le32 annotation and accessors to perform the
single round of AES encryption performed inside the AEGIS transform.
Otherwise, tcrypt reports:
alg: aead: Test 1 failed on encryption for aegis128-generic
: 6c 25 25 4a 3c 10 1d 27 2b c1 d4 84 9a ef 7f 6e
alg: aead:
Some bug fixes for issues that I stumbled upon while working on other
stuff.
Changes since v1:
- add Ondrej's ack to #1
- simplify #2 and drop unrelated performance tweak
Ard Biesheuvel (2):
crypto: morus/generic - fix for big endian systems
crypto: aegis/generic - fix for big endian systems
On Mon, Oct 1, 2018 at 10:01 AM Ard Biesheuvel
wrote:
> On 1 October 2018 at 10:00, Ondrej Mosnacek wrote:
> > On Sun, Sep 30, 2018 at 1:14 PM Ard Biesheuvel
> > wrote:
> >> On 30 September 2018 at 10:58, Ard Biesheuvel
> >> wrote:
> >> > Use the correct __le32 annotation and accessors to
On 1 October 2018 at 10:00, Ondrej Mosnacek wrote:
> On Sun, Sep 30, 2018 at 1:14 PM Ard Biesheuvel
> wrote:
>> On 30 September 2018 at 10:58, Ard Biesheuvel
>> wrote:
>> > Use the correct __le32 annotation and accessors to perform the
>> > single round of AES encryption performed inside the
On Sun, Sep 30, 2018 at 1:14 PM Ard Biesheuvel
wrote:
> On 30 September 2018 at 10:58, Ard Biesheuvel
> wrote:
> > Use the correct __le32 annotation and accessors to perform the
> > single round of AES encryption performed inside the AEGIS transform.
> > Otherwise, tcrypt reports:
> >
> >
On 1 October 2018 at 09:50, Ondrej Mosnacek wrote:
> Hi Ard,
>
> On Sun, Sep 30, 2018 at 10:59 AM Ard Biesheuvel
> wrote:
>> Use the correct __le32 annotation and accessors to perform the
>> single round of AES encryption performed inside the AEGIS transform.
>> Otherwise, tcrypt reports:
>>
>>
Hi Ard,
On Sun, Sep 30, 2018 at 10:59 AM Ard Biesheuvel
wrote:
> Use the correct __le32 annotation and accessors to perform the
> single round of AES encryption performed inside the AEGIS transform.
> Otherwise, tcrypt reports:
>
> alg: aead: Test 1 failed on encryption for aegis128-generic
>
On 1 October 2018 at 09:26, Ondrej Mosnacek wrote:
> On Sun, Sep 30, 2018 at 10:59 AM Ard Biesheuvel
> wrote:
>> Omit the endian swabbing when folding the lengths of the assoc and
>> crypt input buffers into the state to finalize the tag. This is not
>> necessary given that the memory
On Sun, Sep 30, 2018 at 10:59 AM Ard Biesheuvel
wrote:
> Omit the endian swabbing when folding the lengths of the assoc and
> crypt input buffers into the state to finalize the tag. This is not
> necessary given that the memory representation of the state is in
> machine native endianness
On Sun, Sep 30, 2018 at 9:51 PM Ard Biesheuvel
wrote:
> Due to an unfortunate interaction between commit fbe1a850b3b1
> ("crypto: lrw - Fix out-of bounds access on counter overflow") and
> commit c778f96bf347 ("crypto: lrw - Optimize tweak computation"),
> we ended up with a version of
Due to an unfortunate interaction between commit fbe1a850b3b1
("crypto: lrw - Fix out-of bounds access on counter overflow") and
commit c778f96bf347 ("crypto: lrw - Optimize tweak computation"),
we ended up with a version of next_index() that always returns 127.
Fixes: c778f96bf347 ("crypto: lrw
On 30 September 2018 at 10:58, Ard Biesheuvel wrote:
> Use the correct __le32 annotation and accessors to perform the
> single round of AES encryption performed inside the AEGIS transform.
> Otherwise, tcrypt reports:
>
> alg: aead: Test 1 failed on encryption for aegis128-generic
> :
Use the correct __le32 annotation and accessors to perform the
single round of AES encryption performed inside the AEGIS transform.
Otherwise, tcrypt reports:
alg: aead: Test 1 failed on encryption for aegis128-generic
: 6c 25 25 4a 3c 10 1d 27 2b c1 d4 84 9a ef 7f 6e
alg: aead:
Omit the endian swabbing when folding the lengths of the assoc and
crypt input buffers into the state to finalize the tag. This is not
necessary given that the memory representation of the state is in
machine native endianness already.
This fixes an error reported by tcrypt running on a big
101 - 200 of 29368 matches
Mail list logo
