Wireguard and entropy

alzhao · 2019-01-29T14:34:54.699Z

I didn’t notice this.

Has any other people noticed this problem?

jeffsf · 2019-01-29T14:35:12.600Z

Security-conscious users should carefully evaluate the algorithms used by haveged as its randomness is reported to not be very good. Poor random number generation can lead to breaking of the crypto that depends on it.

See, for example,

crypto.stackexchange.com

Quality of randomness on a Linux system with haveged

random-number-generator, randomness

asked by Hal Bal on 05:30AM - 23 Apr 13 UTC

@alzhao – Most all-in-one routers take 30-120 seconds to get to the random: crng init done point in the boot cycle. This is a reality of the available sources of high-quality randomness from these devices. For most users, by the time that NTP sync occurs and the system clock is at or ahead of the last time there were server-client connections (required for Wireguard), there is usually sufficient entropy available for “critical” crypto. Depending on the needs of the application, it can start before the pool is full without exhausting it.

alpha1974 · 2019-01-29T15:07:04.274Z

So without haveged (or something similar as we don´t have a hardware random generator) the solution is to wait for “random: crng init done”. This delays the start of wireguard connections which might be undesirable in testing environments, especially to test new wireguard setups.

When I set up my device with a new wireguard installation I ran into this problem… and searched for firewall/routing issues until I figured out the entropy thing. When anything works as intended haveged can be disabled.

nopro404 · 2019-01-29T15:32:41.079Z

also interesting is openvpn will be releasing version 3 which will have a kernel component like wireguard giving it the same wire like speed.

The protocol implementation is the same as version 2 - but the version 3 client/server will be as fast as wireguard.

My guess is it will be implemented before wireguard gains acceptance in the VPN world.

sfx2000 · 2019-01-30T01:03:55.067Z

jeffsf:

Security-conscious users should carefully evaluate the algorithms used by haveged as its randomness is reported to not be very good. Poor random number generation can lead to breaking of the crypto that depends on it.

haveged is good enough for Tails OS to ship with it, regardless of the many concerns with haveged - there’s a huge amount of politics around the rng in general, and all of it upstream where it likely belongs

Fair amount of discussion over on snbforums.com, where there are maintainers for the rMerlin-AsusWRT fork, along with external scripts and entware packages.

I wouldn’t include haveged as a default package in the build, but it’s there in the repo if folks want to try it.

sfx2000 · 2019-01-30T01:10:33.938Z

nopro404:

My guess is it will be implemented before wireguard gains acceptance in the VPN world.

Except that Linus Torvalds is a big fan of WG - and that means much, as most server side VPN operators are on linux (as is much of the cloud in general)

@alzhao - props for including WG on the products here…

nopro404 · 2019-01-30T04:21:34.206Z

sfx2000:

Except that Linus Torvalds is a big fan of WG - and that means much

What does it mean much?

alzhao · 2019-01-30T07:16:26.682Z

yes.

I’d also like to see how Openvpn can be optimised for speed. Openvpn support layer 2 bridge but WG only works on layer 3. There are some requirements for layer 2.

sfx2000 · 2019-01-30T20:40:06.082Z

alzhao:

I’d also like to see how Openvpn can be optimised for speed. Openvpn support layer 2 bridge but WG only works on layer 3. There are some requirements for layer 2.

There’s a bit perhaps - but if one wants to be secure, one gets compute bound on the m24kc and ramips based targets.

AR300M and MT300 targets are similar to other vendors on the same architecture.

The IPQ4028 in the GL-B1300 should be better there - maybe even 2x the speed perhaps.

(I have one on the way, courtesy of our friends at Minim

sfx2000 · 2019-01-30T20:42:36.909Z

nopro404:

also interesting is openvpn will be releasing version 3 which will have a kernel component like wireguard giving it the same wire like speed.

The protocol implementation is the same as version 2 - but the version 3 client/server will be as fast as wireguard.

Last time I looked - OpenVPN 3.0 discussion has stalled - the initial requirements were set in 2010, and some high level design work was initiated, but last 3.0 project update on their Trac was 6 years ago…

https://community.openvpn.net/openvpn/wiki/RoadMap

Johnex · 2019-01-30T21:24:07.911Z

If Linus likes something it usually gets priority and is accelerated in development, so that is what “means much” refers to. On the other hand OpenVPN is based on OpenSSL which is responsible for all the leaks, hacks and other things in the recent years.

New projects such as Wireguard for VPN and LibreSSL for SSL/TLS are quickly replacing the others.
For example Apple has changed to LibreSSL in High Sierra, and Windows 10 also uses LibreSSL as their provider.

sfx2000 · 2019-01-30T23:58:04.977Z

Johnex:

For example Apple has changed to LibreSSL in High Sierra

Last time I checked, the whole OpenSSL/LibreSSL thing on OS X was a shim into Apple’s SecureTransport API for legacy and FreeBSD userland stuff

One can do MacPorts/HomeBrew and install the real OpenSSL if desired I suppose, and there the ports teams do keep things current.

Getting back to WG - it’s not just Linus that is excited about WG and making it a priority - if one is following OpenWRT, they’re keeping very current on changes on master…

On master, WG performance on GL-AR300M (NAND) is looking good on the ath79 target - which bodes well for the QCA9331/QCA9531 targets once OpenWRT emits a release - I would never suggest running OpenWRT master in a production use-case - but there are more than a couple of folks looking at ath79 as most upstream development is being done there.

Johnex · 2019-01-31T13:46:44.245Z

Yes, Apple uses their SecureTransport API for their own apps, but for all other 3rd party they have moved to LibreSSL. So when you compile your program it will be linking to LibreSSL as default.

nopro404 · 2019-01-31T16:19:32.536Z

Johnex:

OpenVPN is based on OpenSSL which is responsible for all the leaks, hacks and other things in the recent years.

It’s not based on it. It depends how you compile it. It can be compiled with LibreSSL if desired. I am currently running it linked against the mbedTLS SSL library on my 300M and am seeing upto a 20% speed improvement over the default GL-iNET package.

nopro404 · 2019-01-31T17:16:40.014Z

sfx2000:

Last time I looked - OpenVPN 3.0 discussion has stalled

If I had a nickel for every stagnated document in an opensource project

The development is active.

GitHub

Commits · OpenVPN/openvpn3-linux

OpenVPN 3 Linux client. Contribute to OpenVPN/openvpn3-linux development by creating an account on GitHub.

Johnex · 2019-01-31T17:44:03.135Z

I mean back in time. There was no LibreSSL, BoringSSL and other forks before the 2014, OpenSSL was the way to go. OpenVPN was based on those crappy coding standards, where old code is left and new code piled on top, causing all the issues that happened later.

LibreSSL was made to be a drop in replacement to OpenSSL, so yeah you can link any program to it if you like.

mbedTLS might be better specifically for OpenWRT, but it’s not great on other platforms cos it doesn’t even have ARM extensions and other optimizations that LibreSSL and others have.

nopro404 · 2019-01-31T17:59:39.598Z

Johnex:

mbedTLS might be better specifically for OpenWRT, but it’s not great on other platforms cos it doesn’t even have ARM extensions and other optimizations that LibreSSL and others have.

This is quite right. Unfortunately there has been no effort to get OpenWRT into a CI/CD build and be able to do automated testing for performance evaluation. These old projects like OpenWRT live inside mailing lists, closed git repos, and bug trackers with no transparency. They are reluctant to change - it’s near impossible to get them into the way things work now.

jeffsf · 2019-01-31T19:16:26.225Z

nopro404:

These old projects like OpenWRT live inside mailing lists, closed git repos, and bug trackers with no transparency.

Funny, I don’t have any problem finding, among other things

git.openwrt.org Git - openwrt/openwrt.git/summary (and all the other related repos, along with staging trees)
OpenWrt development - Patchwork
Index of /snapshots/
https://bugs.openwrt.org/
[OpenWrt Wiki] Communication within the OpenWrt Project (both mailing list and IRC, both access and logs)

Now, you may not like the decisions that the developers make, but the information is hardly hidden

Back closer to on topic, mbedTLS works very well in highly constrained, embedded targets. It is functional for larger systems (and I often test C/C++ on an interactive Linux system), but targeted at smaller systems. Whatever common TLS library used, it depends on the underlying OS for random generation.

sfx2000 · 2019-01-31T21:12:12.296Z

nopro404:

The development is active.

That’s the client side - server is on 2.4, and that’s what you’ll be seeing for some time to come.

Anyways - I have no issues with OpenVPN - the 2.4 is portable, secure, and well understood by many. Even Chromebooks do OpenVPN as a supported VPN access type.

sfx2000 · 2019-01-31T22:10:26.017Z

Getting the thread back on topic (entropy pool slow to fill) - and /dev/random is blocking as noted by the slow start of WG by the original poster. It doesn’t just affect the AR300/MT300 devices on WG, it’s common in many other scenarios as well.

The 9531 has a HWRNG, but it’s questionable of the quality of that generator (see the OpenWRT thread mentioned below)

With devices like this, it’s going to be a bit of a challenge - as previously noted, haveged does fill the pool fairly fast (noting stated concerns about the quality of randomness generated by haveged) - OpenWRT has done some effort to improve performance there.

Good thread over on the OpenWRT forums - Randomness quality - Installing and Using OpenWrt - OpenWrt Forum

Included in that thread was options for a TRNG key (for the truly paranoid perhaps)

Another good read here on randomness in linux, including /dev/urandom…

2uo.de

Myths about /dev/urandom - Thomas' Digital Garden

My collection of things I've learned.