On Tue, Sep 11, 2018 at 09:42:39AM +0200, Ondrej Mosnacek wrote:
> This patch simplifies the LRW template to recompute the LRW tweaks from
> scratch in the second pass and thus also removes the need to allocate a
> dynamic buffer using kmalloc().
>
> As discussed at [1], the use of kmalloc causes
Hi Ondrej,
On Tue, Sep 11, 2018 at 09:42:38AM +0200, Ondrej Mosnacek wrote:
> This patch rewrites the tweak computation to a slightly simpler method
> that performs less bswaps. Based on performance measurements the new
> code seems to provide slightly better performance than the old one.
>
> PER
Hi Eric, Andy,
> On Tue, Sep 11, 2018 at 5:01 PM Andy Lutomirski wrote:
> > I think Ard’s point is valid: in the long run we don’t want two competing
> > software implementations of each primitive. It clearly *should* be possible
> > to make crypto API call into zinc for synchronous software op
From: Eric Biggers
In commit 9f480faec58c ("crypto: chacha20 - Fix keystream alignment for
chacha20_block()"), I had missed that chacha20_block() can be called
directly on the buffer passed to get_random_bytes(), which can have any
alignment. So, while my commit didn't break anything, it didn't
To revive this...
On Fri, Aug 10, 2018 at 08:27:58AM +0200, Stephan Mueller wrote:
> Am Donnerstag, 9. August 2018, 21:40:12 CEST schrieb Eric Biggers:
>
> Hi Eric,
>
> > while (bytes >= CHACHA20_BLOCK_SIZE) {
> > chacha20_block(state, stream);
> > - crypto_xor(dst, (co
On 9/4/18 12:19 AM, Herbert Xu wrote:
> On Wed, Aug 15, 2018 at 04:11:25PM -0500, Brijesh Singh wrote:
>> Currently, the CCP driver assumes that the SEV command issued to the PSP
>> will always return (i.e. it will never hang). But recently, firmware bugs
>> have shown that a command can hang.
On Tue, Sep 11, 2018 at 5:57 PM David Miller wrote:
> Both of Andrew's statements are completely true.
>
> I'm not looking at any of the networking bits until the crypto stuff
> is fully sorted and fully supported and Ack'd by crypto folks.
Seems reasonable to me.
Jason
Hi Andy,
On Tue, Sep 11, 2018 at 5:01 PM Andy Lutomirski wrote:
> I think Ard’s point is valid: in the long run we don’t want two competing
> software implementations of each primitive. It clearly *should* be possible
> to make crypto API call into zinc for synchronous software operations, but
From: Andrew Lunn
Date: Wed, 12 Sep 2018 01:30:15 +0200
> Just as an FYI:
>
> 1) I don't think anybody in netdev has taken a serious look at the
> network code yet. There is little point until the controversial part
> of the code, Zinc, has been sorted out.
>
> 2) I personally would be surprise
On Tue, Sep 11, 2018 at 04:02:52PM -0600, Jason A. Donenfeld wrote:
> On Tue, Sep 11, 2018 at 3:47 PM Eric Biggers wrote:
> > Of course, the real problem is that even after multiple revisions of this
> > patchset, there's still no actual conversions of the existing crypto API
> > algorithms over t
> On Sep 11, 2018, at 3:18 PM, Jason A. Donenfeld wrote:
>
>> On Tue, Sep 11, 2018 at 4:16 PM Andy Lutomirski wrote:
>> Jason, can you do one of these conversions as an example?
>
> My preference is really to leave that to a different patch series. But
> if you think I *must*, then I shall.
On Tue, Sep 11, 2018 at 4:16 PM Andy Lutomirski wrote:
> Jason, can you do one of these conversions as an example?
My preference is really to leave that to a different patch series. But
if you think I *must*, then I shall.
Jason
> On Sep 11, 2018, at 2:47 PM, Eric Biggers wrote:
>
>> On Tue, Sep 11, 2018 at 04:56:24PM +0200, Greg Kroah-Hartman wrote:
>> On Tue, Sep 11, 2018 at 12:08:56PM +0200, Ard Biesheuvel wrote:
As Zinc is simply library code, its config options are un-menued, with
the exception of CONFI
On Tue, Sep 11, 2018 at 12:08:56PM +0200, Ard Biesheuvel wrote:
>
> I won't go into the 1000s lines of generated assembly again - you
> already know my position on that topic.
>
I'd strongly prefer the assembly to be readable too. Jason, I'm not sure if
you've actually read through the asm from
On Tue, Sep 11, 2018 at 3:48 PM Eric Biggers wrote:
> Please Cc linux-crypto on the whole patch series, including the cover letter.
Ack.
On Tue, Sep 11, 2018 at 3:47 PM Eric Biggers wrote:
> Of course, the real problem is that even after multiple revisions of this
> patchset, there's still no actual conversions of the existing crypto API
> algorithms over to use the new implementations. "Zinc" is still completely
> separate from t
On Tue, Sep 11, 2018 at 03:12:14PM -0600, Jason A. Donenfeld wrote:
> Hey Thomas,
>
> On Tue, Sep 11, 2018 at 3:09 AM Thomas Gleixner wrote:
> > > This is covered on the 02/17 commit message, whose relevant paragraph
> > > follows:
> > Well, being only cc'ed on only half of the patches does not
On Tue, Sep 11, 2018 at 04:56:24PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Sep 11, 2018 at 12:08:56PM +0200, Ard Biesheuvel wrote:
> > > As Zinc is simply library code, its config options are un-menued, with
> > > the exception of CONFIG_ZINC_DEBUG, which enables various selftests and
> > > BUG_
On Tue, Sep 11, 2018 at 3:27 PM Thomas Gleixner wrote:
> Na, all good. I'm fine with the answer and reviewing that ASM maze is way
> over my limited crypto knowledge anyway. I definitely would enjoy
> refreshing the math behind it, but that surely would be way outside of your
> envisioned time fra
On Tue, 11 Sep 2018, Jason A. Donenfeld wrote:
> Hey Thomas,
>
> On Tue, Sep 11, 2018 at 3:09 AM Thomas Gleixner wrote:
> > > This is covered on the 02/17 commit message, whose relevant paragraph
> > > follows:
> > Well, being only cc'ed on only half of the patches does not really help.
>
> So
Hello Ard,
I realize you've put a lot of good and hard work into the existing
crypto API, and that my writing in these commit messages might be a
bit too bristly and dismissive of that hard work. So I think in a
sense it's understandable that you've responded as such here. But
hopefully I can addr
Hey Thomas,
On Tue, Sep 11, 2018 at 3:09 AM Thomas Gleixner wrote:
> > This is covered on the 02/17 commit message, whose relevant paragraph
> > follows:
> Well, being only cc'ed on only half of the patches does not really help.
Sorry about that. I'm happy to Cc you on the whole series for next
On Tue, Sep 11, 2018 at 12:08:56PM +0200, Ard Biesheuvel wrote:
> > As Zinc is simply library code, its config options are un-menued, with
> > the exception of CONFIG_ZINC_DEBUG, which enables various selftests and
> > BUG_ONs.
> >
>
> In spite of the wall of text, you fail to point out exactly wh
On Mon, Sep 10, 2018 at 02:06:57PM -0500, Brijesh Singh wrote:
> Nothing prevent user from supplying a bogus number. The main question
> is, clamp with what number ?
So you definitely want to forbid too large timeouts - that wouldn't make
any sense anyway. And too small either, because a too small
On Tue, Sep 11, 2018 at 02:40:43PM +0800, Kenneth Lee wrote:
> On Mon, Sep 10, 2018 at 11:33:59PM -0400, Jerome Glisse wrote:
> > On Tue, Sep 11, 2018 at 10:42:09AM +0800, Kenneth Lee wrote:
> > > On Mon, Sep 10, 2018 at 10:54:23AM -0400, Jerome Glisse wrote:
> > > > On Mon, Sep 10, 2018 at 11:28:0
On 11 September 2018 at 03:08, Jason A. Donenfeld wrote:
> Zinc stands for "Zinc Is Neat Crypto" or "Zinc as IN Crypto" or maybe
> just "Zx2c4's INsane Cryptolib." It's also short, easy to type, and
> plays nicely with the recent trend of naming crypto libraries after
> elements. The guiding princ
On Tue, Sep 11, 2018 at 9:22 AM, Thomas Gleixner wrote:
> On Mon, 10 Sep 2018, Jason A. Donenfeld wrote:
>> lib/zinc/Makefile|4 +
>> lib/zinc/chacha20/chacha20-x86_64-glue.h | 102 +
>> lib/zinc/chacha20/chacha20-x86_64.S | 2632 ++
>
> Just a
On Tue, 11 Sep 2018, Samuel Neves wrote:
> On Tue, Sep 11, 2018 at 9:22 AM, Thomas Gleixner wrote:
> > On Mon, 10 Sep 2018, Jason A. Donenfeld wrote:
> >> lib/zinc/Makefile|4 +
> >> lib/zinc/chacha20/chacha20-x86_64-glue.h | 102 +
> >> lib/zinc/chacha20/chacha20-x8
On Mon, 10 Sep 2018, Jason A. Donenfeld wrote:
> lib/zinc/Makefile|4 +
> lib/zinc/chacha20/chacha20-x86_64-glue.h | 102 +
> lib/zinc/chacha20/chacha20-x86_64.S | 2632 ++
Just a stupid question. What's the rationale of putting that into lib/z
This patchset is a follow-up to a similar patch for XTS:
https://patchwork.kernel.org/patch/10588775/
The first patch applies a small optimization to the tweak computation
and the second simplifes away the use of auxiliary buffer to cache
computed tweaks.
Changes in v3:
- fix a copy-paste error
This patch simplifies the LRW template to recompute the LRW tweaks from
scratch in the second pass and thus also removes the need to allocate a
dynamic buffer using kmalloc().
As discussed at [1], the use of kmalloc causes deadlocks with dm-crypt.
PERFORMANCE MEASUREMENTS (x86_64)
Performed using
This patch rewrites the tweak computation to a slightly simpler method
that performs less bswaps. Based on performance measurements the new
code seems to provide slightly better performance than the old one.
PERFORMANCE MEASUREMENTS (x86_64)
Performed using: https://gitlab.com/omos/linux-crypto-be
Since commit acb9b159c784 ("crypto: gf128mul - define gf128mul_x_* in
gf128mul.h"), the gf128mul_x_*() functions are very fast and therefore
caching the computed XTS tweaks has only negligible advantage over
computing them twice.
In fact, since the current caching implementation limits the size of
On Mon, Sep 10, 2018 at 6:17 PM Eric Biggers wrote:
> Hi Ondrej,
>
> On Mon, Sep 10, 2018 at 01:28:41PM +0200, Ondrej Mosnacek wrote:
> >
> > -static int init_crypt(struct skcipher_request *req, crypto_completion_t
> > done)
> > +static int xor_tweak_pre(struct skcipher_request *req)
> > {
> > -
34 matches
Mail list logo
