On Fri, 27 Sep 2019 at 09:21, Jason A. Donenfeld wrote:
>
> Hey Andy,
>
> Thanks for weighing in.
>
> > inlining. I'd be surprised for chacha20. If you really want inlining
> > to dictate the overall design, I think you need some real numbers for
> > why it's necessary. There also needs to be a
H
> > > ; Linus Torvalds
> > > ; Samuel
> > > Neves ; Dan Carpenter ; Arnd
> > > Bergmann
> > > ; Eric Biggers ; Andy Lutomirski
> ;
> > > Will Deacon ; Marc Zyngier ; Catalin
> > > Marinas
> > > ; Willy Tarreau ; Netdev
> ;
> &
Hey Andy,
Thanks for weighing in.
> inlining. I'd be surprised for chacha20. If you really want inlining
> to dictate the overall design, I think you need some real numbers for
> why it's necessary. There also needs to be a clear story for how
> exactly making everything inline plays with the
acon ; Marc Zyngier ; Catalin
> > Marinas
> > ; Willy Tarreau ; Netdev
> > ;
> > Toke Høiland-Jørgensen ; Dave Taht
> > Subject: chapoly acceleration hardware [Was: Re: [RFC PATCH 00/18] crypto:
> > wireguard
> > using the existing crypto API]
> >
>
On Thu, 26 Sep 2019 13:06:51 +0200, Jason A. Donenfeld wrote:
> On Thu, Sep 26, 2019 at 12:19 PM Pascal Van Leeuwen wrote:
> > Actually, that assumption is factually wrong. I don't know if anything
> > is *publicly* available, but I can assure you the silicon is running in
> > labs already. And som
On Thu, Sep 26, 2019 at 1:52 PM Jason A. Donenfeld wrote:
>
> Hi Ard,
>
>
> Our goals are that chacha20_arch() from each of these arch glues gets
> included in the lib/crypto/chacha20.c compilation unit. The reason why
> we want it in its own unit is so that the inliner can get rid of
> unreached
> > So are you saying that the handshake timing constraints in the
> > WireGuard protocol are so stringent that we can't run it securely on,
> > e.g., an ARM CPU that lacks a NEON unit? Or given that you are not
> > providing accelerated implementations of blake2s or Curve25519 for
> > arm64, we ca
Hi Ard,
On Thu, Sep 26, 2019 at 2:07 PM Ard Biesheuvel
wrote:
> attitude goes counter to that, and this is why we have made so little
> progress over the past year.
I also just haven't submitted much in the past year, taking a bit of a
break to see how things would settle. Seemed like rushing th
> ;
> Herbert Xu ; David Miller ;
> Greg KH
> ; Linus Torvalds ;
> Samuel
> Neves ; Dan Carpenter ; Arnd
> Bergmann
> ; Eric Biggers ; Andy Lutomirski
> ;
> Will Deacon ; Marc Zyngier ; Catalin Marinas
>
> Subject: Re: [RFC PATCH 00/18] crypto: wireguard usi
.@vger.kernel.org>; linux-arm-kernel
> > ;
> > Herbert Xu ; David Miller
> > ; Greg KH
> > ; Linus Torvalds
> > ; Samuel
> > Neves ; Dan Carpenter ; Arnd
> > Bergmann
> > ; Eric Biggers ; Andy Lutomirski
> > ;
> > Will Deacon ; Marc
; ; Linus Torvalds ;
> Samuel
> Neves ; Dan Carpenter ; Arnd
> Bergmann
> ; Eric Biggers ; Andy Lutomirski
> ;
> Will Deacon ; Marc Zyngier ; Catalin Marinas
>
> Subject: Re: [RFC PATCH 00/18] crypto: wireguard using the existing crypto API
>
> On Thu, 26 Sep 2019
gt; Greg KH
> ; Linus Torvalds ;
> Samuel
> Neves ; Dan Carpenter ; Arnd
> Bergmann
> ; Eric Biggers ; Andy Lutomirski
> ;
> Will Deacon ; Marc Zyngier ; Catalin Marinas
> ; Willy Tarreau ; Netdev
> ;
> Toke Høiland-Jørgensen ; Dave Taht
> Subject: chapoly acceleration ha
On Thu, 26 Sep 2019 at 15:06, Pascal Van Leeuwen
wrote:
...
> >
> > My preference would be to address this by permitting per-request keys
> > in the AEAD layer. That way, we can instantiate the transform only
> > once, and just invoke it with the appropriate key on the hot path (and
> > avoid any
> > In this case, the relevance is that the handshake in WireGuard is
> > extremely performance sensitive, in order to fend off DoS. One of the
> > big design gambits in WireGuard is – can we make it 1-RTT to reduce
> > the complexity of the state machine, but keep the crypto efficient
> > enough t
On Thu, 26 Sep 2019 at 10:59, Jason A. Donenfeld wrote:
>
...
>
> Instead what we’ve wound up with in this series is a Frankenstein’s
> monster of Zinc, which appears to have basically the same goal as
> Zinc, and even much of the same implementation just moved to a
> different directory, but then
"Jason A. Donenfeld" writes:
> [CC +willy, toke, dave, netdev]
>
> Hi Pascal
>
> On Thu, Sep 26, 2019 at 12:19 PM Pascal Van Leeuwen
> wrote:
>> Actually, that assumption is factually wrong. I don't know if anything
>> is *publicly* available, but I can assure you the silicon is running in
>> la
[CC +willy, toke, dave, netdev]
Hi Pascal
On Thu, Sep 26, 2019 at 12:19 PM Pascal Van Leeuwen
wrote:
> Actually, that assumption is factually wrong. I don't know if anything
> is *publicly* available, but I can assure you the silicon is running in
> labs already. And something will be publicly a
On Thu, Sep 26, 2019 at 12:19 PM Pascal Van Leeuwen
wrote:
> Actually, that assumption is factually wrong. I don't know if anything
> is *publicly* available, but I can assure you the silicon is running in
> labs already.
Great to hear, and thanks for the information. I'll follow up with
some que
> There’s also a degree of practicality: right now there is zero ChaPoly
> async acceleration hardware anywhere that would fit into the crypto
> API.
>
Actually, that assumption is factually wrong. I don't know if anything
is *publicly* available, but I can assure you the silicon is running in
labs
Hi Ard,
Thanks for taking the initiative on this. When I first discussed with
DaveM porting WireGuard to the crypto API and doing Zinc later
yesterday, I thought to myself, “I wonder if Ard might want to work on
this with me…” and sent you a message on IRC. It didn’t occur to me
that you were the
This series proposes a way to incorporate WireGuard into the kernel
without relying on a wholesale replacement of the existing crypto
stack. It addresses two issues with the existing crypto API, i.e.,
the need to do a kmalloc() allocation for each request, and the fact
that it can only operate on s
21 matches
Mail list logo
