Re: WireGuard Upstreaming Roadmap (November 2017)

[Stefan Tatschner <rumpelsepp@sevenbyte.org>]

Hi Jason,

thanks for providing all these information. I am looking forward to
the further development of wireguard!

On Sat, Nov 11, 2017 at 5:48 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> The current biggest blocker is issues with the crypto API. Before WireGuard
> can go upstream, I intend to embark on a multi-pronged effort to overhaul the
> crypto API. I very much need to sync up with Herbert regarding my plans for
> this, and start spec'ing things out a bit more formally, so I can begin
> concrete discussions with him. I intend to base my work both on feedback
> from linux-crypto/Herbert and from the cryptographic research community. I
> hope to go to RWC2018 [3] and the subsequent HACS workshop for the academic
> engagement side, but of course like all the work I do on the kernel, things
> will be highly based in engineering, rather than purely academic, practices.

I have a question which is related to the involved crypto. As far as I
have understood the protocol and the concept of wireguard, there is no
crypto agility in the design. That means we cannot easily replace the
underlying cryptographic primitives without breaking things. Please
correct me if I am wrong.

The website states:
> WireGuard uses state-of-the-art cryptography, like the Noise protocol framework,
> Curve25519, ChaCha20, Poly1305, BLAKE2, SipHash24, HKDF, and secure trusted
> constructions. It makes conservative and reasonable choices and has been reviewed
> by cryptographers.

Assuming I am right according the crypto agility, what's the upgrade
path if any of the involved cryptographic algorithms will be declared
insecure/broken? From my point of view wireguard tries to stay as
simple as possible and in general that's a good idea. I am just a bit
worrying about the possible lack of a clear upgrade path once
wireguard is mainlined.

What's your opinion on this?

Thanks!

Stefan