On Mon, Sep 17, 2018 at 6:06 PM Andy Lutomirski wrote:
> #ifdef CONFIG_X86_64
> #include "whatever"
> #endif
>
> It seems a more obfuscated than needed to put the equivalent of that
> into the Makefile, and I don't think people really like searching
> through the Makefile to figure out why the cod
On Mon, Sep 17, 2018 at 6:14 PM Andy Lutomirski wrote:
> Indeed. What I'm saying is that you shouldn't refactor it this way
> because it will be slow. I agree it would be conceptually nice to be
> able to blacklist a chacha20_x86_64 module to disable the asm, but I
> think it would be very hard
heless, and
I'll do my best to incorporate as much as is reasonable.
> I would like to urge Jason to
> bear with us and bring this discussion to a close before resubmitting.
What I fear is that either:
- You don't like the Zinc initiative in one way or another, and the
desire to
On Mon, Sep 17, 2018 at 4:52 PM Andy Lutomirski wrote:
> I think the module organization needs to change. It needs to be possible to
> have chacha20 built in but AES or whatever as a module.
Okay, I'll do that for v5.
> I might have agreed before Spectre :(. Unfortunately, unless we do some
>
On Mon, Sep 17, 2018 at 4:52 PM Andy Lutomirski wrote:
> > * (Nit) The GCC command line -include'd .h files contain variable and
> > function definitions so they are actually .c files.
>
> Hmm. I would suggest just getting rid of the -include magic entirely. The
> resulting ifdef will be more co
On Mon, Sep 17, 2018 at 4:56 PM Andy Lutomirski wrote:
> Would you accept Ard’s (and/or Eric Biggers’, perhaps, as an alternative)?
> Or, if you really want Herbert’s review, can you ask him to review it? (Hi
> Herbert!)
Preferably Eric's.
On Mon, Sep 17, 2018 at 4:54 PM Andy Lutomirski wrote:
> Ard, what do you think? I think it would
> be nice, but if the authors of that assembly are convinced it should be
> replaced, then this step is optional IMO.
I just spent several hours reworking everything for ChaCha. That was
the easy o
mentation
For the arm/arm64 ones, the changes were even more trivial, so much so
that at Ard's urging, I included a cleaned-up diff inside the commit
message:
- zinc: ChaCha20 ARM and ARM64 implementations
- zinc: Poly1305 ARM and ARM64 implementations
How's that level of detail looking to you?
Thanks again for the review.
Regards,
Jason
ger
XSAVEs, which I've now rectified. I'm still working on a few other
facets of it, but I believe v5 will be more satisfactory when posted.
Regards,
Jason
Greetings Mr. Ro Bot,
Another one of your robot friends also caught this, and the offending
code has been removed for v5.
Thanks for botting,
Jason
Hey again Ro,
> 32bbe22e Jason A. Donenfeld 2018-09-14 49 imply KERNEL_MODE_NEON if
> CPU_V7
This shouldn't have ever been there anyway. Fixed now for v5.
Thanks,
Jason
Hi Mr. Ro Bot,
Looks like this is related to stack frames with KASAN. I've fixed this for v5.
Thanks,
Jason
nded. Fixed for v5.
Thanks,
Jason
e-larger-than=]
> }
Thanks, fixed for v5.
Jason
later date with an improvement commit that includes some
benchmarks.
Jason
On Fri, Sep 14, 2018 at 7:40 PM Ard Biesheuvel
wrote:
> > - Move away from makefile ifdef maze and instead prefer kconfig values,
> > which also makes the design a bit more modular too, which could help
> > in the future.
>
> Could you elaborate on this? From the patches, it is not clear
ial, it seems simpler to keep it as is. I'll
wait for word from you two on this.
Jason
s://blake2.net/
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
---
include/zinc/blake2s.h | 101 ++
lib/zinc/Kconfig|4 +
lib/zinc/Makefile |4 +
lib/zinc/blake2s/blake2s.c | 274
This comes from Dan Bernstein and Peter Schwabe's public domain NEON
code, and has been modified to be friendly for kernel space, as well as
removing some qhasm strangeness to be more idiomatic.
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc:
with contributions (upstream) from Samuel Neves and me,
in addition to further changes in the kernel implementation from us.
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Armando Faz-Hernández
Cc: Thomas Gleixner
Cc:
*:
https://github.com/project-everest/hacl-star
The 32-bit version comes from Fiat: https://github.com/mit-plv/fiat-crypto
Information: https://cr.yp.to/ecdh.html
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Karthikeyan Bhargavan
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: Jason A. Donenfeld
Cc: Samuel Neves
Cc
Now that Poly1305 is in Zinc, we can have the crypto API code simply
call into it. We have to do a little bit of book keeping here, because
the crypto API receives the key in the first few calls to update.
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc
complex custom page allocator that big_key really doesn't
need.
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Eric Biggers
Cc: David Howells
---
security/keys/Kconfig | 4 +-
secu
dge for code that won't even run on ancient
AMD chips.
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: x...@kernel.org
---
lib/zinc/Makefile
These two C implementations -- a 32x32 one and a 64x64 one, depending on
the platform -- come from Andrew Moon's public domain poly1305-donna
portable code, modified for usage in the kernel and for usage with
accelerated primitives.
Information: https://cr.yp.to/mac.html
Signed-off-by: Ja
These implementations from Samuel Neves support AVX and AVX-512VL.
Originally this used AVX-512F, but Skylake thermal throttling made
AVX-512VL more attractive and possible to do with negligable difference.
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Samuel Neves
Cc: Andy Lutomirski
Cc
names have been renamed to fit kernel conventions.
- A comment has been added.
No changes have been made to the actual instructions.
Signed-off-by: Jason A. Donenfeld
Signed-off-by: René van Dorst
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc
,[x1] // write result
ret
+ENDPROC(poly1305_emit_neon)
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
---
lib/zinc/Makefile
use this kludge for code that won't even run on ancient
AMD chips.
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: x...@kernel.org
---
lib/zinc/Makef
This MIPS32r2 implementation comes from René van Dorst and me and
results in a nice speedup on the usual OpenWRT targets.
Signed-off-by: Jason A. Donenfeld
Signed-off-by: René van Dorst
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Ralf Baechle
Cc: Paul
ldp x29,x30,[sp],#96
+.Labort_neon:
ret
+ENDPROC(chacha20_neon)
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
--
o/snuffle/xsalsa-20081128.pdf
[6] https://cr.yp.to/mac.html
[7] https://blake2.net/
[8] https://tools.ietf.org/html/rfc8439
[9] https://github.com/google/wycheproof
Signed-off-by: Jason A. Donenfeld
Cc: Samuel Neves
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Jean-Philippe Aumasson
---
#x27;s net-next tree, while Zinc patches will go through Greg KH's tree.
Enjoy,
Jason
(item = get_item_from_queue()) != NULL) {
encrypt_item(item, simd_context);
simd_context = simd_relax(simd_context);
}
simd_put(simd_context);
The relaxation step ensures that we don't trample over preemption, and
the get/put API should be a familiar paradigm in the kernel.
Signed-off-b
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 Lutomirski
Cc: Greg KH
Cc: Jean-Philippe
#x27;s net-next tree, while Zinc patches will go through Greg KH's tree.
Enjoy,
Jason
On Fri, Sep 14, 2018 at 8:15 AM Ard Biesheuvel
wrote:
> OK, so given random.c's future dependency on Zinc (for ChaCha20), and
> the fact that Zinc is one monolithic piece of code, all versions of
> all algorithms will always be statically linked into the kernel
> proper. I'm not sure that is accep
X2
- AVX512F
- AVX512VL
We make a decision based on CPU capabilities, SIMD context, and input
length, and then choose the right function.
> You know what? If you're up for it, let's not wait until Plumbers, but
> instead, let's collaborate off list to get this into shape.
Sure, sounds good.
Jason
On Thu, Sep 13, 2018 at 5:04 PM Ard Biesheuvel
wrote:
> > The code still benefits from the review that's gone into OpenSSL. It's
> > not modified in ways that would affect the cryptographic operations
> > being done. It's modified to be suitable for kernel space.
>
> So could we please at least ha
t help with problems
> mentioned above, I do not see any compelling reason for the new library for
> dm-crypt...
dm-crypt is probably a good consumer of the existing crypto API and
won't be impacted by the introduction of Zinc, which is really just
the exposure of a couple low level simple crypto functions, and not a
fancy API like the crypto API which dm-crypt happily uses.
Jason
appears to be a desire to
derail this by any means necessary.
> Zinc adds its own clunky ways to mix arch and
> generic code, involving GCC -include command line arguments and
> #ifdefs everywhere. My review comments on this were completely ignored
> by Jason.
No, they were not ignored. v2 cleaned up the #ifdefs. v4 has already
cleaned up the makefile stuff and will be even cleaner. Good things
await, don't worry.
Jason
actually already done this after your urging yesterday, and so
that will be a part of v4.
> But I see no reason at all that /lib should ever contain a grab-bag of
> crypto implementations just for the heck of it. They should have real
> in-kernel users IMO. And this means that there will probably always
> be some crypto implementations in crypto/ for things like aes-xts.
Right, precisely.
Jason
back
the three suitcases the airline lost in transit...)
> > Anyway, it sounds like this whole thing may have ruffled your feathers
> > a bit. Will you be at Linux Plumbers Conference in November? I'm
> > planning on attending, and perhaps we could find some time there to
> > sit down and talk one on one a bit.
>
> That would be good, yes. I will be there.
Looking forward to talking to you there, and hopefully we can put to
rest any lingering concerns.
Jason
Hi Eric,
On Wed, Sep 12, 2018 at 12:08 AM Eric Biggers wrote:
> I'd strongly prefer the assembly to be readable too. Jason, I'm not sure if
> you've actually read through the asm from the OpenSSL implementations, but the
> generated .S files actually do lose a lot of s
atic const struct file_operations uverbs_mmap_fops = {
> .release = ib_uverbs_close,
> .llseek = no_llseek,
> .unlocked_ioctl = ib_uverbs_ioctl,
> - .compat_ioctl = ib_uverbs_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
> static struct ib_client uverbs_client = {
For uverbs:
Acked-by: Jason Gunthorpe
It is very strange, this patch did not appear in the RDMA patchworks,
I almost missed it :|
Jason
acha20_zinc.c?h=jd/wireguard>.
I'll be refining and checking these over the next week or so, but the
basics were super easy to do.
Jason
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
r v4. Thanks for the guidance.
Jason
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 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 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
prove the submission
until it is mergable, and I do not intend to stop.
Anyway, it sounds like this whole thing may have ruffled your feathers
a bit. Will you be at Linux Plumbers Conference in November? I'm
planning on attending, and perhaps we could find some time there to
sit down and talk one on one a bit.
Regards,
Jason
u on the whole series for next
round if you want. Just let me know. In the meantime:
https://patchwork.ozlabs.org/project/netdev/list/?series=65056
https://lore.kernel.org/lkml/20180911010838.8818-1-ja...@zx2c4.com/T/
Regards,
Jason
Sorry, this 07/17 is old cruft that was erroneously sitting around in
my v3 directory. Please look only at the real 07/17 instead:
https://patchwork.ozlabs.org/patch/968359/
My scripts have been adjusted so that this kind of clash doesn't happen again.
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: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe
o/snuffle/xsalsa-20081128.pdf
[6] https://cr.yp.to/mac.html
[7] https://blake2.net/
[8] https://tools.ietf.org/html/rfc8439
[9] https://github.com/google/wycheproof
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: linux-crypto@v
These NEON and non-NEON implementations come from Andy Polyakov's
implementation, with several modifications for being friendly to kernel
space.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: Russell
Neves and me.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: x...@kernel.org
Cc: linux-crypto@vger.kernel.org
---
lib/zinc/Makefile|4 +
lib
This MIPS32r2 implementation comes from René van Dorst and me and
results in a nice speedup on the usual OpenWRT targets.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: René van Dorst
Cc: Ralf Baechle
Cc: Paul Burton
Cc
The C implementation is based on Andy Polyakov's implementation, heavily
modified by Samuel Neves.
Information: https://cr.yp.to/mac.html
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: linux-crypto@vger.kerne
These NEON and non-NEON implementations come from Andy Polyakov's
implementation, with several modifications for being friendly to kernel
space.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: Russell
s://blake2.net/
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: linux-crypto@vger.kernel.org
---
include/zinc/blake2s.h | 101 ++
lib/zinc/Kconfig|4 +
lib/zinc/Makefile |4 +
lib/zinc/blake2s
These two C implementations -- a 32x32 one and a 64x64 one, depending on
the platform -- come from Andrew Moon's public domain poly1305-donna
portable code, modified for usage in the kernel and for usage with
accelerated primitives.
Information: https://cr.yp.to/mac.html
Signed-off-by: Ja
This comes from Dan Bernstein and Peter Schwabe's public domain NEON
code, and has been modified to be friendly for kernel space, as well as
removing some qhasm strangeness to be more idiomatic.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc:
with contributions (upstream) from Samuel Neves and me,
in addition to further changes in the kernel implementation from us.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: Armando Faz-Hernández
Cc: Thomas Gleixner
Cc: Ingo Molnar
These implementations from Samuel Neves support AVX and AVX-512VL.
Originally this used AVX-512F, but Skylake thermal throttling made
AVX-512VL more attractive and possible to do with negligable difference.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc
*:
https://github.com/project-everest/hacl-star
The 32-bit version comes from Fiat: https://github.com/mit-plv/fiat-crypto
Information: https://cr.yp.to/ecdh.html
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: Karthikeyan Bhargavan
: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: René van Dorst
Cc: Ralf Baechle
Cc: Paul Burton
Cc: James Hogan
Cc: linux-m...@linux-mips.org
Cc: linux-crypto@vger.kernel.org
---
lib/zinc/Makefile
This provides AVX, AVX-2, and AVX-512F implementations for Poly1305.
The AVX-512F implementation is disabled on Skylake, due to throttling.
These come from Andy Polyakov's implementation, with some heavy
modifications from Samuel Neves and me.
Signed-off-by: Jason A. Donenfeld
Cc:
of v3.
Regards,
Jason
On Sat, Aug 25, 2018 at 12:29 AM Eric Biggers wrote:
> I thought you were going to wrap lines at 80 characters? It's hard to read
> the
> extremely long lines, and they encourage deep nesting.
> There are still some alignment bugs where integers are loaded from byte arrays
> without using the u
Pressed send too fast.
On Sat, Aug 25, 2018 at 11:06 AM Jason A. Donenfeld wrote:
> - https://www.wireguard.com/papers/wireguard-formal-verification.pdf
> - https://www.wireguard.com/papers/dowling-paterson-computational-2018.pdf
> - https://www.wireguard.com/formal-verification
roof of
the protocol, and not of each primitive, like, say, "ChaCha20" or
"Curve25519." However, academic literature is full of all sorts of
curious and fascinating security analyses of the various primitives if
this is something you're interested in.
Jason
g with the point of going with Andy's
implementations in the first place -- and we've been able to pretty
trivially track OpenSSL changes -- but nonetheless important tweaks have
been done to make this suitable to kernel space.
> There are still some alignment bugs where integers are loaded from byte arrays
> without using the unaligned access macros, e.g. in chacha20_init(),
> hchacha20_generic(), and fe_frombytes_impl(). I found these grepping for
> le32_to_cpu. Interestingly, that last one is in "formally verified" code :-)
Thanks. I'll do another pass at these for v3.
Jason
o/snuffle/xsalsa-20081128.pdf
[6] https://cr.yp.to/mac.html
[7] https://blake2.net/
[8] https://tools.ietf.org/html/rfc8439
[9] https://github.com/google/wycheproof
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: linux-crypto@v
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: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe
These NEON and non-NEON implementations come from Andy Polyakov's
implementation, with several modifications for being friendly to kernel
space.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: Russell
Neves and me.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: x...@kernel.org
Cc: linux-crypto@vger.kernel.org
---
lib/zinc/Makefile|4 +
lib
These NEON and non-NEON implementations come from Andy Polyakov's
implementation, with several modifications for being friendly to kernel
space.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: Russell
with contributions (upstream) from Samuel Neves and me,
in addition to further changes in the kernel implementation from us.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: Armando Faz-Hernández
Cc: Thomas Gleixner
Cc: Ingo Molnar
This MIPS32r2 implementation comes from René van Dorst and me and
results in a nice speedup on the usual OpenWRT targets.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: René van Dorst
Cc: Ralf Baechle
Cc: Paul Burton
Cc
These implementations from Samuel Neves support AVX and AVX-512VL.
Originally this used AVX-512F, but Skylake thermal throttling made
AVX-512VL more attractive and possible to do with negligable difference.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc
This comes from Dan Bernstein and Peter Schwabe's public domain NEON
code, and has been modified to be friendly for kernel space.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: D. J. Bernstein
Cc: Jean-Philippe Aumasson
Cc: Russell King
Cc: linu
s://blake2.net/
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: linux-crypto@vger.kernel.org
---
include/zinc/blake2s.h | 94 ++
lib/zinc/Kconfig| 4 +
lib/zinc/Makefile | 4 +
lib/zi
The C implementation is based on Andy Polyakov's implementation, heavily
modified by Samuel Neves.
Information: https://cr.yp.to/mac.html
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: linux-c
This provides AVX, AVX-2, and AVX-512F implementations for Poly1305.
The AVX-512F implementation is disabled on Skylake, due to throttling.
These come from Andy Polyakov's implementation, with some heavy
modifications from Samuel Neves and me.
Signed-off-by: Jason A. Donenfeld
Cc:
*:
https://github.com/project-everest/hacl-star
The 32-bit version comes from Fiat: https://github.com/mit-plv/fiat-crypto
Information: https://cr.yp.to/ecdh.html
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: Karthikeyan Bhargavan
: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: René van Dorst
Cc: Ralf Baechle
Cc: Paul Burton
Cc: James Hogan
Cc: linux-m...@linux-mips.org
Cc: linux-crypto@vger.kernel.org
---
lib/zinc/Makefile
set goes in, and at the same time
we'll try to bring Andy and others into the fold, where our
improvements can generally track each others.
> Also, I don't know whether Andy P. considered the 4xNEON implementation
> technique. It could even be fastest on other ARM CPUs too, I don't know.
After v2, when he's CC'd in, let's plan to start discussing this with him.
Jason
> but it's very hard for a flow classifier because you have to
The construction and identifier strings might not obviously help with
the extremely narrow idea you've brought up, but it is very important
for safely introducing additional versions. Namely, it prevents
against cross-protocol key reus
he first
step of cryptographic operations, containing the Noise handshake
pattern and a list of the cryptographic primitives used.
- A type field at the beginning of each message. Newer message types
(corresponding with newer versions) can easily be introduced via this
field, and they can even coexist with older ones need be.
- Three unused reserved fields ready to be utilised in the event they're needed.
In other words, there's ample room for such contingency measures
within the protocol.
Jason
On Tue, Aug 7, 2018 at 6:49 PM Andy Lutomirski wrote:
> I really wish we had a way to see that we use asm-generic’s copy of a header
> in all cases except where an arch opts out.
It's really not that hard to do -- symlink asm-generic to a target
called "asm" inside an otherwise empty directory,
functions.
I'm inclined to do the explicit context passing only when a function
is likely to be used in that kind of environment, and adjust as
needed. Long term, anyway, that API will be removed once the x86 guys
figure out lazy FPU restoration and the amortization doesn't add
anything.
Jason
if you
have suggestions or concerns or want to poke me while I'm working on
v2, don't hesitate to send me private email or ping me in IRC (I'm
"zx2c4" there) to chat.
Regards,
Jason
get going. Therefore, this patch removes Speck.
[1] https://marc.info/?l=linux-crypto-vger&m=153359499015659
Signed-off-by: Jason A. Donenfeld
Acked-by: Eric Biggers
Cc: sta...@vger.kernel.org
---
Documentation/filesystems/fscrypt.rst | 10 -
arch/arm/crypto/Kconfig |
On 8/6/18, Eric Biggers wrote:
>
> For context, in your commit message can you include a link to my email
> mentioning Android's Speck decision
> (https://marc.info/?l=linux-crypto-vger&m=153359499015659)?
Sure.
>
> Also: "speck" => "Speck".
Ack.
>
> Also I think the fscrypt code points should
filling up caches when writing asynchronously? And for how
much longer do you foresee underpowered hardware like that being a not
insignificant part of the market? I'm especially curious to know
because ostensibly at Google you have all sorts metrics regarding that
kind of thing.
Jason
ou
expect to persist into the future.
Jason
301 - 400 of 810 matches
Mail list logo
