Odd length headers and alignment

Jason A. Donenfeld Jason at zx2c4.com
Wed Dec 7 19:11:17 CET 2016

Hey guys,

Wireguard data packets have a 1 byte type, a 4 byte index, an 8 byte
nonce, the ciphertext, and then a 16 byte auth tag. Having 13 bytes in
the beginning means that when we do in-place decryption, the plaintext
winds up starting at an odd-byte, transferring misalignment down to
the rest of the stack.

Now, in my testing on alignment-sensitive MIPS boxes, I've only had
alignment exceptions with this regarding the first byte, which is the
version number of the IP header. Since this is just a single byte, the
alignment doesn't actually matter. But in practice, the compiler
generates a 16-bit load instead of an 8-bit load, which sucks. I may
be able to work around this though. Beyond that, I haven't actually
observed exceptions from elsewhere in the stack regarding

So, how much of a problem do you suppose this is? Would it be
worthwhile to stick an _extra byte_ in the header, just to get even
alignment? Or an extra three bytes to get 16-byte alignment? Or do you
suppose this isn't really worth the bloat and MTU loss?

Just something to think about...


More information about the WireGuard mailing list