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. Jason
