On Fri, 2019-10-04 at 13:11 -0700, Jerry Snitselaar wrote:
> On Fri Oct 04 19, Jerry Snitselaar wrote:
> > On Fri Oct 04 19, James Bottomley wrote:
> > > On Fri, 2019-10-04 at 11:33 -0700, Jerry Snitselaar wrote:
> > > > On Fri Oct 04 19, James Bottomley wrote:
> > > > > On Fri, 2019-10-04 at 21:22
Op 04-10-2019 om 21:37 schreef Eric Biggers:
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 - Conv
On Fri Oct 04 19, Jerry Snitselaar wrote:
On Fri Oct 04 19, James Bottomley wrote:
On Fri, 2019-10-04 at 11:33 -0700, Jerry Snitselaar wrote:
On Fri Oct 04 19, James Bottomley wrote:
On Fri, 2019-10-04 at 21:22 +0300, Jarkko Sakkinen wrote:
> On Thu, Oct 03, 2019 at 04:59:37PM -0700, James Bot
On Fri Oct 04 19, James Bottomley wrote:
On Fri, 2019-10-04 at 11:33 -0700, Jerry Snitselaar wrote:
On Fri Oct 04 19, James Bottomley wrote:
> On Fri, 2019-10-04 at 21:22 +0300, Jarkko Sakkinen wrote:
> > On Thu, Oct 03, 2019 at 04:59:37PM -0700, James Bottomley wrote:
> > > I think the principl
> From: linux-integrity-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Jarkko Sakkinen
> Sent: Friday, October 4, 2019 2:27 PM
> Subject: EXT: Re: [PATCH] KEYS: asym_tpm: Switch to get_random_bytes()
>
> If you are able to call tpm_get_random(), the driver has already registered
> TP
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
> > >
In crypto_reportstat, a new skb is created by nlmsg_new(). This skb is
leaked if crypto_reportstat_alg() fails. Required release for skb is
added.
Fixes: cac5818c25d0 ("crypto: user - Implement a generic crypto statistics")
Signed-off-by: Navid Emamdoost
---
crypto/crypto_user_stat.c | 4 +++-
1
In crypto_report, a new skb is created via nlmsg_new(). This skb should
be released if crypto_report_alg() fails.
Fixes: a38f7907b926 ("crypto: Add userspace configuration API")
Signed-off-by: Navid Emamdoost
---
crypto/crypto_user_base.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
On Fri, Oct 04, 2019 at 11:35:29AM +0530, Sumit Garg wrote:
> Hi Jarkko,
>
> On Wed, 25 Sep 2019 at 06:41, Jarkko Sakkinen
> wrote:
> >
> > On Wed, Sep 18, 2019 at 11:53:08AM +0530, Sumit Garg wrote:
> > > No worries :). I will send next version of patch-set.
> > >
> > > FYI, I will be travelling
On Fri, 2019-10-04 at 11:33 -0700, Jerry Snitselaar wrote:
> On Fri Oct 04 19, James Bottomley wrote:
> > On Fri, 2019-10-04 at 21:22 +0300, Jarkko Sakkinen wrote:
> > > On Thu, Oct 03, 2019 at 04:59:37PM -0700, James Bottomley wrote:
> > > > I think the principle of using multiple RNG sources for
On Fri Oct 04 19, James Bottomley wrote:
On Fri, 2019-10-04 at 21:22 +0300, Jarkko Sakkinen wrote:
On Thu, Oct 03, 2019 at 04:59:37PM -0700, James Bottomley wrote:
> I think the principle of using multiple RNG sources for strong keys
> is a sound one, so could I propose a compromise: We have a
> > There are many good reasons for wanting the keys to be based on the
> > TPM generator. As the source for the kernel random number generator
> > itself says, some systems lack good randomness at startup, and systems
> > should preserve and reload the pool across shutdown and startup.
> > There
On Fri, Oct 04, 2019 at 01:26:58PM +, Safford, David (GE Global Research,
US) wrote:
> As the original author of trusted keys, let me make a few comments.
> First, trusted keys were specifically implemented and *documented* to
> use the TPM to both generate and seal keys. Its kernel documentat
On Fri, 2019-10-04 at 21:22 +0300, Jarkko Sakkinen wrote:
> On Thu, Oct 03, 2019 at 04:59:37PM -0700, James Bottomley wrote:
> > I think the principle of using multiple RNG sources for strong keys
> > is a sound one, so could I propose a compromise: We have a tpm
> > subsystem random number genera
On Thu, Oct 03, 2019 at 04:59:37PM -0700, James Bottomley wrote:
> I think the principle of using multiple RNG sources for strong keys is
> a sound one, so could I propose a compromise: We have a tpm subsystem
> random number generator that, when asked for random bytes first
> extracts bytes fro
On Thu, Oct 03, 2019 at 06:08:11PM -0400, Mimi Zohar wrote:
> > At the time when trusted keys was introduced I'd say that it was a wrong
> > design decision and badly implemented code. But you are right in that as
> > far that code is considered it would unfair to speak of a regression.
> >
> > as
On Wed, Oct 02, 2019 at 07:54:58AM +0200, Maxime Ripard wrote:
> On Tue, Oct 01, 2019 at 08:41:33PM +0200, Corentin Labbe wrote:
> > This patch adds documentation for Device-Tree bindings for the
> > Crypto Engine cryptographic accelerator driver.
> >
> > Signed-off-by: Corentin Labbe
> > ---
> >
when libkcapi test is executed using HW accelerator, cipher operation
return -74.Since af_alg_async_cb->ki_complete treat err as unsigned int,
libkcapi receive 429467222 even though it expect -ve value.
Hence its required to cast resultlen to int so that proper
error is returned to libkcapi.
AEA
On Wed, Oct 02, 2019 at 12:35:06PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Tue, Oct 01, 2019 at 08:41:32PM +0200, Corentin Labbe wrote:
> > + /* CTS and recent CE (H6) need length in bytes, in word otherwise */
> > + if (ce->variant->model == CE_v2)
> > + cet->t_dlen = areq->cryptle
On Sat, Sep 14, 2019 at 02:02:53PM -0700, Tony Lindgren wrote:
> Hi all,
>
> Here are fixes and improvments for omap3-rom-rng that's been broken for
> a while.
>
> The first four patches get it working, and then the last two patches add
> support for runtime PM.
>
> I did not add Sebastian's ack
On Thu, Sep 26, 2019 at 03:26:29PM +0300, Iuliana Prodan wrote:
> The mapped_{src,dst}_nents _returned_ from the dma_map_sg
> call (which could be less than src/dst_nents) have to be
> used to generate the job descriptors.
>
> Signed-off-by: Iuliana Prodan
> ---
> Changes since v1:
> - updated, w
On Tue, Sep 24, 2019 at 10:08:30AM +0200, Corentin Labbe wrote:
> Hello
>
> This serie enables power management in the sun4i-ss driver.
>
> Regards
>
> Changes since v2 (
> https://lore.kernel.org/linux-arm-kernel/20190919051035.4111-2-clabbe.montj...@gmail.com/T/
> ):
> - depends on PM
> - fu
On Thu, Sep 19, 2019 at 10:04:28PM +0200, Christophe JAILLET wrote:
> Use '__skb_put_data()' instead of rewritting it.
> This improves readability.
>
> Signed-off-by: Christophe JAILLET
> ---
> drivers/crypto/chelsio/chtls/chtls_io.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch
On Fri, Sep 20, 2019 at 06:35:19AM +, Phani Kiran Hemadri wrote:
> This patch fixes assigning UCD block number of Asymmetric crypto
> firmware to AE cores of CNN55XX device.
>
> Fixes: a7268c4d4205 ("crypto: cavium/nitrox - Add support for loading
> asymmetric crypto firmware")
> Signed-off-b
On Thu, Sep 19, 2019 at 11:04:48AM -0500, Navid Emamdoost wrote:
> Release all allocated memory if sha type is invalid:
> In ccp_run_sha_cmd, if the type of sha is invalid, the allocated
> hmac_buf should be released.
>
> v2: fix the goto.
>
> Signed-off-by: Navid Emamdoost
> ---
> drivers/cryp
On Thu, Sep 19, 2019 at 06:33:02PM -0300, Eneas U de Queiroz wrote:
> Set the CRYPTO_ALG_KERN_DRIVER_ONLY flag to all algorithms exposed by
> the qce driver, since they are all hardware accelerated, accessible
> through a kernel driver only, and not available directly to userspace.
>
> Signed-off-
On Thu, Sep 19, 2019 at 04:09:06PM +0200, Arnd Bergmann wrote:
> To avoid missing arm64 specific warnings that get introduced
> in this driver, allow compile-testing on all 64-bit architectures.
>
> The only actual arm64 specific code in this driver is an open-
> coded 128 bit MMIO write. On non-a
On Wed, Sep 18, 2019 at 09:19:18AM +0200, Markus Elfring wrote:
> From: Markus Elfring
> Date: Wed, 18 Sep 2019 09:09:22 +0200
>
> Simplify this function implementation by using a known wrapper function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elf
On Wed, Sep 18, 2019 at 09:44:06AM +0200, Markus Elfring wrote:
> From: Markus Elfring
> Date: Wed, 18 Sep 2019 09:34:11 +0200
>
> Simplify this function implementation by using a known wrapper function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elf
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 Wed, Sep 18, 2019 at 09:39:34AM +, Nagadheeraj Rottela wrote:
> Add support to get microcode information in VF from PF via mailbox
> message.
>
> Signed-off-by: Nagadheeraj Rottela
> Reviewed-by: Srikanth Jampala
> ---
> drivers/crypto/cavium/nitrox/nitrox_dev.h | 15 +++
> d
On Wed, Sep 18, 2019 at 12:41:26PM +0200, Pascal van Leeuwen wrote:
> This patch adds support for the EIP196, which is an EIP197 derivative
> that has no classification hardware and a simplified record cache.
>
> The patch has been tested with the eip196b-ie and eip197c-iewxkbc
> configurations on
Alexander E. Patrakov wrote:
> One should not say "ec can be NULL" and then dereference it.
> One cannot talk about the return value if the function returns void.
>
> Signed-off-by: Alexander E. Patrakov
> ---
> crypto/jitterentropy.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
On Wed, Sep 18, 2019 at 11:25:55PM +0200, Pascal van Leeuwen wrote:
> Extend driver support with chacha20, rfc7539(chacha20,poly1305) and
> rfc7539esp(chacha20,poly1305) ciphers.
> The patchset has been tested with the eip197c_iesb and eip197c_iewxkbc
> configurations on the Xilinx VCU118 developme
On Wed, Sep 18, 2019 at 08:42:38AM +0200, Pascal van Leeuwen wrote:
> This patchset adds support for the eip197f_iewc configuration that is
> currently being taped-out by a customer. It adds support for the 256 bit
> internal buswidth used by larger EIP197's as well as support for having
> less rin
On Tue, Sep 17, 2019 at 12:07:58PM +0200, Pascal van Leeuwen wrote:
> This patchset adds support for the rfc4106(gcm(aes)), rfc4543(gcm(aes))
> and rfc4309(ccm(aes)) ciphersuites intended for IPsec ESP acceleration.
>
> The patchset has been tested with the eip197c_iewxkbc configuration on the
> X
On Mon, Sep 16, 2019 at 06:42:06AM +, Nagadheeraj Rottela wrote:
> Check if device supports assoclen to solve hung task timeout error when
> extra tests are enabled. Return -EINVAL if assoclen is not supported.
> Check authsize to return -EINVAL if authentication tag size is invalid.
> Change b
On Tue, Sep 17, 2019 at 11:55:17AM +0200, Pascal van Leeuwen wrote:
> This patchset fixes some issues with the TRC RAM probing that caused
> instability (random failures) on the Macchiatobin board and incorrect
> configuration of the TRC for some other corner case RAM configuration.
>
> The patchs
On Tue, Sep 17, 2019 at 06:36:50AM +, Nagadheeraj Rottela wrote:
> Self test failures are due to wrong output IV. This patch fixes this
> issue by copying back output IV into skcipher request.
>
> Signed-off-by: Nagadheeraj Rottela
> Reviewed-by: Srikanth Jampala
> ---
> drivers/crypto/cavi
On Fri, Oct 4, 2019 at 5:36 PM Ard Biesheuvel wrote:
> > Just checking for Cortex-A7 being the boot CPU is probably
> > sufficient, that takes care of the common case of all the
> > A7-only embedded chips that people definitely are going to care
> > about for a long time.
> >
>
> But do you agree
On Fri, 4 Oct 2019 at 17:24, Arnd Bergmann 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 CPU intensiv
On Fri, Sep 13, 2019 at 08:44:50PM +0200, Pascal van Leeuwen wrote:
> This patch adds support for the authenc(hmac(sha1),cbc(sm4)),
> authenc(hmac(sm3),cbc(sm4)), authenc(hmac(sha1),rfc3686(ctr(sm4))),
> and authenc(hmac(sm3),rfc3686(ctr(sm4))) aead ciphersuites.
> These are necessary to support IP
On Fri, Sep 13, 2019 at 10:04:43PM +0200, Pascal van Leeuwen wrote:
> This patchset adds the remaining authencs with DES or 3DES currently
> supported with vectors by testmgr.
>
> The patchset has been tested with the eip197c_iewxkbc configuration on the
> Xilinx VCU118 development boardi as well
On Fri, Sep 13, 2019 at 08:56:46PM +0200, Pascal van Leeuwen wrote:
> This patchset adds support for all flavours of sha3-xxx and hmac(sha3-xxx)
> ahash algorithms.
>
> The patchset has been tested with the eip197c_iewxkbc configuration on the
> Xilinx VCU118 development board, including the testm
On 04/10/2019 16:26, Herbert Xu wrote:
> On Thu, Sep 12, 2019 at 03:30:22PM +0200, Laurent Vivier wrote:
>>
>> @@ -496,19 +510,24 @@ int hwrng_register(struct hwrng *rng)
>> goto out_unlock;
>> }
>>
>> -if (old_rng && !rng->init) {
>> +new_rng = rng;
>> +kref
On Fri, Sep 13, 2019 at 07:36:18PM +0100, Ard Biesheuvel wrote:
> The next version of Clang will start policing compiler command line
> options, and will reject combinations of -march and -mfpu that it
> thinks are incompatible.
>
> This results in errors like
>
> clang-10: warning: ignoring ex
On Fri, Sep 13, 2019 at 05:20:35PM +0200, Pascal van Leeuwen wrote:
> Extend driver support with sm3 and hmac(sm3) ahash support.
> Also add GM/T 0042-2015 hmac(sm3) testvectors to the testmgr.
> The patchset has been tested with the eip197c_iewxkbc configuration
> on the Xilinx VCU118 development
On Fri, Sep 13, 2019 at 11:10:35AM +0200, Pascal van Leeuwen wrote:
> Extend driver support with ecb(sm4), cbc(sm4), ofb(sm4), cfb(sm4) and
> rfc3686(ctr(sm4)) skcipher algorithms.
> Also add ofb(sm4), cfb(sm4) and rfc3686(ctr(sm4)) testvectors to testmgr.
> The patchset has been tested with the ei
On Thu, Sep 12, 2019 at 12:01:47PM +0300, Tomer Maimon wrote:
> This patch set adds Random Number Generator (RNG) support
> for the Nuvoton NPCM Baseboard Management Controller (BMC).
>
> The RNG driver we use power consumption when the RNG
> is not required.
>
> The NPCM RNG driver tested on N
On Wed, Sep 11, 2019 at 12:18:58AM +0100, Ard Biesheuvel wrote:
> This series reimplements gcm(aes) for arm64 systems that support the
> AES and 64x64->128 PMULL/PMULL2 instructions. Patch #1 adds a test
> case and patch #2 updates the driver.
>
> Ard Biesheuvel (2):
> crypto: testmgr - add anot
On Tue, Sep 10, 2019 at 06:04:14AM +, Christophe Leroy wrote:
> When VMAP_STACK is selected, stack cannot be DMA-mapped.
> Therefore, the hash result has to be DMA-mapped in the request
> context and copied into areq->result at completion.
>
> Signed-off-by: Christophe Leroy
> ---
> drivers/
On Mon, Sep 09, 2019 at 01:13:05PM +0200, Pascal van Leeuwen wrote:
> This patchset adds support for the (AES) CBCMAC family of authentication
> algorithms: AES-CBCMAC, AES-XCBCMAC and AES-MAC
> It has been verified with a Xilinx PCIE FPGA board as well as the Marvell
> Armada A8K based Macchiatobi
On Mon, Sep 09, 2019 at 01:10:29PM +0200, Pascal van Leeuwen wrote:
> This patch adds support for the CRC32 "hash" algorithm
>
> Signed-off-by: Pascal van Leeuwen
> ---
> drivers/crypto/inside-secure/safexcel.c | 1 +
> drivers/crypto/inside-secure/safexcel.h | 2 +
> drivers/crypt
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 CPU intensive tasks are scheduled on big cores,
> where NEON performance is mu
On Fri, 4 Oct 2019 at 17:15, René van Dorst wrote:
>
> Hi Jason,
>
> Quoting "Jason A. Donenfeld" :
>
> > On Fri, Oct 4, 2019 at 4:44 PM Ard Biesheuvel
> > wrote:
> >> The round count is passed via the fifth function parameter, so it is
> >> already on the stack. Reloading it for every block does
Hi Jason,
Quoting "Jason A. Donenfeld" :
On Fri, Oct 4, 2019 at 4:44 PM Ard Biesheuvel
wrote:
The round count is passed via the fifth function parameter, so it is
already on the stack. Reloading it for every block doesn't sound like
a huge deal to me.
Please benchmark it to indicate that,
On Fri, 4 Oct 2019 at 16:59, Jason A. Donenfeld wrote:
>
> On Fri, Oct 4, 2019 at 4:44 PM Ard Biesheuvel
> wrote:
> > The round count is passed via the fifth function parameter, so it is
> > already on the stack. Reloading it for every block doesn't sound like
> > a huge deal to me.
>
> Please b
On Fri, 4 Oct 2019 at 16:55, Jason A. Donenfeld wrote:
>
> On Fri, Oct 4, 2019 at 4:53 PM Andy Lutomirski wrote:
> > I think it might be better to allow two different modules to export the
> > same symbol but only allow one of them to be loaded. Or use static calls.
>
> Static calls perform well
On Fri, Oct 4, 2019 at 4:44 PM Ard Biesheuvel wrote:
> The round count is passed via the fifth function parameter, so it is
> already on the stack. Reloading it for every block doesn't sound like
> a huge deal to me.
Please benchmark it to indicate that, if it really isn't a big deal. I
recall fi
On Fri, 4 Oct 2019 at 16:53, Andy Lutomirski wrote:
>
>
>
> > On Oct 4, 2019, at 6:52 AM, Ard Biesheuvel
> > wrote:
> >
> > On Fri, 4 Oct 2019 at 15:42, Jason A. Donenfeld wrote:
> >>
> >>> On Thu, Oct 03, 2019 at 10:43:29AM +0200, Ard Biesheuvel wrote:
> >>> On Wed, 2 Oct 2019 at 16:17, Ard B
On Fri, Oct 4, 2019 at 4:53 PM Andy Lutomirski wrote:
> I think it might be better to allow two different modules to export the same
> symbol but only allow one of them to be loaded. Or use static calls.
Static calls perform well and are well understood. This would be my preference.
> On Oct 4, 2019, at 6:52 AM, Ard Biesheuvel wrote:
>
> On Fri, 4 Oct 2019 at 15:42, Jason A. Donenfeld wrote:
>>
>>> On Thu, Oct 03, 2019 at 10:43:29AM +0200, Ard Biesheuvel wrote:
>>> On Wed, 2 Oct 2019 at 16:17, Ard Biesheuvel
>>> wrote:
>>> ...
In the future, I would
> On Oct 4, 2019, at 6:42 AM, Jason A. Donenfeld wrote:
>
> On Thu, Oct 03, 2019 at 10:43:29AM +0200, Ard Biesheuvel wrote:
>>> On Wed, 2 Oct 2019 at 16:17, Ard Biesheuvel
>>> wrote:
>>>
>> ...
>>>
>>> In the future, I would like to extend these interfaces to use static calls,
>>> so that
On Fri, 4 Oct 2019 at 16:38, Ard Biesheuvel wrote:
>
> On Fri, 4 Oct 2019 at 15:46, Jason A. Donenfeld wrote:
> >
> > On Wed, Oct 02, 2019 at 04:16:58PM +0200, Ard Biesheuvel wrote:
> > > This integrates the accelerated MIPS 32r2 implementation of ChaCha
> > > into both the API and library interf
On Fri, 4 Oct 2019 at 15:46, Jason A. Donenfeld wrote:
>
> On Wed, Oct 02, 2019 at 04:16:58PM +0200, Ard Biesheuvel wrote:
> > This integrates the accelerated MIPS 32r2 implementation of ChaCha
> > into both the API and library interfaces of the kernel crypto stack.
> >
> > The significance of thi
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 CPU intensive tasks are scheduled on big cores,
> where NEON performance is much
On Fri, Oct 4, 2019 at 4:23 PM Ard Biesheuvel wrote:
> > Did these changes make it into the existing tree?
>
> I'd like to keep Eric's code, but if it is really that much faster, we
> might drop it in arch/arm/lib so it supersedes the builtin code that
> /dev/random uses as well.
That was the ide
On Thu, Sep 12, 2019 at 03:30:22PM +0200, Laurent Vivier wrote:
>
> @@ -496,19 +510,24 @@ int hwrng_register(struct hwrng *rng)
> goto out_unlock;
> }
>
> - if (old_rng && !rng->init) {
> + new_rng = rng;
> + kref_get(&new_rng->ref);
> +out_unlock:
> +
On Fri, 4 Oct 2019 at 15:53, Jason A. Donenfeld wrote:
>
> On Wed, Oct 2, 2019 at 4:17 PM Ard Biesheuvel
> wrote:
> > Expose the accelerated NEON ChaCha routine directly as a symbol
> > export so that users of the ChaCha library can use it directly.
>
> Eric had some nice code for ChaCha for cer
On Wed, Oct 2, 2019 at 4:17 PM Ard Biesheuvel wrote:
> This is a followup to RFC 'crypto: wireguard with crypto API library
> interface'
> [0]. Since no objections were raised to my approach, I've proceeded to fix up
> some minor issues, and incorporate [most of] the missing MIPS code.
Could you
On Fri, 4 Oct 2019 at 16:01, Jason A. Donenfeld wrote:
>
> On Wed, Oct 02, 2019 at 04:17:11PM +0200, Ard Biesheuvel wrote:
> > +bool curve25519_arch(u8 out[CURVE25519_KEY_SIZE],
> > + const u8 scalar[CURVE25519_KEY_SIZE],
> > + const u8 point[CURVE25519_KEY_SIZE])
On Fri, 4 Oct 2019 at 16:03, Jason A. Donenfeld wrote:
>
> On Wed, Oct 02, 2019 at 04:17:13PM +0200, Ard Biesheuvel wrote:
> > Reimplement the library routines to perform chacha20poly1305 en/decryption
> > on scatterlists, without [ab]using the [deprecated] blkcipher interface,
> > which is rather
On Wed, Oct 02, 2019 at 04:17:13PM +0200, Ard Biesheuvel wrote:
> Reimplement the library routines to perform chacha20poly1305 en/decryption
> on scatterlists, without [ab]using the [deprecated] blkcipher interface,
> which is rather heavyweight and does things we don't really need.
>
> Instead, w
On Fri, 4 Oct 2019 at 15:57, Jason A. Donenfeld wrote:
>
> On Wed, Oct 02, 2019 at 04:17:07PM +0200, Ard Biesheuvel wrote:
> >- replace .c #includes with Kconfig based object selection
>
> Cool!
>
> > +config CRYPTO_ARCH_HAVE_LIB_CURVE25519
> > + tristate
> > +
> > +config CRYPTO_ARCH_
On Wed, Oct 02, 2019 at 04:17:11PM +0200, Ard Biesheuvel wrote:
> +bool curve25519_arch(u8 out[CURVE25519_KEY_SIZE],
> + const u8 scalar[CURVE25519_KEY_SIZE],
> + const u8 point[CURVE25519_KEY_SIZE])
> +{
> + if (!have_neon || !crypto_simd_usable())
> +
On Wed, Oct 02, 2019 at 04:17:07PM +0200, Ard Biesheuvel wrote:
>- replace .c #includes with Kconfig based object selection
Cool!
> +config CRYPTO_ARCH_HAVE_LIB_CURVE25519
> + tristate
> +
> +config CRYPTO_ARCH_HAVE_LIB_CURVE25519_BASE
> + bool
> +
> +config CRYPTO_LIB_CURVE25519
On Fri, 4 Oct 2019 at 15:36, Jason A. Donenfeld wrote:
>
> On Wed, Oct 02, 2019 at 04:16:55PM +0200, Ard Biesheuvel wrote:
> > Wire the existing x86 SIMD ChaCha code into the new ChaCha library
> > interface.
> >
> > Signed-off-by: Ard Biesheuvel
> > ---
> > arch/x86/crypto/chacha_glue.c | 36 ++
On Wed, Oct 2, 2019 at 4:17 PM Ard Biesheuvel wrote:
> Expose the accelerated NEON ChaCha routine directly as a symbol
> export so that users of the ChaCha library can use it directly.
Eric had some nice code for ChaCha for certain ARM cores that lived in
Zinc as chacha20-unrolled-arm.S. This cod
On Fri, 4 Oct 2019 at 15:42, Jason A. Donenfeld wrote:
>
> On Thu, Oct 03, 2019 at 10:43:29AM +0200, Ard Biesheuvel wrote:
> > On Wed, 2 Oct 2019 at 16:17, Ard Biesheuvel
> > wrote:
> > >
> > ...
> > >
> > > In the future, I would like to extend these interfaces to use static
> > > calls,
> > >
On Wed, Oct 02, 2019 at 04:17:03PM +0200, Ard Biesheuvel wrote:
> This integrates the accelerated MIPS 32r2 implementation of ChaCha
> into both the API and library interfaces of the kernel crypto stack.
>
> The significance of this is that, in addition to becoming available
> as an accelerated li
On Wed, Oct 02, 2019 at 04:16:58PM +0200, Ard Biesheuvel wrote:
> This integrates the accelerated MIPS 32r2 implementation of ChaCha
> into both the API and library interfaces of the kernel crypto stack.
>
> The significance of this is that, in addition to becoming available
> as an accelerated li
On Thu, Oct 03, 2019 at 10:43:29AM +0200, Ard Biesheuvel wrote:
> On Wed, 2 Oct 2019 at 16:17, Ard Biesheuvel wrote:
> >
> ...
> >
> > In the future, I would like to extend these interfaces to use static calls,
> > so that the accelerated implementations can be [un]plugged at runtime. For
> > the
On Wed, Oct 02, 2019 at 04:16:55PM +0200, Ard Biesheuvel wrote:
> Wire the existing x86 SIMD ChaCha code into the new ChaCha library
> interface.
>
> Signed-off-by: Ard Biesheuvel
> ---
> arch/x86/crypto/chacha_glue.c | 36
> crypto/Kconfig| 1 +
> include/c
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
the generic CBC template wrapper from a blkcipher to a skcipher algo,
to get away
> From: Mimi Zohar
> Sent: Thursday, October 3, 2019 2:54 PM
> To: Jarkko Sakkinen ; Safford, David (GE
> Subject: EXT: Re: [PATCH] KEYS: asym_tpm: Switch to get_random_bytes()
>
> [Cc'ing David Safford]
>
> On Thu, 2019-10-03 at 20:58 +0300, Jarkko Sakkinen wrote:
> > On Thu, Oct 03, 2019 at 09
On Wed, Oct 02, 2019 at 04:16:54PM +0200, Ard Biesheuvel wrote:
>
> chacha_permute(x, nrounds);
Interested in porting my single-statement unrolled implementation from
Zinc to this? I did see performance improvements on various platforms.
Hi Ard,
On Wed, Oct 02, 2019 at 04:16:53PM +0200, Ard Biesheuvel wrote:
> This is a followup to RFC 'crypto: wireguard with crypto API library
> interface'
> [0]. Since no objections were raised to my approach, I've proceeded to fix up
> some minor issues, and incorporate [most of] the missing MI
On Fri, 4 Oct 2019 at 12:21, Florian Bezdeka wrote:
>
> I'm facing the same problem on one of my VPN gateways.
>
> I updated the affected system from Debian Stretch to Buster.
> Therefore the kernel was updated from 4.9.x to 4.19.x
>
> The supplied patch uses some symbols / functions that were int
I'm facing the same problem on one of my VPN gateways.
I updated the affected system from Debian Stretch to Buster.
Therefore the kernel was updated from 4.9.x to 4.19.x
The supplied patch uses some symbols / functions that were introduced
with 4.19 (like crypto_sync_skcipher_clear_flags()) so s
The patch brings support of several BLAKE2 variants (2b with various
digest lengths). The in-tree user will be btrfs (for checksumming),
we're going to use the BLAKE2b-256 variant.
The code is reference implementation taken from the official sources and
modified only in terms of kernel coding styl
From: Tudor Ambarus
commit 394a9e044702 ("crypto: cfb - add missing 'chunksize' property")
adds a test vector where the input length is smaller than the IV length
(the second test vector). This revealed a NULL pointer dereference in
the atmel-aes driver, that is caused by passing an incorrect off
91 matches
Mail list logo
