1. 19
    1. 3

      Though there are already objections to do ECDH and key derivation in the kernel

      I’ve read some objections by @zx2c4 as well about putting timers and handshake code outside of the kernel when this was proposed by someone developing a kernel version for OpenBSD: https://lists.zx2c4.com/pipermail/wireguard/2018-December/003656.html

      In my own userland implementation I’ve separated the long term secrets into a small privileged process apart from the rest.

      1. 2

        In my own userland implementation I’ve separated the long term secrets into a small privileged process apart from the rest.

        That’s the right way to do it. :)

        EDIT: Finally reading mailing list (shorter than I thought), his counter is pretty good. We keep stuff out of the kernel by default due to higher damage upon code injection. Another principle for trusted code is keeping it simple enough to know with confidence that won’t happen. He says he did that. The last factor is whether it’s easier to analyze his code for immunity vs yours plus its interactions with kernel code. The latter might be considerably more complex. This is good example of where exception might be made. So, either sounds good in this case. One might still apply some verification or hard-hitting analyzers to it if wanting extra assurance.

    2. 1

      What advantages does it give (or how does it relate in general) if compared with OpenVPN or IPsec?

      1. 5

        Substantially simpler protocol, very little possibility to misconfigure, only supports modern crypto, etc.