I think an extra byte would be a great idea. We can use that in the future to implement a user space IUnknown/O_PONIES end to end negotiation
--John On 8/12/2016 7:11 a.m., Jason A. Donenfeld wrote: > 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 > misalignment. > > 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... > > Jason > _______________________________________________ > WireGuard mailing list > [email protected] > https://lists.zx2c4.com/mailman/listinfo/wireguard > _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
