On Tue, Oct 2, 2018 at 8:04 AM Ard Biesheuvel wrote:
>
> On 2 October 2018 at 05:45, Jason A. Donenfeld wrote:
> > Hi Herbert,
> >
> > On Tue, Oct 2, 2018 at 5:39 AM Herbert Xu
> > wrote:
> >> > I would also strongly prefer that all crypto work is taken through
> >> > Herbert's tree, so we have
On 2 October 2018 at 05:45, Jason A. Donenfeld wrote:
> Hi Herbert,
>
> On Tue, Oct 2, 2018 at 5:39 AM Herbert Xu wrote:
>> > I would also strongly prefer that all crypto work is taken through
>> > Herbert's tree, so we have a coherent view of it before it goes
>> > upstream.
>>
>> I agree. I do
On Sun, Sep 30, 2018 at 7:35 AM Andy Lutomirski wrote:
> >>> Oh, and another thing (and I'm surprised checkpatch.pl didn't complain
> >>> about it): the use of typedef in new code is strongly discouraged.
> >>> This policy predates my involvement, so perhaps Joe can elaborate on
>
Hi Jason:
On Tue, Oct 02, 2018 at 05:45:20AM +0200, Jason A. Donenfeld wrote:
> Hi Herbert,
>
> > I agree. I don't have any problems with the zinc code living in
> > its own git tree. But any upstream merges should definitely go
> > through the crypto tree because the inherent ties between the
Hi Herbert,
On Tue, Oct 2, 2018 at 5:39 AM Herbert Xu wrote:
> > I would also strongly prefer that all crypto work is taken through
> > Herbert's tree, so we have a coherent view of it before it goes
> > upstream.
>
> I agree. I don't have any problems with the zinc code living in
> its own git
Ard Biesheuvel wrote:
> On 28 September 2018 at 07:46, Jason A. Donenfeld wrote:
>
>> If an implementation enters Zinc, it will go through my tree. If it
>> enters the crypto API, it will go through Herbert's tree. If there
>> wind up being messy tree dependency and merge timing issues, I can
>>
Hi Herbert,
On Tue, Oct 2, 2018 at 5:26 AM Herbert Xu wrote:
> Oh nice, so you did the conversion of the existing crypto code.
>
> I presume someone has done the numbers and verified that there
> is no performance regression?
>
> If so it would be good to include those numbers somewhere in this
>
Jason A. Donenfeld wrote:
> Now that ChaCha20 is in Zinc, we can have the crypto API code simply
> call into it. The crypto API expects to have a stored key per instance
> and independent nonces, so we follow suite and store the key and
> initialize the nonce independently.
>
> Signed-off-by: Jas
Hi Herbert,
On Tue, Oct 2, 2018 at 5:18 AM Herbert Xu wrote:
> > sizeold new
> >
> > 0 62 52
>
> What is the old column? Is it the existing x86-64 implementation
> in the kernel or something else? This needs to be made clear in the
> patch description.
Goo
Jason A. Donenfeld wrote:
> This provides SSSE3, AVX-2, AVX-512F, and AVX-512VL implementations for
> ChaCha20. The AVX-512F implementation is disabled on Skylake, due to
> throttling, and the VL ymm implementation is used instead. These come
> from Andy Polyakov's implementation, with the followi
Hi Herbert,
On Tue, Oct 2, 2018 at 5:15 AM Herbert Xu wrote:
> I don't have any problems with this interface.
>
> However, I'm very unhappy about the fact that this adds another
> copy of the chacha20 implementation to the kernel. Either this
> is better than the one that we already have or it i
Jason A. Donenfeld wrote:
> This implements the ChaCha20 permutation as a single C statement, by way
> of the comma operator, which the compiler is able to simplify
> terrifically.
>
> Information: https://cr.yp.to/chacha.html
>
> Signed-off-by: Jason A. Donenfeld
> Cc: Samuel Neves
> Cc: Andy
Hi Ard,
On Fri, Sep 28, 2018 at 5:47 PM Ard Biesheuvel
wrote:
> > While this is CRYPTOGAMS code, the originating code for this happens to
> > be the same as OpenSSL's commit cded951378069a478391843f5f8653c1eb5128da
> >
>
> I'd still prefer the kernel side changes to be presented as a separate
> f
Hi Borislav,
On Sat, Sep 29, 2018 at 9:56 AM Borislav Petkov wrote:
> Documentation/process/submitting-patches.rst
>
> section 12, first sentence.
>
> The SOB chain needs to clearly express the path of the patch from
> author(s) to the upstream kernel.
Thanks for the clarification.
I've receive
On Mon, Oct 01, 2018 at 09:30:35AM +, Kalyani Akula wrote:
> Hi ,
>
> We wrote a Xilinx specific AES driver in the crypto framework, while testing
> we have seen one issue.
> We are trying to send a input data of size 1MB using sendmsg system call from
> the application, and we could see it
On Mon, Oct 01, 2018 at 09:30:35AM +, Kalyani Akula wrote:
> This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be proprietary,
> privileged or copyrighted under applicable law. If you are not the intended
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
On 1 October 2018 at 09:20, LABBE Corentin wrote:
> On Fri, Sep 28, 2018 at 07:03:11PM +0200, Ard Biesheuvel wrote:
>> On 28 September 2018 at 15:13, Ard Biesheuvel
>> wrote:
>> > On 19 September 2018 at 12:10, Corentin Labbe wrote:
>> >> This patch adds an userspace tool for displaying kernel
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 endian
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: Test
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 perf
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 AE
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:
> >
> > alg:
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 representat
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 already.
On Fri, Sep 28, 2018 at 07:03:11PM +0200, Ard Biesheuvel wrote:
> On 28 September 2018 at 15:13, Ard Biesheuvel
> wrote:
> > On 19 September 2018 at 12:10, Corentin Labbe wrote:
> >> This patch adds an userspace tool for displaying kernel crypto API
> >> statistics.
> >>
> >> Signed-off-by: Core
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 next_index(
30 matches
Mail list logo
