lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 7 Dec 2017 11:22:04 +0100
From:   Stefan Tatschner <rumpelsepp@...enbyte.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        wireguard@...ts.zx2c4.com
Subject: Re: WireGuard Upstreaming Roadmap (November 2017)

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@...c4.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ