Thoughts on wg-dynamic

Reid Rankin reidrankin at
Mon Apr 6 11:46:02 CEST 2020

That's a neat tool, and I'd probably use it in my own projects -- I'm
a big fan of the shell-script-only approach for userland tools -- but
the algorithm it uses has a few rough edges I'd prefer didn't get

- The hash is taken over a (newline-terminated!) Base64-encoded key
and not the raw bytes; there's nothing else in the protocol that would
require implementations to have a Base64 encoder. (This might matter
in a microcontroller implementation.) It wouldn't be hard to pipe to
`base64 -d` before hashing, which would fix this.
- I'm a fan of SHA-256 in general, but again, there's nothing else in
the protocol that would require implementers to have a SHA-256 engine.
(This would definitely matter in a microcontroller implementation.)
OTOH, `sha256sum` is a commonly available utility and reasonable to
use in a bash script, while `b2sum` is not so much.

My prototype also uses the `(subnet & mask) | (hash & ~mask)`
construction, though I use the full fe80::/10 space, instead of
fe80::/64. There's a decent argument to be made for just using the
/64, though -- it's the "interface identifier" portion of the address,
which is why that's what RFC 3972 does as well. That said, I'm not
sure there's quite the same need for subnetting in a link-local
address space. (I also feel like the subnet id/interface id dichotomy
is going the way of IPv4 class-based routing, and was probably only
conceived of as a clever ploy to keep ISPs from screwing everyone over
by only handing out out /120s.)

I've taken another look at RFC 3972, and the only way it would work
here would be by using well-known modifier and Sec parameters of zero
-- and it would force reliance on SHA-1. So I'm now thinking we don't

In any case, that makes at least two independent engineering efforts
that both use `(subnet & mask) | (hash & ~mask)` rather than using
subnet as a prefix for the hash.


More information about the WireGuard mailing list