On Tue, May 12, 2020 at 3:48 AM Kevin Chadwick <m8il1i...@gmail.com> wrote:
> On 2020-05-12 06:05, Matt Dunwoodie wrote:
> >  I don't want to put misleading numbers out there and every use case
> >    is different, therefore you should perform your own tests. In my
> >    environment (tcbbench between two Lenovo x230 (i5-3320m), em(4)
> >    ethernet) I was seeing 750mbit/s. This was compared to default
> >    isakmpd(8) with a basic ike psk configuration, which achieved
> >    380mbit/s. Different configurations will behave differently, of
> >    course, but I think we're off to a pretty good start here.
> That is certainly more than fast enough for my purposes and at slower speeds
> will cause no issue with the bonus that hw that does not have AES-NI, will 
> still
> be performant.
> However I assume that compared to using AES-NI, the machine will be running a
> lot hotter, using more power and be less usable for other tasks.
> Especially, less powerful systems will have far less performance when their hw
> support is not utilised and contrary to the wireguard paper. Many embedded
> systems do have AES hw support.
> I imagine supporting all those embedded hw variants is problematic and part of
> the reason AES might have been avoided?
> I just wonder. Is there scope in the design for adding AES-NI support, in the
> future as a config option even, rather than a runtime negotiation like OpenSSH
> facilitates?

A good place to discuss future revisions of WireGuard protocol design
is over on the WireGuard mailing list --
<https://lists.zx2c4.com/mailman/listinfo/wireguard>. WireGuard uses
"versioned crypto" instead of options for ciphersuites, and there's
some interesting discussion to be had [not here] on our current
choices. To answer your question, "nobs" are not something we really
add places, but on another mailing list I'm happy to discuss future
protocol design and that pandora's box. With regards to your inquiry
about performance though:

There are lightening fast implementations of chacha using avx, avx2,
avx512, arm vector extensions, and so forth, that are easily in the
same ballpark as aes-ni. Djb has a nice post on chacha performance in
this context: <https://moderncrypto.org/mail-archive/noise/2016/000699.html>.
After the initial wireguard patchset lands, I'm happy to explore
adding accelerated chacha implementations to the openbsd kernel. For
example, I've already ported Andy's cryptogams implementations for a
number of platforms to be use in the kernel, and it probably wouldn't
be too hard to put this in OpenBSD. In practice, I've found that the
choice of chacha means that WireGuard performs well on both beefy avx2
hardware and on cheap little mips routers. There's tons of room for
performance improvement, in general. I think what Matt's posted here
is a good, safe, simple implementation that provides a basis for
tweaking and optimizing -- faster crypto implementations, better
queueing algorithms, and so forth.


Reply via email to