Cipher Agility [Re: WireGuard Upstreaming Roadmap (November 2017)]

Cipher Agility [Re: WireGuard Upstreaming Roadmap (November 2017)]

[Jason A. Donenfeld]

On Thu, Dec 7, 2017 at 11:22 AM, Stefan Tatschner
<rumpelsepp@sevenbyte.org> wrote:
> 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.
> 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?

Have you read the paper?

https://www.wireguard.com/papers/wireguard.pdf

The basic answer is that WireGuard has message type identifiers, and
the handshake also hashes into it an identifier of the primitives
used. If there's ever a problem with those primitives chosen, it will
be possible to introduce new message type identifiers, if that kind of
"support everything even the broken garbage" approach is desired by
misguided people. However, a better approach, of course, is to keep
your secure network separate from your insecure network, and to not
allow insecure nodes on secure segments; when you mix the two,
disaster tends to strike. So, in other words, both approaches are
possible, in this fantasy wireguardalypse. Take note, though, that
neither one of these approaches (support new and retain old protocol
too for old nodes, or only support new) are "agile" or are anything at
all like the 90s "cipher agility" -- the user still is not permitted
to choose ciphers.

Hope this satisfies your curiosity.

Regards,
Jason